Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


MySQL 8.0 リファレンスマニュアル  / InnoDB ストレージエンジン  /  InnoDB と MySQL レプリケーション

このページは機械翻訳したものです。

15.19 InnoDB と MySQL レプリケーション

レプリカ上のストレージエンジンがソース上のストレージエンジンと同じでない方法でレプリケーションを使用できます。 たとえば、ソースのInnoDB テーブルに対する変更をレプリカのMyISAM テーブルにレプリケートできます。 詳細は、セクション17.4.4「異なるソースおよびレプリカのストレージエンジンでのレプリケーションの使用」 を参照してください。

レプリカの設定の詳細は、セクション17.1.2.6「レプリカの設定」 およびセクション17.1.2.5「データスナップショットの方法の選択」 を参照してください。 ソースまたは既存のレプリカを停止せずに新しいレプリカを作成するには、MySQL Enterprise Backup 製品を使用します。

ソースで失敗したトランザクションはレプリケーションに影響しません。 MySQL レプリケーションは、データを変更する SQL ステートメントが MySQL によって書き込まれたバイナリログに基づいています。 失敗したトランザクション (外部キー違反やロールバックされたためなど) はバイナリログに書き込まれないため、レプリカには送信されません。セクション13.3.1「START TRANSACTION、COMMIT および ROLLBACK ステートメント」を参照してください。

レプリケーションと CASCADE.  外部キーリレーションを共有するテーブルがソースとレプリカの両方でInnoDB を使用する場合、ソース上のInnoDB テーブルのカスケードアクションはレプリカのみでレプリケートされます。 これは、ステートメントベースのレプリケーションと行ベースのレプリケーションのどちらを使用している場合にも当てはまります。 レプリケーションを開始し、次のCREATE TABLE ステートメントを使用して、InnoDB がデフォルトのストレージエンジンとして定義されているソースに 2 つのテーブルを作成するとします:

CREATE TABLE fc1 (    i INT PRIMARY KEY,    j INT);CREATE TABLE fc2 (    m INT PRIMARY KEY,    n INT,    FOREIGN KEY ni (n) REFERENCES fc1 (i)        ON DELETE CASCADE);

レプリカにデフォルトのストレージエンジンとして定義されたMyISAM がある場合、レプリカ上に同じテーブルが作成されますが、それらはMyISAM ストレージエンジンを使用し、FOREIGN KEY オプションは無視されます。 次に、ソースのテーブルにいくつかの行を挿入します:

source> INSERT INTO fc1 VALUES (1, 1), (2, 2);Query OK, 2 rows affected (0.09 sec)Records: 2  Duplicates: 0  Warnings: 0source> INSERT INTO fc2 VALUES (1, 1), (2, 2), (3, 1);Query OK, 3 rows affected (0.19 sec)Records: 3  Duplicates: 0  Warnings: 0

この時点で、次に示すように、ソースとレプリカの両方で、テーブルfc1 には 2 行、テーブルfc2 には 3 行が含まれます:

source> SELECT * FROM fc1;+---+------+| i | j    |+---+------+| 1 |    1 || 2 |    2 |+---+------+2 rows in set (0.00 sec)source> SELECT * FROM fc2;+---+------+| m | n    |+---+------+| 1 |    1 || 2 |    2 || 3 |    1 |+---+------+3 rows in set (0.00 sec)replica> SELECT * FROM fc1;+---+------+| i | j    |+---+------+| 1 |    1 || 2 |    2 |+---+------+2 rows in set (0.00 sec)replica> SELECT * FROM fc2;+---+------+| m | n    |+---+------+| 1 |    1 || 2 |    2 || 3 |    1 |+---+------+3 rows in set (0.00 sec)

ここで、ソースで次のDELETE ステートメントを実行するとします:

source> DELETE FROM fc1 WHERE i=1;Query OK, 1 row affected (0.09 sec)

カスケードのため、ソースのテーブルfc2 には 1 行のみが含まれるようになりました:

source> SELECT * FROM fc2;+---+---+| m | n |+---+---+| 2 | 2 |+---+---+1 row in set (0.00 sec)

ただし、レプリカではDELETE forfc1fc2 から行を削除しないため、カスケードはレプリカに伝播されません。fc2 のレプリカコピーには、最初に挿入されたすべての行が引き続き含まれます:

replica> SELECT * FROM fc2;+---+---+| m | n |+---+---+| 1 | 1 || 3 | 1 || 2 | 2 |+---+---+3 rows in set (0.00 sec)

この違いは、カスケード削除が、実際にはInnoDB ストレージエンジンによって内部的に処理されることから来ています。つまり、どの変更もログに記録されません。