Возможна репликация, где движок хранения на реплике отличается от движка на источнике. Например, вы можете реплицировать изменения в таблице InnoDB на источнике в таблицу MyISAM на реплике. Более подробную информацию см. в разделе 19.4.4, «Использование репликации с различными движками хранения источника и реплики».

Информацию о настройке реплики см. в разделе 19.1.2.6, «Настройка реплик» и разделе 19.1.2.5, «Выбор метода для создания моментальных снимков данных». Для создания новой реплики без остановки источника или существующей реплики используйте продукт MySQL Enterprise Backup.

Транзакции, которые завершаются неудачно на источнике, не влияют на репликацию. Репликация MySQL основана на двоичном журнале, в котором MySQL записывает SQL-операторы, изменяющие данные. Транзакция, завершившаяся неудачно (например, из-за нарушения внешнего ключа или из-за отката), не записывается в двоичный журнал, поэтому она не отправляется на реплики. См. раздел 15.3.1, «Операторы START TRANSACTION, COMMIT и ROLLBACK».

Репликация и CASCADE. Действия каскадного выполнения для таблиц InnoDB на источнике выполняются на реплике только если таблицы, имеющие отношение внешнего ключа, используют InnoDB как на источнике, так и на реплике. Это верно, независимо от того, используете ли вы репликацию на основе операторов или на основе строк. Предположим, что вы запустили репликацию, а затем создали две таблицы на источнике, где InnoDB определен как движок хранения по умолчанию, используя следующие операторы CREATE TABLE:

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 для fc1 не удаляет строки из таблицы fc2. Копия таблицы fc2 на реплике по-прежнему содержит все строки, которые были вставлены изначально:

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

Это различие обусловлено тем, что каскадные удаления обрабатываются внутренне движком хранения InnoDB, что означает, что ни одно из изменений не регистрируется.