Обновления пакета MySQL (склонные Debian - добираются) всегда повреждают основную основную репликацию из-за изменений в mysql схеме
Мне настраивали основную основную репликацию на 2 серверах Debian, и они копируют все, включая саму mysql базу данных (так, чтобы новые пользователи и такой также копировали). Это обычно работает очень хорошо, за исключением того, что большинство, если не все, способные обновления mysql включают некоторые изменения в mysql схеме базы данных, которые вызывают ошибки репликации та репликация останова. В конечном счете я всегда должен вручную фиксировать путем пропуска ошибочных операторов на каждой стороне. Это является всегда трудоемким, и я волнуюсь, что мог сделать ошибки, делающие его вручную (пропускающий слишком много операторов, введя ВЕДУЩИЕ детали ИЗМЕНЕНИЯ С ОПЕЧАТКОЙ, и т.д.).
Есть ли что-то, что я могу сделать, чтобы удостовериться, что склонный - добираются, обновления MySQL в будущем будут обработаны гладко, не вызывая проблемы репликации? Конечно, существует известная лучшая практика для этого?
Я не знаю, будет ли это работать для всех возможных сценариев обновления, но я только что протестировал это, и обновление прошло без каких-либо проблем с репликацией:
# /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.
Если текст Отключено по умолчанию есть, вы должны быть в порядке.