Skip navigation links
MySQL 5.1 リファレンスマニュアル :: 14 MySQL Cluster :: 14.10 MySQL Cluster レプリケーション :: 14.10.4 レプリケーション スキーマおよびテーブル
14.10.5 レプリケーションにクラスタを準備する »
Section Navigation      [Toggle]

14.10.4. レプリケーション スキーマおよびテーブル

MySQL Cluster でのレプリケーションではレプリケートされるクラスタおよびレプリケーション スレーブ （単一のサーバーあるいはクラスタのいずれか） としての役割を果たす各 MySQL Server インスタンスの mysql データベースの多くの専用のテーブルを使用しています。これらのテーブルは mysql_install_db スクリプトによって MySQL のインストール中に作成され、バイナリ ログのインデックス データを保存するテーブルを含んでいます。ndb_binlog_index テーブルは各 MySQL サーバーに対してはローカルで、クラスタ化には使用されず、MyISAM ストレージ エンジンを使用します。このことはそれはマスタのクラスタに使用される各 mysqld で個別に作成されることを意味しています。(しかし、binlog そのものはレプリケートされるクラスタの MySQL サーバーの更新を含んでいます。）このテーブルは以下のように定義されます。 

        
CREATE TABLE `ndb_binlog_index` (
          `Position`  BIGINT(20) UNSIGNED NOT NULL,
          `File`      VARCHAR(255) NOT NULL,
          `epoch`     BIGINT(20) UNSIGNED NOT NULL,
          `inserts`   BIGINT(20) UNSIGNED NOT NULL,
          `updates`   BIGINT(20) UNSIGNED NOT NULL,
          `deletes`   BIGINT(20) UNSIGNED NOT NULL,
          `schemaops` BIGNINT(20) UNSIGNED NOT NULL,
          PRIMARY KEY (`epoch`)
) ENGINE=MYISAM  DEFAULT CHARSET=latin1;

重要MySQL 5.1.14 以前のバージンでは、ndb_binlog_index テーブルは binlog_index として知られ個別 cluster データベースで維持され、それは MySQL 5.1.7 あるいはそれ以前のバージョンでは cluster_replication データベースとして知られていました。同様に、ndb_apply_status および ndb_schema テーブルは apply_status および schema として知られており、cluster (以前は cluster_replication) データベースにありました。しかし、MySQL 5.1.14 以降では、すべての MySQL Cluster のレプリケーション テーブルは mysql システム データベースにあります。

この変更が MySQL Cluster 5.1.13 および 5.1.14 およびそれ以降のバージョンのアップグレードに影響を及ぼすかは 項C.1.3. 「Changes in release 5.1.14 (05 December 2006)」 を参照してください。

以下の図は MySQL Cluster のレプリケーション マスタ サーバー、その binlog インジェクタースレッド、および mysql.ndb_binlog_index テーブルのレプリケーションを表しています。

レプリケーション マスタ クラスタ、binlog インジェクタースレッド、および ndb_binlog_index テーブル

ndb_apply_status の名前の新たなテーブルがマスタからスレーブにレプリケートされたオペレーションの記録を取るために使用されます。ndb_binlog_index の場合と違って、このテーブルのデータはクラスタのどの SQL ノード独自おものではないため、 ndb_apply_status は以下に示すように NDB Cluster ストレージ エンジンを使用できます。 

CREATE TABLE `ndb_apply_status` (
    `server_id` INT(10) UNSIGNED NOT NULL,
    `epoch`     BIGINT(20) UNSIGNED NOT NULL,
    PRIMARY KEY  USING HASH (`server_id`)
) ENGINE=NDBCLUSTER  DEFAULT CHARSET=latin1;

ndb_binlog_index および ndb_apply_status テーブルはそれらがレプリケートされる必要が無いため mysql データベースで作成されます。それらのいずれの作成および維持に関してユーザーが関与することは通常ありません。ndb_binlog_index および ndb_apply_status テーブルの双方は NDB インジェクタースレッドで維持されます。これが NDB ストレージ エンジンで実行される変更に対する更新されたマスタ mysqld プロセスを維持します。NDB binlog インジェクター スレッドは NDB ストレージ エンジンから直接イベントを受け取ります。NDB インジェクターはクラスタのすべてのデータ イベントの取得を行い、データの変更、挿入、あるいは削除するすべてのイベントが ndb_binlog_index テーブルに記録されたことを確認します。スレーブ I/O スレッドはイベントをマスタのバイナリ ログからスレーブのリレーログに転送します。

しかし、これらのテーブルの存在と品質をレプリケーションに MySQL Cluster を準備する初期のステップで確認することをお勧めします。マスタで直接 mysql.binlog_index テーブルをクエリするとバイナリ ログに記録されたイベント データを表示できます。これをレプリケーション マスタあるいはスレーブ MySQL サーバーのいずれかの SHOW BINLOG EVENTS ステートメントを使用して表示することもできます。

注:MySQL 5.1.14 以降では、apply_status テーブルがスレーブに無い場合、ndb_restore で作成できます。(Bug#14612)