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

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)

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

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