Назад | Перейти на главную страницу

Дилемма формата binlog MySQL?

Версия MySQL: 5.5.13

Если я установил формат binlog на STATEMENT, Я получил следующие предупреждения на Мастере:

[Предупреждение] Небезопасный оператор записан в двоичный журнал с использованием формата оператора, поскольку BINLOG_FORMAT = STATEMENT. Оператор небезопасен, потому что он использует системную функцию, которая может возвращать другое значение на ведомом устройстве ...

Я также прочитал об ограничениях процедур и функций репликации хранилищ: http://dev.mysql.com/doc/refman/5.5/en/stored-programs-logging.html

Но если я перейду на MIXED, mysqld.log на рабе показывает:

[Предупреждение] Slave SQL: не удалось выполнить событие Update_rows для таблицы hdcn.sessions; Не удается найти запись в «сессиях», Error_code: 1032; ошибка обработчика HA_ERR_KEY_NOT_FOUND; главный журнал событий mysql-bin.003834, end_log_pos 602692401, Error_code: 1032

[Предупреждение] Slave SQL: не удалось выполнить событие Delete_rows для таблицы Reportingdb.102_rpt_clickview; Не удается найти запись в «102_rpt_clickview», код ошибки: 1032; ошибка обработчика HA_ERR_END_OF_FILE; главный журнал событий mysql-bin.003834, end_log_pos 725203511, Error_code: 1032

Похоже на MIXED Формат binlog приводит к тому, что Мастер не полностью реплицируется на Slave.

Я снова переключился на STATEMENT формат. Могу ли я игнорировать небезопасные предупреждения?

Я предполагаю, что вы сделали это на одной установке, не очищая ведомое устройство и не настраивая его с нуля.

Как сообщает сообщение об ошибке для репликации на основе операторов, ваше приложение использовало некоторые команды, которые не могут быть реплицированы с помощью репликации на основе операторов. Примером может служить запрос типа

INSERT INTO t (t) VALUES(NOW())

где NOW() вернет разные значения при выполнении на ведущем и ведомом.

Таким образом у вас будут разные данные на главном и подчиненном устройстве. Это плохо, поскольку в зависимости от вашего ведомого устройства ваши клиенты будут читать разные данные, а последующие записи изменят другие данные, поэтому вы получите данные, которые будут еще более разными.

Теперь вы переключаетесь на смешанную репликацию, при которой для некоторых операторов может использоваться построчная репликация. С RBR вам действительно нужны точно такие же данные, поскольку ему сложно идентифицировать строки, которые были изменены, и обновлять их.

Итак, что нужно сделать? - Настройте ведущее устройство для использования смешанного ведения журнала, а затем настройте ведомое устройство с использованием согласованного снимка.

Вы должны исключить все возможности вставок, обновлений, открытых временных таблиц и т. Д.

  1. на ведомом (ах): 
stop slave;
flush tables with read lock;
  1. на Мастере:
flush tables with read lock;
set global binlog_format='MIXED';
unlock tables;
  1. на ведомом (ах): 
unlock tables;
start slave;