MySQLとMariaDBのHA-マスターマスターレプリケーションとGaleraクラスターの比較

ガレラレプリケーションは、MySQL v3.23以降でネイティブにサポートされているMySQLレプリケーションと比較すると、比較的新しいものです。 MySQLレプリケーションは、マスタースレーブ単方向レプリケーション用に設計されていますが、双方向レプリケーションを備えたアクティブなマスターマスターセットアップとして構成できます。セットアップは簡単で、一部のユースケースはこの「ハック」の恩恵を受ける可能性がありますが、いくつかの注意点があります。一方、Galeraクラスターは、学習および管理するための別のタイプのテクノロジーです。それだけの価値はありますか？

このブログ投稿では、マスターマスターレプリケーションをGaleraクラスターと比較します。

レプリケーションの概念

比較に入る前に、これら2つの複製メカニズムの背後にある基本的な概念を説明しましょう。

通常、MySQLデータベースを変更すると、バイナリ形式でイベントが生成されます。このイベントは、選択したレプリケーション方法（MySQLレプリケーション（ネイティブ）またはGaleraレプリケーション（wsrep APIでパッチが適用されます））に応じて他のノードに転送されます。

MySQLレプリケーション

次の図は、MySQLレプリケーションを使用した場合の、あるノードから別のノードへの成功したトランザクションのデータフローを示しています。

バイナリイベントは、マスターのバイナリログに書き込まれます。 slave_IO_threadを介したスレーブ マスターのバイナリログからバイナリイベントをプルし、それらをリレーログに複製します。 slave_SQL_thread 次に、リレーログからのイベントを非同期で適用します。レプリケーションは非同期であるため、マスターが変更を実行するときにスレーブサーバーがデータを保持することは保証されません。

理想的には、MySQLレプリケーションでは、read_only=ONまたはsuper_read_only=ONを設定することにより、スレーブを読み取り専用サーバーとして構成します。これは、マスターフェイルオーバー中のデータの不整合や障害（誤ったトランザクションなど）につながる可能性のある偶発的な書き込みからスレーブを保護するための予防策です。ただし、マスター-マスターアクティブ-アクティブレプリケーションのセットアップでは、書き込みを同時に処理できるようにするには、他のマスターで読み取り専用を無効にする必要があります。プライマリマスターは、CHANGE MASTERステートメントを使用してセカンダリマスターからレプリケートするように構成し、循環レプリケーションを有効にする必要があります。

ガレラレプリケーション

次の図は、GaleraClusterのあるノードから別のノードへの成功したトランザクションのデータレプリケーションフローを示しています。

イベントはライトセットにカプセル化され、Galeraレプリケーションを使用して、発信元ノードからクラスター内の他のノードにブロードキャストされます。ライトセットはすべてのGaleraノードで認証を受け、合格すると、アプライヤースレッドがライトセットを非同期に適用します。これは、グローバルな合計順序で参加しているすべてのノードが合意した後、スレーブサーバーが最終的に一貫性を持つようになることを意味します。論理的には同期していますが、テーブルスペースへの実際の書き込みとコミットは独立して行われるため、各ノードで非同期に行われ、変更がすべてのノードに伝播することが保証されます。

主キーの衝突の回避

マスターマスターセットアップでMySQLレプリケーションをデプロイするには、自動インクリメント値を調整して、2つ以上のレプリケーションマスター間のINSERTの主キーの衝突を回避する必要があります。これにより、マスターの主キー値が相互にインターリーブし、同じ自動増分番号がいずれかのノードで2回使用されるのを防ぐことができます。この動作は、レプリケーション設定のマスターの数に応じて手動で構成する必要があります。 auto_increment_incrementの値 複製するマスターの数とauto_increment_offsetに等しい それらの間で一意である必要があります。たとえば、対応するmy.cnf内に次の行が存在する必要があります。

マスター1：

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

マスター2：

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

同様に、Galera Clusterはこれと同じトリックを使用して、自動インクリメント値とオフセットを wsrep_auto_increment_control で自動的に制御することにより、主キーの衝突を回避します。 変数。 1（デフォルト）に設定すると、 auto_increment_incrementが自動的に調整されます およびauto_increment_offset クラスターのサイズに応じた変数、およびクラスターのサイズが変更されたとき。これにより、auto_incrementによるレプリケーションの競合が回避されます。マスタースレーブ環境では、この変数をオフに設定できます。

この構成の結果、3ノードのGaleraクラスターの次の表に示すように、自動増分値が順番に表示されなくなります。

アプリケーションが次のノードで次の順序で挿入操作を実行する場合：

• Node1、Node3、Node2、Node3、Node3、Node1、Node3 ..

その場合、テーブルに格納される主キーの値は次のようになります。

• 1、6、8、9、12、13、15 ..

簡単に言うと、マスターマスターレプリケーション（MySQLレプリケーションまたはGalera）を使用する場合、アプリケーションはデータセット内の非シーケンシャル自動インクリメント値を許容できる必要があります。

ClusterControlユーザーの場合、アクティブ-パッシブセットアップの場合のみ、レプリケーションクラスターごとに2つのマスターの制限でMySQLマスター-マスターレプリケーションの展開をサポートすることに注意してください。したがって、ClusterControlは、 auto_increment_incrementを使用してマスターを意図的に構成しません。 およびauto_increment_offset 変数。

データの一貫性

Galera Clusterにはフロー制御メカニズムが付属しており、複製時にクラスター内の各ノードが追いつく必要があります。そうしないと、最も遅いノードが追いつくために他のすべてのノードの速度を落とす必要があります。これにより、基本的にスレーブラグの可能性が最小限に抑えられますが、それでも発生する可能性はありますが、MySQLレプリケーションほど重要ではありません。デフォルトでは、Galeraは、変数 gcs.fc_limit を介して適用する際に、ノードが少なくとも16トランザクション遅れることを許可します。 。重要な読み取り（最新の情報を返す必要があるSELECT）を実行する場合は、セッション変数 wsrep_sync_waitを使用することをお勧めします。 。

一方、Galera Clusterには、データの不整合に対する保護手段が付属しており、何らかの理由でライトセットを適用できなかった場合にノードがクラスターから削除されます。たとえば、基盤となるストレージエンジン（MySQL / MariaDB）による内部エラーが原因で、Galeraノードがライトセットの適用に失敗した場合、ノードは次のエラーでクラスターから自身を引き出します。

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

データの整合性を修正するには、問題のあるノードをクラスターへの参加を許可する前に再同期する必要があります。これは、手動で行うことも、データディレクトリを消去してスナップショット状態の転送（ドナーからの完全同期）をトリガーすることによって行うこともできます。

MySQLマスターマスターレプリケーションはデータ整合性保護を強制せず、スレーブは分岐することが許可されます。たとえば、データのサブセットをレプリケートしたり、遅れたりするため、スレーブはマスターと整合性がなくなります。マスターからスレーブまで、1つのフローでデータを複製するように設計されています。データ整合性チェックは、手動で実行するか、PerconaToolkitpt-table-checksumやmysql-replication-checkなどの外部ツールを介して実行する必要があります。

競合の解決

一般に、マスターマスター（またはマルチマスター、または双方向）レプリケーションでは、クラスター内の複数のメンバーが書き込みを処理できます。 MySQLレプリケーションでは、レプリケーションの競合が発生した場合、レプリケーションイベントを手動でスキップするか、問題のある行を修正するか、スレーブを再同期することにより、競合が解決されるまで、スレーブのSQLスレッドは次のクエリの適用を停止します。簡単に言うと、MySQLレプリケーションの自動競合解決サポートはありません。

Galera Clusterは、レプリケーション中に問題のあるトランザクションを再試行することにより、より適切な代替手段を提供します。 wsrep_retry_autocommitを使用する 変数の場合、クライアントにエラーを返す前に、クラスター全体の競合が原因で失敗したトランザクションを自動的に再試行するようにGaleraに指示できます。 0に設定すると、再試行は試行されませんが、1（デフォルト）以上の値は、再試行の回数を指定します。これは、デッドロックを回避するために自動コミットを使用するアプリケーションを支援するのに役立ちます。

ノードのコンセンサスとフェイルオーバー

Galeraは、グループコミュニケーションシステム（GCS）を使用して、クラスターメンバー間のノードコンセンサスと可用性をチェックします。ノードが異常な場合、 gmcast.peer_timeoutの後にクラスターから自動的に削除されます。 値。デフォルトは3秒です。 「同期」状態の正常なGaleraノードは、読み取りと書き込みを提供する信頼できるノードと見なされますが、他のノードはそうではありません。この設計により、上位層（ロードバランサーまたはアプリケーション）からのヘルスチェック手順が大幅に簡素化されます。

MySQLレプリケーションでは、マスターはスレーブを気にしませんが、スレーブは slave_IO_threadを介して唯一のマスターとのみコンセンサスを持ちます。 マスターのバイナリログからバイナリイベントを複製するときに処理します。マスターがダウンすると、レプリケーションが中断され、リンクの再確立が slave_net_timeoutごとに試行されます。 （デフォルトは60秒）。アプリケーションまたはロードバランサーの観点から、レプリケーションスレーブのヘルスチェック手順には、少なくとも次の状態のチェックが含まれている必要があります。

• Secondarys_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• read_only変数
• super_read_only変数（MySQL 5.7.8以降）

フェイルオーバーに関しては、一般的に、マスターマスターレプリケーションとGaleraノードは同等です。それらは同じデータセットを保持し（MySQLレプリケーションでデータのサブセットをレプリケートできますが、マスターマスターでは一般的ではありません）、マスターと同じ役割を共有し、読み取りと書き込みを同時に処理できます。したがって、この平衡状態のため、データベースの観点からは実際にはフェイルオーバーはありません。動作していないノードをスキップするためにフェイルオーバーを必要とするアプリケーション側からのみ。 MySQLレプリケーションは非同期であるため、マスターで行われたすべての変更が他のマスターに伝播されない可能性があることに注意してください。

ノードプロビジョニング

レプリケーションを開始する前にノードをクラスターと同期させるプロセスは、プロビジョニングと呼ばれます。 MySQLレプリケーションでは、新しいノードのプロビジョニングは手動プロセスです。レプリケーションリンクを設定する前に、マスターのバックアップを取り、それを新しいノードに復元する必要があります。既存のレプリケーションノードの場合、マスターのバイナリログがローテーションされている場合（ expire_logs_days に基づく） 、デフォルトの0は自動削除がないことを意味します）、この手順を使用してノードを再プロビジョニングする必要がある場合があります。これを支援するPerconaToolkitpt-table-syncやClusterControlなどの外部ツールもあります。 ClusterControlは、2回クリックするだけでスレーブの再同期をサポートします。アクティブなマスターまたは既存のバックアップからバックアップを取ることで再同期するオプションがあります。

Galeraでは、これを行うには2つの方法があります。インクリメンタル状態転送（IST）または状態スナップショット転送（SST）です。 ISTプロセスは、欠落しているトランザクションのみがドナーのキャッシュから転送される推奨される方法です。 SSTプロセスは、ドナーからの完全バックアップの取得に似ており、通常、かなりのリソースを消費します。 Galeraは、参加者の状態に基づいて、トリガーする同期プロセスを自動的に決定します。ほとんどの場合、ノードがクラスターへの参加に失敗した場合は、問題のあるノードのMySQLデータディレクトリを消去して、MySQLサービスを開始します。 Galeraのプロビジョニングプロセスははるかに簡単で、クラスターをスケールアウトしたり、問題のあるノードをクラスターに再導入したりするときに非常に便利です。

緩く結合されたものと密に結合されたもの

MySQLレプリケーションは、低速の接続間や、連続していない接続でも非常にうまく機能します。また、さまざまなハードウェア、環境、およびオペレーティングシステムで使用することもできます。 MyISAM、Aria、MEMORY、ARCHIVEなど、ほとんどのストレージエンジンがこれをサポートしています。この疎結合のセットアップにより、MySQLマスター-マスターレプリケーションは、制限の少ない混合環境で適切に機能します。

Galeraノードは緊密に結合されており、レプリケーションのパフォーマンスは最も遅いノードと同じくらい高速です。 Galeraは、フロー制御メカニズムを使用して、メンバー間のレプリケーションフローを制御し、スレーブラグを排除します。レプリケーションは、すべてのノードですべて高速またはすべて低速にすることができ、Galeraによって自動的に調整されます。したがって、特にCPU、RAM、ディスクサブシステム、ネットワークインターフェイスカード、およびクラスター内のノード間のネットワークレイテンシに関して、すべてのGaleraノードに統一されたハードウェア仕様を使用することをお勧めします。

結論

要約すると、Galera Clusterは、強力な一貫性を備えた同期レプリケーションサポートに加えて、自動メンバーシップ制御、自動ノードプロビジョニング、マルチスレッドスレーブなどのより高度な機能により、MySQLマスターマスターレプリケーションと比較して優れています。最終的に、これはアプリケーションがデータベースサーバーとどのように相互作用するかに依存します。スタンドアロンデータベースサーバー用に構築された一部のレガシーアプリケーションは、クラスター化されたセットアップではうまく機能しない場合があります。

上記のポイントを単純化するために、次の理由により、MySQLマスターマスターレプリケーションをいつ使用するかが正当化されます。

• Galeraでサポートされていないもの：
  • MyISAM、Aria、MEMORY、ARCHIVEなどの非InnoDB/XtraDBテーブルのレプリケーション。
  • XAトランザクション。
  • マスター間のステートメントベースのレプリケーション（帯域幅が非常に高い場合など）。
  • LOCKTABLESステートメントのような明示的なロックに依存しています。
  • 一般的なクエリログと遅いクエリログは、ファイルではなくテーブルに送信する必要があります。
• ハードウェアの仕様、ソフトウェアのバージョン、接続速度がマスターごとに大幅に異なる、ゆるく結合されたセットアップ。
• すでにMySQLレプリケーションチェーンがあり、マスターの1つが利用できない場合に備えて、フェイルオーバーとリカバリ時間を短縮するために冗長性のために別のアクティブ/バックアップマスターを追加する場合。
• アプリケーションを変更してGaleraClusterの制限を回避できず、ProxySQLやMaxScaleなどのMySQL対応のロードバランサーを使用できない場合。

MySQLマスターマスターレプリケーションよりもGaleraClusterを選択する理由：

• 複数のマスターに安全に書き込む機能。
• データベース全体でデータの一貫性が自動的に管理（および保証）されます。
• 新しいデータベースノードは簡単に導入および同期できます。
• 障害または不整合が自動的に検出されます。
• 一般的に、より高度で堅牢な高可用性機能。