理解しておく必要があることの 1 つは、その記事で簡単に言及されていることですが、各 MariaDB の GTID 実装がこの状況で問題を引き起こす可能性があるということです。各ノードは GTID の独自のリストを保持し、galera トランザクションには独自の ID がないため、同じ GTID が各サーバーの同じ場所を指していない可能性があります (この記事を参照)。
その問題のため、MariaDB 10.1 なしであなたがしていることを試みません。MariaDB 10.1.8 がリリースされたばかりで、10.1 ラインの最初の GA リリースです。10.1 では GTID の実装が変更されているため、galera トランザクションは独自のserver_id(構成変数を介して設定) を使用します。その後、スレーブでレプリケーションをフィルタリングして、galera id のみをレプリケートできます。
別のスレーブ サーバーに切り替えるには、古いスレーブで実行された最後の GTID を取得する必要があります。gtid_slave_posに格納されますがmysql.gtid_slave_pos、mysql.*テーブルは複製されません。トランザクションの元の GTID が他のスレーブ galera ノードに渡されるかどうか (つまり、マスター クラスターの galera server_id が 1 で、スレーブ クラスターの galera server_id が 2 であり、 MDBDR-01 は GTID 1-1-123 のスレーブ イベントを取得し、MDBDR-02 はそれを 1-1-123 または 1-2-456 として記録します)。新しい GTID 実装では server_id を変更する必要があるため、そうではないと推測していますが、これを確認できる場合があります。最後に実行されたマスター GTID を別のスレーブ galera ノードから取得することはおそらくできないため、古いスレーブを正常にシャットダウンしない限り、古いスレーブから GTID を取得する必要があります。新しいスレーブの binlog で最後に実行されたトランザクションから GTID を見つけ、それをマスターの binlog のトランザクションと照合する必要がある場合があります。また、使用していない場合はsync_binlog = 1、バイナリログは信頼できず、少し遅れている可能性があります。
各 galera スレーブ ノードはおそらく実行された GTID を認識しておらず、以前の GTID イベントをスキップできないSQL_SLAVE_SKIP_COUNTERため、見つけた GTID が遅れている場合は、正しい位置に到達するために操作する必要がある場合もあります。
GTID (またはその推測) を取得したら、元のスレーブで設定したのと同じ方法で、新しいスレーブでレプリケーションを設定します。次のコマンドでそれを行う必要があります。
SET GLOBAL gtid_slave_pos = "{最後に実行された GTID}";
CHANGE MASTER TO master_host="{Master Address}", master_port={Master Port}, master_user="{Replication User}", master_password={Replication Password}, master_use_gtid=slave_pos;
スレーブを開始します。
また、古いスレーブを再起動する前に複製を無効にして、見逃したイベントが 2 回複製されないようにする必要があります。
実行されたスレーブ GTID が galera を介してレプリケートされるまで (これは決して起こらない可能性があります)、このようなフェイルオーバーは厄介なプロセスになります。