Можно использовать репликацию таким образом, чтобы движок хранения на реплике не совпадал с движком хранения на источнике. Например, вы можете реплицировать изменения в таблице 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, что означает, что ни одно из изменений не регистрируется.