MySQL アクティブ-アクティブ同期レプリケーションの 4 つのソリューションの詳細な説明

リアルタイム データ同期の核心は、ログに基づいて実装することであり、これにより、準リアルタイム データ同期を実現できます。ログ ベースの実装では、データベース自体に設計と実装における追加の制約は必要ありません。

MySQLネイティブレプリケーションに基づくマスター-マスター同期ソリューション

これは一般的なソリューションです。一般的に、このアーキテクチャは中小規模のプロジェクトの場合に最も便利です。

2 つのノードは、シンプルなデュアル マスター モードを採用し、専用回線接続を使用できます。master_A ノードに障害が発生すると、アプリケーション接続はすぐに master_B ノードに切り替えられ、その逆も同様です。注意すべき点がいくつかあります。スプリット ブレインの場合、2 つのノードが同じデータを書き込んで競合が発生します。同時に、2 つのノードの auto_increment_increment (自動インクリメント ステップ) と auto_increment_offset (自動インクリメント開始値) が異なる値に設定されます。目的は、マスターノードが予期せずクラッシュしたときに、一部のバイナリログがスレーブにコピーされずにアプリケーションが実行され、スレーブの新しく書き込まれた自動インクリメント ID が元のマスターと競合するのを回避することです。そのため、最初からずらして配置されています。もちろん、マスターとスレーブの自動インクリメント ID の競合を解決するための適切なフォールト トレラント メカニズムがあれば、これも回避できます。新しいデータ バージョン 5.7+ を使用すると、マルチスレッド レプリケーションを使用して、レプリケーションの遅延を大幅に削減できます。同時に、レプリケーションの遅延に特に敏感な別の代替ソリューションは、半同期半同期レプリケーションです。これは基本的に遅延はありませんが、特に双方向書き込みでは、トランザクションの同時実行パフォーマンスが大幅に低下するため、決定する前に包括的な評価が必要です。

Galeraレプリケーションソリューションに基づく

Galera は、Codership が提供するマルチマスター データ同期およびレプリケーション メカニズムです。複数のノード間でデータ同期レプリケーションと読み取り/書き込みを実現し、データベース サービスの高可用性とデータの一貫性を確保できます。Galera に基づく高可用性ソリューションには、主に MariaDB Galera Cluster と Percona XtraDB Cluster (略して PXC) があります。

現在、PXC はより広く使用されています。データの一貫性が厳格で、特に電子商取引アプリケーションに適しています。ただし、PXC にも制限があります。同時トランザクション量が多い場合は、ネットワーク遅延を減らすために InfiniBand ネットワークを使用することをお勧めします。PXC には書き込み拡張とショートボード効果があるため、同時効率が大幅に低下します。半同期半同期レプリケーションと同様に、Gelera は実際には 3 つのノードしか使用できず、ネットワーク ジッターによるパフォーマンスと安定性の問題が常態化しています。

グループレプリケーションソリューションに基づく

MGRはMySQLが正式にリリースした高可用性ソリューションで、Paxosプロトコルを通じてデータベースクラスタノードデータに強力な一貫性保証を提供します。ネイティブレプリケーションテクノロジに基づいており、プラグインとして提供されます。クラスタ間のすべてのノードに書き込みが可能で、単一クラスタの書き込みパフォーマンスを解決します。すべてのノードが読み取りと書き込みが可能で、ネットワークパーティションによるブレインスプリットの問題を解決し、複製されたデータの信頼性を向上させます。しかし、現実はまだ少し残酷です。現時点では、試した人は多くありません。同時に、InnoDBテーブルのみをサポートしており、書き込みセットの競合検出のために各テーブルにプライマリキーが必要です。GTID機能をオンにし、プライマリ選択と書き込みセットのバイナリログ形式をROWに設定する必要があります。

COMMIT は、スナップショット トランザクション分離レベルの障害シナリオと同様に、障害を引き起こす可能性があります。現在、MGR クラスターは最大 9 ノードをサポートし、外部キーとセーブ ポイント機能をサポートせず、グローバル制約検出と部分ロールバックを実行できず、バイナリ ログは binlog イベント チェックサムをサポートしていません。

運河ソリューションに基づく

データベースのリアルタイム同期のために、Alibaba は分散データベースの同期レプリケーションを実装する特別なオープンソース プロジェクト Otter を持っています。その中心となるアイデアは、データベースの増分データ ログを取得することで、準リアルタイムの同期レプリケーションを実行することです。そのため、Otter 自体は、増分データベース同期ログ情報の取得に重点を置いた別のオープンソース プロジェクトである Canal に依存しています。

現在、Otter の焦点は、MySQL 間のデータベース同期とレプリケーションを実現することにあります。基本的には、同様のテクノロジを使用して、2 つの MySQL データベース間の双方向同期データベース レプリケーションを実現します。この双方向性自体は、A->B または B->A に移動できることを意味し、特定の時点では単方向であることに注意してください。

マスタースレーブレプリケーションは 3 つのステップに分かれています。

マスターはバイナリ ログに変更を記録します (これらの記録はバイナリ ログ イベントと呼ばれ、show binlog events で表示できます)。

スレーブはマスターのバイナリ ログ イベントをリレー ログにコピーします。

スレーブはリレー ログ内のイベントをやり直し、データを自身のものに反映するように変更します。

運河の原理は比較的単純です。

Canal は MySQL スレーブの対話型プロトコルをシミュレートし、MySQL スレーブのふりをして、ダンプ プロトコルを MySQL マスターに送信します。

MySQL マスターはダンプ要求を受信し、バイナリ ログをスレーブ (チャネル) にプッシュし始めます。
Canalはバイナリログオブジェクト（元々はバイトストリーム）を解析します

詳細については、https://github.com/alibaba/canal をご覧ください。

要約する

上記は、編集者が紹介したMySQLアクティブ-アクティブ同期レプリケーションの4つのソリューションです。皆様のお役に立てれば幸いです。ご質問がある場合は、メッセージを残してください。編集者がすぐに返信します。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。