MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
レプリカ上のストレージエンジンがソース上のストレージエンジンと同じでない方法でレプリケーションを使用できます。 たとえば、ソースの 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: 0 source>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
for fc1
は fc2
から行を削除しないため、カスケードはレプリカに伝播されません。 fc2
のレプリカコピーには、最初に挿入されたすべての行が引き続き含まれます:
replica> SELECT * FROM fc2;
+---+---+
| m | n |
+---+---+
| 1 | 1 |
| 3 | 1 |
| 2 | 2 |
+---+---+
3 rows in set (0.00 sec)
この違いは、カスケード削除が、実際には InnoDB
ストレージエンジンによって内部的に処理されることから来ています。つまり、どの変更もログに記録されません。