MySQL集群でのレプリケーションでは,複製されるクラスタとレプリケーションスレーブ(スレーブは単一のサーバーである場合やクラスタである場合があります)の両方でSQLノードとしての役割を果たす各MySQL服务器インスタンス上のmysqlデタベスの数多くの専用のテブルを使用します。これらのテブルはmysql_install_dbスクリプトによってMySQLのインストールプロセス中に作成され,バイナリログのインデックスデータを保存するテーブルを含みます。ndb_binlog_indexテブルは各MySQLサMyISAMストレジエンジンを使用します。すなわ，これは各mysqldで個別に作成され，マスタクラスタに参加する必要があります。（ただし、バイナリログ自身には、複製されるクラスタ内にあるすべての MySQL サーバーからの更新が含まれます。)このテーブルは次のように定義されます。

CREATE TABLE ' ndb_binlog_index ' (' Position ' BIGINT(20) UNSIGNED NOT NULL， ' File ' VARCHAR(255) NOT NULL， ' epoch ' BIGINT(20) UNSIGNED NOT NULL， ' insert ' INT(10) UNSIGNED NOT NULL， ' update ' INT(10) UNSIGNED NOT NULL， ' schemaops ' INT(10) UNSIGNED NOT NULL， ' orig_server_id ' INT(10) UNSIGNED NOT NULL， ' orig_epoch ' BIGINT(20) UNSIGNED NOT NULL， ' gci ' INT(10) UNSIGNED NOT NULL， ' next_position ' BIGINT(20) UNSIGNED NOT NULL， ' next_file ' VARCHAR(255) NOT NULL， '主键(' epoch '， ' orig_server_id '， ' orig_epoch '))

このテーブルのサイズは,バイナリログファイル当たりのエポック数およびバイナリログファイル数に依存します。一般的に,バイナリログファイル当たりのエポック数は,エポックごとに作成されるバイナリログの量とバイナリログファイルのサイズに依存し,エポックが小さくなるとファイル当たりのエポックが増えます。空のエポックは，——ndb-log-empty-epochsオプションが从のときでも，ndb_binlog_indexテーブルに挿入される結果となり,ファイル当たりのエントリ数はファイルが使用中である時間の長さに依存する点に注意してください。すなわ，次のとおりです。

[每个文件的周期数]=[每个文件所花费的时间]/ TimeBetweenEpochs

ビジーなMySQL集群は定期的にバイナリログに書き込み,おそらく,ビジーでないMySQL集群よりも頻繁にバイナリログファイルを交替します。すなわ，——ndb-log-empty-epochs =である「ビジでない」MySQL集群は大量のアクティビティーを持つMySQL集群に比べて,実際にはファイル当たりのndb_binlog_index行数をかなり多く持ことができます。

mysqldが——ndb-log-origオプションで起動されると，orig_server_idとorig_epochのカラムに,それぞれ,イベントが発生したサーバーのIDとイベントが発生元のサーバーで行なったエポックが格納されます。これは,複数のマスターを使用するMySQL集群のレプリケーションのセットアップに役立ちます。マルチマスターのセットアップでスレーブに適用されるいちばん高いエポックにいちばん近いバイナリログの位置を検出するために使用される选择ステトメントは(セクション18.6.10“MySQL集群レプリケーション:マルチマスターと循環レプリケーション”を参照してください)，これら2のカラム(ンデックス化されていません)を使用します。これにより，特にマスタが——ndb-log-empty-epochs =で実行しているときに,クエリーはテーブルスキャンを実行しなければならないため,フェイルオーバーを試みるときにパフォーマンスの問題につながる可能性があります。ここで示すように,これらのカラムにインデックスを追加することで,マルチマスターのフェイルオーバー時間を改善できます。

ALTER TABLE mysql。ndb_binlog_indexADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch);

このインデックスを追加しても,1つのマスターから1つのスレーブに複製する場合はメリットがありません。これは、このような場合にバorig_server_idまたはorig_epochを利用しないためです。

next_positionおよびnext_fileカラムの使用にいての詳細は，セクション18.6.8“MySQL集群レプリケーションを使用したフェイルオーバーの実装”を参照してください。

次の図は,MySQL集群レプリケーションのマスターサーバー,そのバイナリログのインジェクタスレッド,およびmysql.ndb_binlog_indexテブルの関係を示します。

ndb_apply_statusという名前の追加テブルは，マスタブに複製された操作の記録を取るために使用されます。ndb_binlog_indexの場合と異なり,このテーブルのデータは(スレーブ)クラスタのどのSQLノードにも特定されていないため,ここで示すように,ndb_apply_statusはNDBCLUSTERストレジエンジンを使用できます。

CREATE TABLE ' ndb_apply_status ' (' server_id ' INT(10) UNSIGNED NOT NULL， ' epoch ' BIGINT(20) UNSIGNED NOT NULL， ' log_name ' VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL， ' start_pos ' BIGINT(20) UNSIGNED NOT NULL， ' end_pos ' BIGINT(20) UNSIGNED NOT NULL， ' server_id ') USING HASH) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;

ndb_apply_statusテブルはスレブでのみ移入されます。このことは，マスタ，では，このテ，ブルに行は含まれないことを意味しています。このため，ここでndb_apply_statusに割り当てられるDataMemoryまたはIndexMemoryを考慮する必要がありません。

このテブルはマスタで発生したデタから移入されるため，複製は許可されます。ただし,レプリケーションのフィルタリングルールまたはバイナリログのフィルタリングルールによって,意図せずにスレーブがndb_apply_statusを更新しなかったり,マスターがバイナリログに書き込まなかったりすると,クラスタ間のレプリケーションが正しく動作しない場合があります。このようなフィルタリングルルに起因する潜在的な問題の詳細は，MySQL集群間のレプリケーションで使用する,レプリケーションおよびバイナリロギングのフィルタリングルールを参照してください。

ndb_binlog_indexとndb_apply_statusのテブルは，ユによって明示的に複製されることはないため，mysqlデタベスに作成されます。通常，これらのテらかを作成または維持するには，ユの介入は必要ありません。ndb_binlog_indexとndb_apply_statusの両方ともNDBバereplicationナリログ(binlog)のereplicationンジェクタスレッドによって維持されるためです。これにより，マスタのmysqldプロセスは，NDBストレジエンジンによって実行された変更への更新が維持されます。NDBBinlog邮箱ンジェクタスレッドはNDBストレジエンジンから直接。NDBインジェクタは,クラスタ内のすべてのデータイベントを取得する役割を担い,データを変更,挿入,または削除するすべてのイベントがndb_binlog_indexテブルに記録されたかを確認します。スレーブのI / Oスレッドは,マスターのバイナリログからスレーブのリレーログにイベントを転送します。

ただし,レプリケーション用にMySQL集群を準備する初期の段階で,これらのテーブルの存在と完全性を確認することをお勧めします。マスタでmysql.ndb_binlog_indexテブルに直接クエリを発行することで，バ。これは，レプリケションマスタまたはスレブのMySQLサバのどらかで显示BINLOG的事件ステトメントを使用して実現することもできます。（セクション13.7.5.3 " show binlog events構文"を参照してください。)

显示引擎NDB状态の出力から有効な情報を取得することもできます。

ndb_schemaテブルは，NDBテブルに行われたスキマの変更を追跡するために使用されます。ここで示すように定義されます。

CREATE TABLE ndb_schema (' db ' VARBINARY(63) NOT NULL， ' name ' VARBINARY(63) NOT NULL， ' slock ' BINARY(32) NOT NULL， ' query ' BLOB NOT NULL， ' node_id ' INT UNSIGNED NOT NULL， ' epoch ' BIGINT UNSIGNED NOT NULL， ' id ' INT UNSIGNED NOT NULL， ' version ' INT UNSIGNED NOT NULL， ' type ' INT UNSIGNED NOT NULL， ' PRIMARY KEY USING HASH (db,name)) ENGINE=NDB DEFAULT CHARSET=latin1;

このセクションで前に述べた2のテブルとは異なり，ndb_schemaテブルはMySQL显示ステトメントでも，INFORMATION_SCHEMAテブルでも参照できません。ただし，ここで示すように，ndb_show_tablesの出力で参照できます。

shell> ndb_show_tables -t 2 id type state logging database schema name 4 UserTable Online Yes mysql def ndb_apply_status 5 UserTable Online Yes ndbworld def City 6 UserTable Online Yes ndbworld def Country 3 UserTable Online Yes mysql def NDB$ blob__3 7 UserTable Online Yes ndbworld def CountryLanguage . shell2 UserTable Online是mysql def ndb_schemaNDBT_ProgramExit: 0 - OK

ここで示すように，mysqlおよびほかのMySQLクラ选择を発行することも可能です。

mysql> SELECT * FROM mysql。ndb_schemaWHERE name='City' \G *************************** 1. row *************************** db: ndbworld name: City slock: query: alter table City engine=ndb node_id: 4 epoch: 0 id: 0 version: 0 type: 7 1 row in set (0.00 sec)

これは，アプリケションのデバッグで有効となる場合があります。

ndb_apply_statusテブルまたはndb_schemaテブルがスレブに存在しない場合，ndb_restoreは存在しないテブル(または複数のテブル)を再作成します(Bug #14612)。

MySQL集群レプリケションの競合の解決には，追加のmysql.ndb_replicationテブルが必要です。現在，このテブルは手動で作成する必要があります。これを行う方法にいては，セクション18.6.11 " MySQL集群レプリケションの競合解決"を参照してください。