Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  MySQL Cluster レプリケーション: マルチマスターと循環レプリケーション

18.6.10 MySQL Cluster レプリケーション: マルチマスターと循環レプリケーション

マルチマスターレプリケーションで MySQL Cluster を使用することは可能です (多くの MySQL Cluster 間の循環レプリケーションを含みます)。

循環レプリケーションの例  次のいくつかのパラグラフでは、次のようなレプリケーションセットアップの例について検討します。このセットアップは、番号が 1、2、3 の 3 つの MySQL Cluster で構成され、クラスタ 1 はクラスタ 2 のレプリケーションマスターとして動作し、クラスタ 2 はクラスタ 3 のマスターとして動作し、クラスタ 3 はクラスタ 1 のマスターとして動作します。各クラスタは 2 つの SQL ノードを持ち、SQL ノード A と B はクラスタ 1 に属し、SQL ノード C と D はクラスタ 2 に属し、SQL ノード E と F はクラスタ 3 に属しています。

これらのクラスタを使用する循環レプリケーションは、次の条件を満たすかぎり、サポートされます。

  • すべてのマスターとスレーブの SQL ノードは同じ

  • レプリケーションのマスターおよびスレーブとして動作するすべての SQL ノードが --log-slave-updates オプションを使用して起動される

このタイプの循環レプリケーションのセットアップは、次の図に示すとおりです。

すべてのマスター SQL ノードがスレーブでもある、MySQL Cluster 循環レプリケーションのスキームです。

このシナリオでは、クラスタ 1 の SQL ノード A はクラスタ 2 の SQL ノード C に複製し、SQL ノード C はクラスタ 3 の SQL ノード E に複製し、SQL ノード E は SQL ノード A に複製します。言い換えると、レプリケーションライン (図中の赤の矢印) は、レプリケーションのマスターおよびスレーブとして使用されるすべての SQL ノードを直接接続します。

ここで示すように、すべてのマスター SQL ノードが必ずしもスレーブというわけではない場合に、循環レプリケーションをセットアップすることも可能です。

すべてのマスター SQL ノードが必ずしもスレーブではない、MySQL Cluster 循環レプリケーションのスキームです。

この場合、各クラスタの異なる SQL ノードはレプリケーションのマスターおよびスレーブとして使用されます。ただし、SQL ノードを --log-slave-updates を使用して起動する必要はありません。レプリケーションのライン (これも図中の赤の矢印) が連続的でない MySQL Cluster のこのタイプの循環レプリケーションスキームは、可能性はありますが、まだ完全にはテストされていないため、実験的なものだと考えるようにしてください。

NDB ネイティブのバックアップとリストアを使用したスレーブ MySQL Cluster の初期化  循環レプリケーションをセットアップする場合、バックアップを作成する MySQL Cluster で管理クライアントの BACKUP コマンドを使用してから、ndb_restore を使用して別の MySQL Cluster でこのバックアップを適用すると、スレーブクラスタを初期化できます。ただし、これによってバイナリログが、レプリケーションスレーブとして動作する 2 番目の MySQL Cluster の SQL ノードに、自動的に作成されることはありません。バイナリログが作成されるようにするには、対象の SQL ノードで SHOW TABLES ステートメントを発行する必要があります。これは、START SLAVE を実行する前に行なってください。

これは、今後のリリースで対応する予定の既知の問題です。

マルチマスターのフェイルオーバーの例  このセクションでは、3 つの MySQL Cluster のサーバー ID が 1、2、および 3 であるマルチマスターの MySQL Cluster レプリケーションセットアップでのフェイルオーバーについて説明します。このシナリオでは、クラスタ 1 はクラスタ 2 および 3 に複製し、クラスタ 2 もクラスタ 3 に複製します。この関係はここで示すとおりです。

3 つの MySQL Cluster で構成される、マルチマスター MySQL Cluster レプリケーションセットアップ

つまり、データはクラスタ 1 からクラスタ 3 へ異なる 2 つのルートを介して (直接、およびクラスタ 2 経由で) 複製されます。

マルチマスターレプリケーションに参加するすべての MySQL サーバーが必ずしもマスターとスレーブの両方の役割を果たさなければならないわけではなく、特定の MySQL Cluster が異なるレプリケーションチャネルの異なる SQL ノードを使用する場合があります。このようなケースを次に示します。

マルチマスター MySQL Cluster レプリケーションセットアップ (各 MySQL Server)

レプリケーションスレーブとして動作している MySQL サーバーは、--log-slave-updates オプションを使用して実行する必要があります。また、どの mysqld プロセスでこのオプションが必要か、前の図に示されています。

注記

--log-slave-updates オプションを使用しても、レプリケーションスレーブとして動作していないサーバーには作用しません。

複製しているクラスタの 1 つが停止した場合、フェイルオーバーの必要性が生じます。この例では、クラスタ 1 のサービスが失われ、そのためにクラスタ 3 がクラスタ 1 の更新の 2 つのソースを失うケースを検討します。MySQL Cluster 間のレプリケーションが非同期であるため、クラスタ 1 から直接生じるクラスタ 3 の更新が、クラスタ 2 を経由して受け取った更新よりも新しいという保証はありません。クラスタ 1 からの更新に関して、クラスタ 3 が確実にクラスタ 2 に追いつくことで、これに対処できます。すなわち、MySQL サーバーに関して、未処理の更新を MySQL サーバー C からサーバー F に複製する必要があります。

サーバー C で、次のクエリーを実行します。

mysqlC> SELECT @latest:=MAX(epoch)
     ->     FROM mysql.ndb_apply_status
     ->     WHERE server_id=1;

mysqlC> SELECT
     ->     @file:=SUBSTRING_INDEX(File, '/', -1),
     ->     @pos:=Position
     ->     FROM mysql.ndb_binlog_index
     ->     WHERE orig_epoch >= @latest
     ->     AND orig_server_id = 1
     ->     ORDER BY epoch ASC LIMIT 1;
注記

適切なインデックスを ndb_binlog_index テーブルに追加することで、このクエリーのパフォーマンスを向上できるため、フェイルオーバー時間が大幅に短縮される可能性があります。詳細については、セクション18.6.4「MySQL Cluster レプリケーションスキーマとテーブル」を参照してください。

@file および @pos の値を手動でサーバー C からサーバー F にコピーをします (またはアプリケーションで同様に実行させます)。次にサーバー F で、次の CHANGE MASTER TO ステートメントを実行します。

mysqlF> CHANGE MASTER TO
     ->     MASTER_HOST = 'serverC'
     ->     MASTER_LOG_FILE='@file',
     ->     MASTER_LOG_POS=@pos;

この実行後、MySQL サーバー F で START SLAVE ステートメントを発行でき、サーバー B から生じた、不足している更新がサーバー F に複製されます。

CHANGE MASTER TO ステートメントは IGNORE_SERVER_IDS オプションもサポートします。このオプションは、カンマ区切りのサーバーの ID を使用し、対応するサーバーから発生したイベントが無視されます。詳細については、セクション13.4.2.1「CHANGE MASTER TO 構文」およびセクション13.7.5.35「SHOW SLAVE STATUS 構文」を参照してください。