可以以一种方式使用复制，使得副本上的存储引擎与源上的存储引擎不同。例如，可以将源上的 InnoDB 表的修改复制到副本上的 MyISAM 表。更多信息请参见 第 19.4.4 节，“使用不同源和副本存储引擎的复制”。It is possible to use replication in a way where the storage engine on the replica is not the same as the storage engine on the source. For example, you can replicate modifications to an InnoDB table on the source to a MyISAM table on the replica. For more information see, Section 19.4.4, “Using Replication with Different Source and Replica Storage Engines”.

有关设置副本的信息，请参见第 19.1.2.6 节，“设置副本”，以及第 19.1.2.5 节，“选择数据快照的方法”。若要在不中断源或现有副本的情况下创建新副本，请使用MySQL 企业备份产品。For information about setting up a replica, see Section 19.1.2.6, “Setting Up Replicas”, and Section 19.1.2.5, “Choosing a Method for Data Snapshots”. To make a new replica without taking down the source or an existing replica, use the MySQL Enterprise Backup product.

在源端失败的事务不会影响复制。MySQL 复制是基于二进制日志的，MySQL 会在其中写入修改数据的 SQL 语句。一个失败的事务（例如，由于外键约束违规，或者事务被回滚）不会被写入二进制日志，因此不会发送到副本。参见 第 15.3.1 节，“START TRANSACTION、COMMIT 和 ROLLBACK 语句”。Transactions that fail on the source do not affect replication. MySQL replication is based on the binary log where MySQL writes SQL statements that modify data. A transaction that fails (for example, because of a foreign key violation, or because it is rolled back) is not written to the binary log, so it is not sent to replicas. See Section 15.3.1, “START TRANSACTION, COMMIT, and ROLLBACK Statements”.

Replication and CASCADE.  Cascading actions for InnoDB tables on the source are executed on the replica 生成的值 if the tables sharing the foreign key relation use InnoDB on both the source and replica. This is true whether you are using statement-based or row-based replication. Suppose that you have started replication, and then create two tables on the source, where InnoDB is defined as the default storage engine, using the following CREATE TABLE有几个原因Replication and CASCADE.  Cascading actions for InnoDB tables on the source are executed on the replica only if the tables sharing the foreign key relation use InnoDB on both the source and replica. This is true whether you are using statement-based or row-based replication. Suppose that you have started replication, and then create two tables on the source, where InnoDB is defined as the default storage engine, using the following CREATE TABLE statements:

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 选项将被忽略。现在我们在源上向表中插入一些行：If the replica has MyISAM defined as the default storage engine, the same tables are created on the replica, but they use the MyISAM storage engine, and the FOREIGN KEY option is ignored. Now we insert some rows into the tables on the source:

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 行，如下所示：At this point, on both the source and the replica, table fc1 contains 2 rows, and table fc2 contains 3 rows, as shown here:

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 语句：Now suppose that you perform the following DELETE statement on the source:

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

由于级联作用，源上的表 fc2 现在只包含 1 行：Due to the cascade, table fc2 on the source now contains only 1 row:

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

然而，级联操作不会在副本上传播，因为在副本上，DELETE 对 fc1 并未删除 fc2 中的任何行。副本中的 fc2 副本仍然包含最初插入的所有行：However, the cascade does not propagate on the replica because on the replica the DELETE for fc1 deletes no rows from fc2. The replica's copy of fc2 still contains all of the rows that were originally inserted:

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

这种差异是由于级联删除是由 InnoDB 存储引擎在内部处理的，这意味着没有任何更改被记录在日志中。This difference is due to the fact that the cascading deletes are handled internally by the InnoDB storage engine, which means that none of the changes are logged.