16.4.3 Upgrading a Replication Topology — MySQL 5.7

16.4.3 Модернизация топологии репликации

При модернизации серверов, участвующих в топологии репликации, необходимо учитывать роль каждого сервера в топологии и обращать внимание на проблемы, специфичные для репликации. Для общей информации и инструкций по модернизации экземпляра MySQL Server см. Раздел 2.10, «Модернизация MySQL».

Как объясняется в Разделе 16.4.2, «Совместимость репликации между версиями MySQL», MySQL поддерживает репликацию с источника, работающего в одной серии релизов, на реплику, работающую в следующей более новой серии релизов, но не поддерживает репликацию с источника, работающего в более поздней версии, на реплику, работающую в более ранней версии. Реплика более ранней версии может не иметь необходимых возможностей для обработки транзакций, которые может обрабатывать источник более поздней версии. Поэтому необходимо модернизировать все реплики в топологии репликации до целевой версии MySQL Server, прежде чем модернизировать сервер источника до целевой версии. Таким образом, вы никогда не столкнётесь с ситуацией, когда реплика, всё ещё работающая в более ранней версии, пытается обработать транзакции с источника более поздней версии.

В топологии репликации с несколькими источниками (многоисточниковая репликация) использование более двух версий MySQL Server не поддерживается, независимо от количества серверов MySQL источника или реплики. Это ограничение относится не только к сериям релизов, но и к номерам версий в рамках одной серии релизов. Например, вы не можете одновременно использовать MySQL 5.7.22, MySQL 5.7.24 и MySQL 5.7.28 в такой настройке, хотя вы можете использовать любые две из этих версий вместе.

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

Изменения поведения между версиями

Хотя такая последовательность модернизации верна, возможны проблемы с репликацией при репликации с источника более ранней версии, который ещё не был модернизирован, на реплику более поздней версии, которая была модернизирована. Это может произойти, если источник использует операторы или полагается на поведение, которое больше не поддерживается в более поздней версии, установленной на реплике. Вы можете использовать утилиту проверки модернизации MySQL Shell util.checkForServerUpgrade() для проверки экземпляров сервера MySQL 5.7 или экземпляров сервера MySQL 8.0 на предмет модернизации до релизной версии MySQL 8.0. Эта утилита выявляет всё, что нужно исправить для данного экземпляра сервера, чтобы он не стал причиной проблем после модернизации, включая функции и поведение, которые больше недоступны в более поздней версии. См. для получения информации об утилите проверки модернизации.

Если вы модернизируете существующую конфигурацию репликации с версии MySQL, не поддерживающей глобальные идентификаторы транзакций (GTID), до версии, которая их поддерживает, включите GTID только на источнике и репликах, когда убедитесь, что настройка удовлетворяет всем требованиям для репликации на основе GTID. См. Раздел 16.1.3.4, «Настройка репликации с использованием GTID» для получения информации о преобразовании конфигураций репликации на основе позиции файла двоичного журнала в конфигурации репликации на основе GTID.

Изменения, влияющие на операции в строгом режиме SQL (STRICT_TRANS_TABLES или STRICT_ALL_TABLES), могут привести к сбою репликации на модернизированной реплике. Если используется протоколирование на основе операторов (binlog_format=STATEMENT), если реплика модернизируется до источника, источник выполняет операторы, которые успешно выполняются там, но могут завершиться с ошибкой на реплике и, таким образом, остановить репликацию. Для решения этой проблемы остановите все новые операторы на источнике и подождите, пока реплики не догонят, затем модернизируйте реплики. В противном случае, если вы не можете остановить новые операторы, временно измените протоколирование на основе строк на источнике (binlog_format=ROW) и подождите, пока все реплики не обработают все двоичные журналы, созданные до этого момента, затем модернизируйте реплики.

Значение по умолчанию набора символов изменилось с latin1 на utf8mb4 в MySQL 8.0. В конфигурации репликации при модернизации с MySQL 5.7 на 8.0 рекомендуется изменить значение набора символов по умолчанию на набор символов, используемый в MySQL 5.7, перед модернизацией. После завершения модернизации значение набора символов по умолчанию можно изменить на utf8mb4. Предполагая, что использовались предыдущие значения по умолчанию, один из способов сохранить их — запустить сервер с этими строками в файле my.cnf:

[mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ci

Стандартная процедура модернизации

Для модернизации топологии репликации следуйте инструкциям в Разделе 2.10, «Модернизация MySQL» для каждого отдельного экземпляра MySQL Server, используя следующую общую процедуру:

Сначала модернизируйте реплики. На каждом экземпляре реплики:
- Выполните предварительные проверки и шаги, описанные в .
- Остановите MySQL Server.
- Модернизируйте двоичные файлы или пакеты MySQL Server.
- Запустите MySQL Server.
- Если вы модернизировали до версии ранее, чем MySQL 8.0.16, вручную вызовите mysql_upgrade для модернизации системных таблиц и схем. Когда сервер работает с включенными глобальными идентификаторами транзакций (GTID) (gtid_mode=ON), не включайте двоичное протоколирование с помощью mysql_upgrade (не используйте параметр --write-binlog). Затем остановите и перезапустите сервер.
- Если вы модернизировали до MySQL 8.0.16 или более поздней версии, не вызывайте mysql_upgrade. Начиная с этой версии, MySQL Server выполняет всю процедуру модернизации MySQL, отключая двоичное протоколирование во время модернизации.
- Перезапустите репликацию, используя оператор или START SLAVE.
После того, как все реплики будут модернизированы, выполните те же шаги для модернизации и перезапуска сервера источника, за исключением оператора или START SLAVE. Если вы вносили временные изменения в протоколирование на основе строк или значения набора символов по умолчанию, вы можете теперь их отменить.

Процедура модернизации с ремонтом или перестроением таблиц

Некоторые модернизации могут потребовать удаления и повторного создания объектов базы данных при переходе от одной серии MySQL к следующей. Например, изменения набора сортировки могут потребовать перестроения индексов таблиц. Если такие операции необходимы, они подробно описаны в Разделе 2.10.3, «Изменения в MySQL 5.7». Безопаснее всего выполнять эти операции отдельно на репликах и источнике и отключать репликацию этих операций с источника на реплику. Для этого используйте следующую процедуру:

Остановите все реплики и модернизируйте двоичные файлы или пакеты. Перезапустите их с параметром --skip-slave-start или, начиная с MySQL 8.0.24, системной переменной , чтобы они не подключались к источнику. Выполните любые необходимые операции по ремонту или перестроению таблиц для повторного создания объектов базы данных, например, используя REPAIR TABLE или ALTER TABLE, или дублируя и перезагружая таблицы или триггеры.
Отключите двоичный журнал на источнике. Для этого без перезапуска источника выполните оператор SET sql_log_bin = OFF. В качестве альтернативы остановите источник и перезапустите его с параметром --skip-log-bin. Если вы перезапустите источник, вы также можете запретить подключения клиентов. Например, если все клиенты подключаются через TCP/IP, включите системную переменную skip_networking при перезапуске источника.
При отключённом двоичном журнале выполните любые необходимые операции по ремонту или перестроению таблиц для повторного создания объектов базы данных. Двоичный журнал должен быть отключён на этом этапе, чтобы предотвратить протоколирование этих операций и их отправку репликам позже.
Включите двоичный журнал на источнике. Если ранее вы установили sql_log_bin на OFF, выполните оператор SET sql_log_bin = ON. Если вы перезапустили источник для отключения двоичного журнала, перезапустите его без --skip-log-bin и без включения системной переменной skip_networking, чтобы клиенты и реплики могли подключиться.
Перезапустите реплики, на этот раз без параметра --skip-slave-start или системной переменной.