Spec-Zone .ru
спецификации, руководства, описания, API
|
Когда главный сервер завершает работу и перезапускает, MEMORY
таблицы становятся пустыми. Тиражировать этот эффект в ведомые устройства,
в первый раз, когда ведущее устройство использует данный MEMORY
таблица после запуска, это регистрирует событие, которое уведомляет
ведомые устройства, что таблица должна, чтобы быть освобожденной при записи a DELETE
оператор для той таблицы к двоичному журналу.
Когда ведомый сервер завершает работу и перезапускает, MEMORY
таблицы становятся пустыми. Это заставляет ведомое устройство испытывать
недостаток синхронии с ведущим устройством и может привести к другим отказам или заставить ведомое устройство
останавливаться:
Формат строки обновляет и удаляет полученный от ведущего устройства, может
перестать работать с Can't find record in '
.
memory_table
'
Операторы такой как INSERT INTO ... SELECT FROM
может вставить различный набор строк
на ведущем устройстве и ведомом устройстве.memory_table
Безопасный способ перезапустить ведомое устройство, которое тиражируется MEMORY
таблицы должны сначала отбросить или удалить все строки из MEMORY
таблицы на ведущем устройстве и ожидают, пока те изменения не
тиражировались к ведомому устройству. Затем безопасно перезапустить ведомое устройство.
Альтернативный метод перезапуска может применяться в некоторых случаях. Когда binlog_format=ROW
, можно препятствовать тому, чтобы ведомое устройство
остановилось, если Вы устанавливаете slave_exec_mode=IDEMPOTENT
прежде, чем Вы запустите ведомое устройство снова.
Это позволяет ведомому устройству продолжать тиражироваться, но MEMORY
таблицы будут все еще отличаться от тех на ведущем устройстве. Это
может быть хорошо, если логика приложения является так, что содержанием MEMORY
таблицы могут быть безопасно потеряны (например, если MEMORY
таблицы используются для того, чтобы кэшироваться). slave_exec_mode=IDEMPOTENT
применяется глобально ко всем таблицам, таким
образом, это может скрыть другие ошибки репликации в не -MEMORY
таблицы.
Размер MEMORY
таблицы ограничиваются
значением max_heap_table_size
системная переменная, которая не тиражируется (см. Раздел
16.4.1.33, "Репликация и Переменные"). Изменение в max_heap_table_size
вступает в силу для MEMORY
таблицы, которые составляются или обновили использование ALTER TABLE ... ENGINE = MEMORY
или TRUNCATE TABLE
после изменения, или для всех MEMORY
таблицы после перезапуска сервера. Если Вы увеличиваете значение этой
переменной на ведущем устройстве, не делая так на ведомом устройстве, для таблицы на ведущем устройстве
становится возможно вырасти чем ее дубликат на ведомом устройстве, приведение вставляет, которые успешно
выполняются на ведущем устройстве, но сбой на ведомом устройстве с Таблицей является полными
ошибками. Это - известная проблема (Ошибка #48666). В таких случаях следует установить глобальное значение max_heap_table_size
на ведомом устройстве так же как на ведущем устройстве, затем перезапустите репликацию. Также рекомендуется,
чтобы Вы перезапустили и основные и ведомые серверы MySQL, чтобы обеспечить, чтобы новое значение взяло полный
(глобальный) эффект на каждого из них.
См. Раздел
14.4," MEMORY
Механизм хранения", для получения дополнительной
информации о MEMORY
таблицы.