16.2.2. Реле репликации и Журналы Состояния

16.2.2.1. Ведомый Релейный Журнал
16.2.2.2. Ведомые Журналы Состояния

Во время репликации ведомый сервер создает несколько журналов, которые проводят двоичные мероприятия журнала, переданные от ведущего устройства к ведомому устройству, и записывать информацию о текущем статусе и расположении в пределах релейного журнала. Есть три типа журналов, используемых в процессе, перечисленных здесь:

Релейный журнал состоит из событий, считанных из двоичного журнала ведущего устройства и записанный ведомым потоком ввода-вывода. События в релейном журнале выполняются на ведомом устройстве как часть потока SQL.
Основной журнал информации содержит состояние и текущую конфигурационную информацию для соединения ведомого устройства с ведущим устройством. Этот журнал содержит информацию об основном имени хоста, учетных данных входа в систему, и координатах, указывающих, как далеко ведомое устройство читало из двоичного журнала ведущего устройства.

До MySQL 5.6 этот журнал всегда был файлом (master.info), но в MySQL 5.6 и позже, этот журнал может быть записан mysql.slave_master_info таблица вместо файла, запуская ведомое устройство с --master-info-repository=TABLE.
Релейный журнал информации журнала содержит информацию о статусе о точке выполнения в пределах релейного журнала ведомого устройства.

До MySQL 5.6 этот журнал всегда был файлом (relay-log.info), но в MySQL 5.6 и позже, этот журнал может быть записан mysql.slave_relay_log_info таблица вместо файла, запуская ведомое устройство с --relay-log-info-repository=TABLE.

До MySQL 5.6.7, Master_id столбец slave_master_info и slave_relay_log_info таблицы показывали ID сервера ведомого устройства вместо ID сервера ведущего устройства. (Ошибка #12334346)

Для репликации, чтобы быть безопасными от катастрофического отказа при использовании таблиц для того, чтобы зарегистрировать состояние и релейную информацию, таблицы должны использовать транзакционный механизм хранения, такой как InnoDB. Начинаясь с MySQL 5.6.6, эти таблицы составляются, используя InnoDB. (Ошибка #13538891)

Отметить

Чтобы гарантировать безопасность при столкновении на ведомом устройстве, следует также выполнить ведомое устройство с --relay-log-recovery включенный.

До MySQL 5.6.6, если mysqld был неспособен инициализировать таблицы журналирования репликации, ведомое устройство, которому отказывают, чтобы запуститься. В MySQL 5.6.6 и позже, дается предупреждение, когда это происходит, но ведомому устройству позволяют продолжать запускаться. (Ошибка #13971348) Эта ситуация, наиболее вероятно, произойдет, обновляя от версии MySQL, который не поддерживает ведомые таблицы журналирования к тому, в котором они поддерживаются.

В MySQL 5.6.5 и ранее, slave_master_info и slave_relay_log_info таблицы используются MyISAM по умолчанию, который означал, что было необходимо перед запускающейся репликацией изменить механизм хранения, используемый этими таблицами, выходя ALTER TABLE ... ENGINE=InnoDB, как показано здесь:

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;

ALTER TABLE операторы должны быть выполнены MySQL root или другая учетная запись пользователя с соответствующими полномочиями на mysql база данных. Недопустимо попытаться сделать это, в то время как репликация работает; начинание с MySQL 5.6.3, попытка выполниться ALTER TABLE на любой этих отвергаются таблицы, в то время как репликация является продолжающейся. Запускаясь с MySQL 5.6.4, выполнение любого оператора, требующего записи, соединяется или или обе из этих таблиц, отвергается, в то время как репликация продолжающаяся, в то время как операторы, которые выполняют только чтения, разрешаются в любое время.

Важный

Не пытайтесь обновить или вставить строки в slave_master_info или slave_relay_log_info представьте в виде таблицы вручную. Выполнение так может вызвать неопределенное поведение, и не поддерживается.

До MySQL 5.6.4 mysqldump не выводил таблицы журнала репликации, если они не были определены по имени и --master-data опция использовалась.