NDB Cluster は非同期レプリケーションをサポートしており、通常は単に「「レプリケーション」」と呼ばれます。 このセクションでは、NDB Cluster として動作しているコンピュータの 1 つのグループが 2 つ目のコンピュータまたはコンピュータのグループにレプリケートする構成を設定および管理する方法について説明します。 標準の MySQL レプリケーションに関してはこのマニュアルで別途説明しています。 (第17章「レプリケーション」を参照してください。)

通常の (クラスタ化されていない) レプリケーションには、ソースサーバーとレプリカサーバー、レプリケートされる操作とデータの発生元であるために名前が付けられているソース、およびレプリカがこれらの受信者になります。 NDB Cluster では、レプリケーションは概念的に非常に似ていますが、2 つの完全なクラスタ間のレプリケーションを含む多数の異なる構成に対応するように拡張できるため、実際には複雑になることがあります。 NDB Cluster 自体はクラスタリング機能のために NDB ストレージエンジンに依存しますが、レプリケートされたテーブルのレプリカコピーのストレージエンジンとして NDB を使用する必要はありません (NDB から別のストレージエンジンへのレプリケーション を参照)。 ただし、可用性を最大限に高めるために、NDB Cluster 間でレプリケートすることが可能であり、次の図に示すように、このシナリオについて説明します:

図 23.31 NDB Cluster 間レプリケーションのレイアウト

このシナリオでは、レプリケーションプロセスは、ソースクラスタの連続した状態がログに記録され、レプリカクラスタに保存されるプロセスです。 このプロセスは NDB バイナリログインジェクタスレッドとして知られる特別なスレッドによって実行されます。このスレッドは各 MySQL サーバーで動作し、バイナリログ (binlog) を作成します。 このスレッドは、バイナリログを作成するクラスタのすべての変更 (MySQL Server を介して影響を受けた変更だけではありません) を、シリアライゼーションの正しい順序でバイナリログに挿入します。 MySQL ソースサーバーとレプリカサーバーをレプリケーションサーバーまたはレプリケーションノードと呼び、それらの間のデータフローまたは通信回線をレプリケーションチャネルと呼びます。

NDB Cluster および NDB Cluster レプリケーションを使用したポイントインタイムリカバリの実行については、セクション23.6.9.2「NDB Cluster レプリケーションを使用したポイントインタイムリカバリ」 を参照してください。

NDB API レプリカステータス変数.  NDB API カウンタは、レプリカクラスタで拡張モニタリング機能を提供できます。 これらのカウンタは、SHOW STATUS の出力に表示される NDB 統計_slave ステータス変数として、または NDB Cluster レプリケーションでレプリカとして機能している MySQL Server に接続されている mysql クライアントセッションのパフォーマンススキーマ session_status または global_status テーブルに対するクエリーの結果として実装されます。 レプリケートされた NDB テーブルに影響を与えるステートメントの実行前後にこれらのステータス変数の値を比較することで、NDB Cluster のレプリケーションをモニタリングまたはトラブルシューティングするときに役立つ可能性のある、NDB API レベルで実行された対応するアクションをレプリカで監視できます。セクション23.5.13「NDB API 統計のカウンタと変数」 では、追加情報が提供されます。

NDB テーブルから非 NDB テーブルへのレプリケーション.  レプリケーションソースとして機能する NDB Cluster から、複製 mysqld 上のほかの MySQL ストレージエンジン (InnoDB や MyISAM など) を使用してテーブルに NDB テーブルを複製できます。 これには多くの条件が適用されます。詳細については、NDB から別のストレージエンジンへのレプリケーションおよびNDB から非トランザクションストレージエンジンへのレプリケーションを参照してください。