このセクションでは、MySQL Cluster NDB 7.3 でレプリケーションを使用する場合の既知の問題や課題について説明します。
マスタースレーブの接続の喪失
接続の喪失は、レプリケーションマスターの SQL ノードとレプリケーションスレーブの SQL ノードとの間、またはレプリケーションマスターの SQL ノードとマスタークラスタのデータノードとの間のいずれかで発生する可能性があります。後者の場合にこの発生は、物理的な接続が喪失した結果 (たとえば、ネットワークケーブルの破損など) だけではなく、データノードイベントのバッファーのオーバーフローによる可能性もあります。SQL ノードは、応答が遅すぎると、クラスタでドロップされる可能性があります (これは、MaxBufferedEpochs
および TimeBetweenEpochs
構成パラメータを調整することで、ある程度まで制御が可能です)。これが起こると、新しいデータをレプリケーションマスターのバイナリログに記録せずに、マスタークラスタに挿入できます。このため、高可用性を保証するには、スレーブクラスタとマスター間の同期の維持に必要な場合、セカンダリレプリケーションチャネルへのフェイルオーバー、バックアップレプリケーションチャネルの維持、プライマリチャネルのモニターが非常に重要です。MySQL Cluster は、自身でこのようなモニタリングを実行するようには設計されていないため、外部のアプリケーションが必要です。
レプリケーションマスターは、マスタークラスタに接続したり、再接続をしたりするときに「ギャップ」イベントを発行します。(ギャップイベントは一種の「インシデントイベント」であり、データベースの内容に影響を与えるが、一連の変更として容易に表現できないインシデントが発生したことを示します。インシデントの例は、サーバーのクラッシュ、データベースの再同期、(複数の) ソフトウェアの更新、(複数の) ハードウェアの更新などです。)スレーブは、レプリケーションログ内のギャップを検出すると、エラーメッセージを出して停止します。このメッセージは SHOW SLAVE STATUS
の出力に表示され、SQL スレッドがレプリケーションストリームに登録されたインシデントによって停止し、手動による介入が必要なことを示します。このような状況での対処の詳細については、セクション18.6.8「MySQL Cluster レプリケーションを使用したフェイルオーバーの実装」を参照してください。
MySQL Cluster は自身でレプリケーションのステータスをモニターしたり、フェイルオーバーの準備をしたりするようには設計されていないため、高可用性がスレーブのサーバーまたはクラスタの要件である場合、複数のレプリケーションラインをセットアップし、プライマリのレプリケーションラインでマスターの mysqld をモニターし、必要に応じてセカンダリラインへのフェイルオーバーの準備をする必要があります。これは、手動や、場合によってはサードパーティーのアプリケーションによって行う必要があります。この種のセットアップの実装に関する情報については、セクション18.6.7「2 つのレプリケーションチャネルを使用する MySQL Cluster レプリケーション」および セクション18.6.8「MySQL Cluster レプリケーションを使用したフェイルオーバーの実装」を参照してください。
ただし、スタンドアロンの MySQL サーバーから MySQL Cluster に複製している場合は、通常 1 つのチャネルで十分です。
循環レプリケーション MySQL Cluster レプリケーションは、次の例で示すように、循環レプリケーションをサポートしています。レプリケーションのセットアップは、番号が 1、2、3 の 3 つの MySQL Cluster で構成され、クラスタ 1 はクラスタ 2 のレプリケーションマスターとして動作し、クラスタ 2 はクラスタ 3 のマスターとして動作し、クラスタ 3 はクラスタ 1 のマスターとして動作して循環を完成します。各 MySQL Cluster は 2 つの SQL ノードを持ち、SQL ノード A と B はクラスタ 1 に属し、SQL ノード C と D はクラスタ 2 に属し、SQL ノード E と F はクラスタ 3 に属しています。
これらのクラスタを使用する循環レプリケーションは、次の条件を満たすかぎり、サポートされます。
すべてのマスターとスレーブの SQL ノードは同じ
レプリケーションのマスターおよびスレーブとして動作するすべての SQL ノードが
--log-slave-updates
オプションを使用して起動される
このタイプの循環レプリケーションのセットアップは、次の図に示すとおりです。

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

この場合、各クラスタの異なる SQL ノードはレプリケーションのマスターおよびスレーブとして使用されます。ただし、SQL ノードを --log-slave-updates
を使用して起動する必要はありません。レプリケーションのライン (これも図中の赤の矢印) が連続的でない MySQL Cluster のこのタイプの循環レプリケーションスキームは、可能性はありますが、まだ完全にはテストされていないため、実験的なものだと考えるようにしてください。
NDB
ストレージエンジンはIDEMPOTENT 実行モードを使用します。このモードでは、このモードでない場合に MySQL Cluster の循環レプリケーションを中断する重複キーなどのエラーを抑止します。これは、グローバル slave_exec_mode
システム変数を IDEMPOTENT
に設定することと同等です。これは、MySQL Cluster を使用する場合のマルチマスターレプリケーションにも必要です。(Bug #31609)
多重モードは MySQL Cluster を使用する場合のマルチマスターレプリケーションにも必須ですが (Bug #31609)、MySQL Cluster のレプリケーションで slave_exec_mode
を設定する必要はありません。MySQL Cluster でこの設定を自動的に行い、この変数の明示的な設定への試行を無視するためです。
MySQL Cluster レプリケーションと主キー
ノード障害が発生した場合、重複行が挿入される可能性があるため、主キーがない NDB
テーブルのレプリケーションでエラーが発生する可能性があります。このため、複製されるすべての NDB
テーブルに主キーを持つことを強くお勧めします。
MySQL Cluster レプリケーションと一意キー
古いバージョンの MySQL Cluster では、NDB
テーブルの一意キーのカラムの値を更新する操作が行われると、複製時に重複キーエラーになる場合がありました。NDB
テーブル間のレプリケーションに関するこの問題は、すべてのテーブル行の更新が実行されるまで一意キーのチェックを保留することで解決されます。
この方法で制約を保留することは、現在 NDB
でのみサポートされています。このため、NDB
から別のストレージエンジン (MyISAM
や InnoDB
など) に複製する場合の一意キーの更新は、まだサポートされていません。
一意キーの更新のチェックを保留しないレプリケーションが NDB
テーブル (t
など) を使用して説明が可能な場合に発生する問題は、ここで示すように、マスターで発生し、移入されます (および一意キーの更新の保留をサポートしていないスレーブに複製されます)。
CREATE TABLE t (
p INT PRIMARY KEY,
c INT,
UNIQUE KEY u (c)
) ENGINE NDB;
INSERT INTO t
VALUES (1,1), (2,2), (3,3), (4,4), (5,5);
t
での次の UPDATE
ステートメントはマスターで成功します。これは、影響を受ける行が ORDER BY
オプションで指定される順番で処理され、テーブル全体に実行されるためです。
UPDATE t SET c = c - 1 ORDER BY p;
しかしスレーブでは、同じステートメントが重複キーエラーなどの制約違反で失敗しました。これは、行の更新の順序付けが、テーブル全体に対して行われたのではなく、一回に 1 つのパーティションに対して行われたためです。
各 NDB
テーブルは、作成時に、キーで無条件にパーティション化されます。詳細については、セクション19.2.5「KEY パーティショニング」を参照してください。
GTID は未サポート
グローバルトランザクション ID を使用するレプリケーションは、NDB
ストレージエンジンと互換性がなく、サポートされていません。GTID を有効にすると、MySQL Cluster レプリケーションが失敗する可能性があります。
--initial での再起動
--initial
オプションを使用してクラスタを再起動すると、GCI とエポック番号の順序が 0
からやり直されます。(これは一般的に MySQL Cluster に当てはまり、MySQL Cluster を含むレプリケーションシナリオに限定されているわけではありません。)この場合、レプリケーションに関与する MySQL サーバーは再起動されます。この後、RESET MASTER
および RESET SLAVE
ステートメントを使用して、無効な ndb_binlog_index
および ndb_apply_status
テーブルをそれぞれクリアしてください。
NDB から別のストレージエンジンへのレプリケーション
マスターの NDB
テーブルを、異なるストレージエンジンを使用するスレーブのテーブルに複製できますが、次に記載した制限事項を考慮してください。
マルチマスターと循環レプリケーションはサポートされていません (これを機能させるには、マスターとスレーブの両方のテーブルで
NDB
ストレージエンジンを使用する必要があります)。スレーブのテーブルにバイナリロギングを実行していないストレージエンジンを使用するには、特別な処理が必要です。
スレーブのテーブルに非トランザクションのストレージエンジンを使用する場合も、特別な処理が必要です。
マスターの mysqld は
--ndb-log-update-as-write=0
または--ndb-log-update-as-write=OFF
で起動する必要があります。
次のいくつかのパラグラフでは、ここで説明したそれぞれの問題の追加情報を示します。
NDB をほかのストレージエンジンに複製するときにサポートされていないマルチマスター
NDB
からの異なるストレージエンジンへのレプリケーションの場合、2 つのデータベースの関係は、単純なマスタースレーブ関係である必要があります。つまり、循環レプリケーションまたはマスターマスターレプリケーションは MySQL Cluster とほかのストレージエンジン間でサポートされていません。
また、NDB
および別のストレージエンジン間で複製する場合、複数のレプリケーションチャネルを構成できません。(ただし、MySQL Cluster データベースは複数のスレーブ MySQL Cluster データベースに同時に複製できます。)マスターが NDB
テーブルを使用している場合、複数の MySQL Server がすべての変更のバイナリログを維持することは、引き続き可能です。ただし、スレーブがマスターを変えた場合 (フェイルオーバー)、新しいマスタースレーブ関係はスレーブで明示的に定義される必要があります。
バイナリロギングを実行していないスレーブのストレージエンジンへの NDB の複製 独自のバイナリロギングを処理しないストレージエンジンを使用するスレーブに MySQL Cluster から複製を試みると、レプリケーションプロセスは次のエラーにより停止します: Binary logging not possible ... Statement cannot be written atomically since more than one engine involved and at least one engine is self-logging (エラー 1595)。次の方法のいずれかで、この問題を回避できます。
スレーブのバイナリロギングをオフにします これを実現するには、
sql_log_bin = 0
を設定します。mysql.ndb_apply_status テーブルに使用されるストレージエンジンを変更します このテーブルが独自のバイナリロギングを処理しないエンジンを使用することになるため、競合も解消できます。これを行うには、スレーブで
ALTER TABLE mysql.ndb_apply_status ENGINE=MyISAM
などのステートメントを発行します。スレーブで非NDB
ストレージエンジンを使用する場合、この実行は安全です。これは、複数のスレーブ SQL ノードの同期の維持について気にする必要がないためです。スレーブでの mysql.ndb_apply_status テーブルへの変更を除外します これを行うには、スレーブの SQL ノードを
--replicate-ignore-table=mysql.ndb_apply_status
で起動します。レプリケーションでほかのテーブルを無視する必要がある場合、代わりに適切な--replicate-wild-ignore-table
オプションを使用することをお勧めします。
mysql.ndb_apply_status
のレプリケーションまたはバイナリロギングを無効にしたり、ある MySQL Cluster から別の MySQL Cluster に複製するときに、このテーブルに使用されるストレージエンジンを変更したりしないでください。詳細は、MySQL Cluster 間のレプリケーションで使用する、レプリケーションおよびバイナリロギングのフィルタリングルールを参照してください。
NDB から非トランザクションストレージエンジンへのレプリケーション
MyISAM
などの非トランザクションストレージエンジンに NDB
から複製する場合、INSERT ... ON DUPLICATE KEY UPDATE
ステートメントを複製するときに、不要な重複キーエラーが発生することがあります。これらを抑止するには、強制的に更新を (更新としてではなく) 書き込みとしてログを取るようにする --ndb-log-update-as-write=0
を使用します。
MySQL Cluster 間のレプリケーションで使用する、レプリケーションおよびバイナリロギングのフィルタリングルール
--replicate-do-*
、--replicate-ignore-*
、--binlog-do-db
、または --binlog-ignore-db
のいずれかのオプションを使用して、複製されるデータベースまたはテーブルを除外する場合、mysql.ndb_apply_status
のレプリケーションまたはバイナリロギングをブロックしないように注意する必要があります。このことは、MySQL Cluster 間のレプリケーションが適切に動作するために必要です。特に、次の点に留意しておく必要があります。
-
--replicate-do-db=
を使用すると (およびほかのdb_name
--replicate-do-*
または--replicate-ignore-*
オプションを使用しない)、データベースdb_name
にあるテーブルだけが複製されます。この場合、--replicate-do-db=mysql
、--binlog-do-db=mysql
、または--replicate-do-table=mysql.ndb_apply_status
も使用して、確実にmysql.ndb_apply_status
をスレーブに移入する必要があります。--binlog-do-db=
を使用すると (およびほかのdb_name
--binlog-do-db
オプションを使用しない)、データベースdb_name
にあるテーブルへの変更のみがバイナリログに書き込まれます。この場合、--replicate-do-db=mysql
、--binlog-do-db=mysql
、または--replicate-do-table=mysql.ndb_apply_status
も使用して、確実にmysql.ndb_apply_status
をスレーブに移入する必要があります。 -
--replicate-ignore-db=mysql
を使用すると、mysql
データベースにあるテーブルは複製されません。この場合、--replicate-do-table=mysql.ndb_apply_status
も使用して、確実にmysql.ndb_apply_status
を複製する必要があります。--binlog-ignore-db=mysql
を使用すると、mysql
データベースにあるテーブルへの変更はバイナリログに書き込まれません。この場合、--replicate-do-table=mysql.ndb_apply_status
も使用して、確実にmysql.ndb_apply_status
を複製する必要があります。
各レプリケーションルールには次のことも必要になります。
独自の
--replicate-do-*
または--replicate-ignore-*
オプション。複数のルールはレプリケーションの 1 つのフィルタリングオプションで表現できません。これらのルールについての情報は、セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。独自の
--binlog-do-db
または--binlog-ignore-db
オプション。複数のルールはバイナリログの 1 つのフィルタリングオプションで表現できません。これらのルールについての情報は、セクション5.2.4「バイナリログ」を参照してください。
NDB
以外のストレージエンジンを使用するスレーブに MySQL Cluster を複製する場合、このセクションの別のところで説明するように、直前で説明した考慮事項は当てはまりません。
MySQL Cluster レプリケーションと IPv6 現在、NDB API と MGM API は IPv6 をサポートしていません。ただし、MySQL Server (MySQL Cluster で SQL ノードとして動作する MySQL Server を含む) は IPv6 を使用してほかの MySQL Server に接続できます。つまり、次の図の点線の矢印で示すように、マスターとスレーブの SQL ノードを接続するために、IPv6 を使用して MySQL Cluster 間を複製できます。

ただし、MySQL Cluster 内で発生するすべての接続 (前の図の実線の矢印で示した接続) は IPv4 を使用する必要があります。言い換えると、すべての MySQL Cluster のデータノード、管理サーバー、および管理クライアントは、IPv4 を使用して互いにアクセスできる必要があります。また、SQL ノードは IPv4 を使用してクラスタと通信する必要があります。
現在、NDB と MGM の API では IPv6 をサポートしていないため、これらの API を使用して書かれたアプリケーションは、IPv4 を使用してすべての接続を作ることも必要です。
属性の昇格と降格
MySQL Cluster レプリケーションでは、属性の昇格と降格がサポートされています。後者の実装では、不可逆型と可逆型の変換は区別され、スレーブでのこれらの変換の使用は、slave_type_conversions
グローバルシステム変数を設定することで制御できます。
MySQL Cluster の属性の昇格と降格についての詳細は、行ベースレプリケーション: 属性の昇格と降格を参照してください。