MySQL Cluster のレプリケーション スレーブ mysqld はマスタの接続が切断され、ログがバッファされないことを検知する方法がありません。このため、マスタが使用できなくなったりあるいはネットワークの問題が発生した場合、スレーブがマスタに対して一貫性が無くなる場合があります。

この問題を避けるために、複数のレプリケーション ラインを設け、プライマリのレプリケーション ラインでマスタ mysqld を監視し、必要に応じてフェールオーバーを 2 次側のラインに設定します。

この種の設定を行うための情報に関しては、項14.10.7. 「2 つのレプリケーション チャネルを使用する」、および 項14.10.8. 「MySQL Cluster にフェールオーバーを導入する」 を参照してください。

弊社では現在この問題の解決策を今後の MySQL Cluster のリリースも含めて検討しています。(この問題に関する説明は Bug#21494　にあります。)

循環的なレプリケーションはクラスタのレプリケーションではサポートしていません。これは特定の MySQL Cluster で作成されたすべてのログ イベントの マスタとして使用されている MySQL サーバーサーバーID のタグが間違っており、元のサーバーのサーバーID ではないからです。

その ID の間違いにより、MySQL サーバー A→B→A、そこでは B はクラスタ A に接続された MySQL サーバーで、クラスタ テーブル A からの変更 (ログ エントリ） により元のサーバーの識別名をB から A で失う 「lose」 からです。これによりその変更はサーバー A に再び適用されます。

CREATE TABLE、DROP TABLE、および ALTER TABLE などのデータ定義ステートメントを使用はバイナリのログにそれが発行された MySQL サーバーにのみ記録されます。

MySQL 5.1.6 では、明示のプライマリ キーを持つNDB のみがレプリケートされます。この制限は MySQL 5.1.7 が解除されています。

クラスタを --initial オプションで再起動すると GCI およびエポック番号が 0 から始まります。(これは一般的には MySQL Cluster では当たり前でクラスタを使用したレプリケーションのシナリオに限ったことではありません。レプリケーションに使用された MySQL サーバーはこの場合レプリケートされます。この後、RESET MASTER および RESET SLAVE ステートメントを使用して ndb_binlog_index および ndb_apply_status テーブルをそれぞれクリアします。

auto_increment_offset および auto_increment_increment サーバーシステムに変数を設定しようとすると予測できない結果がでます。これらの変数の使用は MySQL Cluster のレプリケーションではサポートされていません。