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

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

Транзакции, которые завершаются неудачно на источнике, не влияют на репликацию. MySQL репликация основана на двоичном журнале, где MySQL записывает SQL-команды, изменяющие данные. Транзакция, завершившаяся неудачно (например, из-за нарушения ограничения внешнего ключа или из-за отката), не записывается в двоичный журнал, поэтому не отправляется на реплики. См. раздел 13.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 хранения, что означает, что ни одно из изменений не регистрируется.