При остановке и последующем запуске сервера-источника репликации его таблицы MEMORY становятся пустыми. Для репликации этого эффекта на репликах, при первом использовании сервером-источником таблицы MEMORY после запуска, записывается событие, уведомляющее реплики о необходимости очистить таблицу, выполнив оператор DELETE или TRUNCATE TABLE для этой таблицы в двоичный журнал. Это событие идентифицируется комментарием в двоичном журнале, и если на сервере используется GTID, ему присваивается GTID. Оператор всегда записывается в формате оператора, даже если формат двоичного логирования установлен в ROW, и он записывается даже если read_only или super_read_only режим установлен на сервере. Обратите внимание, что реплика всё ещё содержит устаревшие данные в таблице MEMORY в промежутке времени между перезапуском источника и первым использованием им таблицы. Чтобы избежать этого промежутка, когда прямой запрос к реплике может вернуть устаревшие данные, можно установить переменную среды init_file на имя файла, содержащего операторы, которые заполняют таблицу MEMORY на источнике при запуске.

При остановке и последующем запуске сервера-реплики его таблицы MEMORY становятся пустыми. Это приводит к рассогласованию реплики с источником и может привести к другим сбоям или к остановке реплики:

Реплика также записывает оператор DELETE или TRUNCATE TABLE в свой собственный двоичный журнал, который передаётся на любые последующие реплики, заставляя их очистить свои таблицы MEMORY.

Безопасный способ перезапуска реплики, которая выполняет репликацию таблиц MEMORY, заключается в предварительном удалении всех строк из таблиц MEMORY на источнике и ожидании, пока эти изменения не будут реплицированы на реплику. После этого можно безопасно перезапустить реплику.

В некоторых случаях может применяться альтернативный метод перезапуска. При значении binlog_format=ROW, можно предотвратить остановку реплики, установив значение replica_exec_mode=IDEMPOTENT перед повторным запуском реплики. Это позволяет реплике продолжить репликацию, но её таблицы MEMORY всё ещё отличаются от таблиц на источнике. Это приемлемо, если логика приложения такова, что содержимое таблиц MEMORY можно безопасно потерять (например, если таблицы MEMORY используются для кэширования). replica_exec_mode=IDEMPOTENT применяется глобально ко всем таблицам, поэтому он может скрывать другие ошибки репликации в таблицах, не являющихся MEMORY.

(Описанный метод не применим в NDB Cluster, где replica_exec_mode всегда IDEMPOTENT и не может быть изменён.)

Размер таблиц MEMORY ограничен значением переменной среды max_heap_table_size, которая не реплицируется (см. Раздел 19.5.1.39, «Репликация и переменные»). Изменение max_heap_table_size вступает в силу для таблиц MEMORY, которые созданы или обновлены с помощью ALTER TABLE ... ENGINE = MEMORY или TRUNCATE TABLE после изменения, или для всех таблиц MEMORY после перезапуска сервера. Если вы увеличите значение этой переменной на источнике, не сделав этого на реплике, то таблица на источнике может стать больше, чем её аналог на реплике, что приведёт к успешным операциям вставки на источнике, но к их провалу на реплике с ошибками Таблица полна. Это известная проблема (Ошибка #48666). В таких случаях необходимо установить глобальное значение max_heap_table_size как на реплике, так и на источнике, затем перезапустить репликацию. Также рекомендуется перезапустить как сервер MySQL-источника, так и сервер MySQL-реплики, чтобы обеспечить полное (глобальное) вступление в силу нового значения на каждом из них.

Дополнительную информацию о таблицах MEMORY см. в Разделе 18.3, «Двигатель хранения MEMORY».