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 構文」を参照してください。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.