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

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