18.6.3 MySQL Cluster レプリケーションの既知の問題

このセクションでは、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 間のレプリケーションが適切に動作するために必要です。特に、次の点に留意しておく必要があります。

1. --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 をスレーブに移入する必要があります。

2. --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 を複製する必要があります。

各レプリケーションルールには次のことも必要になります。

1. 独自の --replicate-do-* または --replicate-ignore-* オプション。複数のルールはレプリケーションの 1 つのフィルタリングオプションで表現できません。これらのルールについての情報は、セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

2. 独自の --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 の属性の昇格と降格についての詳細は、行ベースレプリケーション: 属性の昇格と降格を参照してください。