レプリカ上のストレージエンジンがソース上のストレージエンジンと同じでない方法でレプリケーションを使用できます。 たとえば、ソースの 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 ストレージエンジンによって内部的に処理されることから来ています。つまり、どの変更もログに記録されません。