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

Обновления пакетов MySQL (Debian apt-get) всегда прерывают репликацию мастер-мастер из-за изменений в схеме mysql

У меня есть репликация мастер-мастер, настроенная на 2 серверах Debian, и они реплицируют все, включая саму базу данных mysql (так что новые пользователи и тому подобное также реплицируются). Обычно это работает очень хорошо, за исключением того, что большинство, если не все, обновления apt до mysql включают некоторые изменения в схеме базы данных mysql, которые вызывают ошибки репликации, которые останавливают репликацию. В конце концов, мне всегда нужно исправить вручную, пропуская ошибочные утверждения с каждой стороны. Это всегда отнимает много времени, и я беспокоюсь, что могу сделать ошибки, делая это вручную (пропускание слишком большого количества операторов, опечатка в деталях CHANGE MASTER и т.д.).

Могу ли я что-то сделать, чтобы гарантировать, что обновления MySQL с помощью apt-get в будущем будут обрабатываться плавно, не вызывая проблем с репликацией? Конечно, для этого есть устоявшаяся передовая практика?

Я не знаю, будет ли это работать для всех возможных сценариев обновления, но я только что протестировал это, и обновление прошло без каких-либо проблем с репликацией:

# /etc/mysql/conf.d/binlog_ignoredb_mysql.cnf.disabled
# Rename this to end in .cnf prior to performing `apt-get upgrade`.
# Otherwise, its attempts to `ALTER TABLE users` will cause replication errors.
# After upgrade is complete, rename back to .disabled and then /etc/init.d/mysql restart

[mysqld]
binlog-ignore-db=mysql

Обратите внимание, что мой тест проводился при небольшом обновлении (с 5.5.41 до 5.5.43).

Было бы неплохо узнать, какие команды нарушили вашу репликацию, но я полагаю, что скрипт mysql_upgrade будет таким мошенником. Если да, вы можете пересобрать пакет mysql, добавив к сценарию после установки параметр --skip-write-binlog (это не требуется после 5.6.7).

Но обычно я никогда не стал бы просто apt-get обновить сервер, который находится в производстве, остановить ведомое устройство, обновить его и повторно подключить его. Это путь дзен.

Исследуя, действительно ли mysql_upgrade вызывать проблемы в реплицированных настройках все еще было (потому что это раньше укусило меня и мою команду, но в то же время binlog-ignore-db=mysql также есть проблемы) Я наткнулся на эту страницу и был рад прочитать ответ Баньека в котором говорится, что это решенная проблема! 🎉

Однако я хотел более явную ссылку, чтобы подтвердить, что проблема решена (а также мне было любопытно как это было решено) поэтому я просмотрел Журналы изменений MySQL 5.6.7 и вот он:

Репликация: mysql_upgrade не удалось, когда сервер работал с gtid_mode=ON и --disable-gtid-unsafe-statements потому что системные таблицы MySQL хранятся с использованием MyISAM. Эта проблема устраняется путем изменения поведения ведения журнала по умолчанию для mysql_upgrade; ведение журнала отключено по умолчанию. (Действия, предпринятые mysql_upgrade зависят от версии сервера и, следовательно, не должны реплицироваться на ведомые устройства.) Чтобы включить ведение журнала, вы можете выполнить mysql_upgrade используя --write-binlog вариант.

Обновить:

В ответ на комментарий @dlo текст справки mysql_upgrade Команда может быть проверена, чтобы подтвердить, получил ли данный сервер упомянутое выше обновление:

$ mysql_upgrade --help | grep -A2 write-binlog
  --write-binlog      All commands including mysqlcheck are binlogged. Disabled
                      by default; use when commands should be sent to
                      replication slaves.

Если Disabled by default текст там у тебя должно быть хорошо 🙂.