19.5.3 Модернизация или понижение версии топологии репликации
При модернизации серверов, участвующих в топологии репликации, необходимо учитывать роль каждого сервера в топологии и обращать внимание на проблемы, специфичные для репликации. Для получения общей информации и инструкций по модернизации экземпляра MySQL Server см. Главу 3, Модернизация MySQL.
Как объясняется в разделе 19.5.2 «Совместимость репликации между версиями MySQL», MySQL поддерживает репликацию из более старой версии источника в более новую версию реплики для комбинаций версий, где мы поддерживаем модернизацию от версии источника к версии реплики, как описано в разделе 1.3 «Выпуски MySQL: инновации и LTS» и разделе 3.2 «Пути модернизации», но не поддерживает репликацию из источника с более поздней версией в реплику с более ранней версией. Реплика с более ранней версией может не иметь необходимых возможностей для обработки транзакций, которые может обрабатывать источник с более поздней версией. Поэтому необходимо модернизировать все реплики в топологии репликации до целевой версии MySQL Server, прежде чем модернизировать сервер-источник до целевой версии. Таким образом, вы никогда не окажетесь в ситуации, когда реплика, которая все еще использует более раннюю версию, пытается обрабатывать транзакции из источника с более поздней версией.
В топологии репликации с несколькими источниками (репликация с несколькими источниками) использование более двух версий MySQL Server не поддерживается, независимо от количества серверов MySQL-источников или реплик. Например, вы не можете одновременно использовать MySQL X.Y.1, MySQL X.Y.2 и MySQL X.Y.3 в такой настройке, хотя вы можете использовать любые две из этих версий вместе.
Предварительная проверка серверов перед модернизацией
Возможны проблемы с репликацией при репликации из источника более ранней версии, которая еще не модернизирована, в реплику более поздней версии, которая уже модернизирована. Это может произойти, если источник использует операторы или полагается на поведение, которое больше не поддерживается в более поздней версии, установленной на реплике. Вы можете использовать утилиту проверки модернизации MySQL Shell util.checkForServerUpgrade() для проверки экземпляров серверов MySQL 8.0 на предмет модернизации до версии MySQL 8.4. Эта утилита определяет конфигурацию и сохраненные данные, которые, как известно, могут вызывать проблемы при модернизации, включая функции и поведение, которые больше недоступны в более поздней версии. См. для получения информации об утилите проверки модернизации.
Стандартная процедура модернизации
Для модернизации топологии репликации следуйте инструкциям в главе 3, Модернизация MySQL для каждого отдельного экземпляра MySQL Server, используя следующую общую процедуру:
-
Сначала модернизируйте реплики. На каждом экземпляре реплики:
Выполните предварительные проверки и шаги, описанные в разделе 3.6 «Подготовка вашей установки к модернизации».
Остановите MySQL Server.
Модернизируйте двоичные файлы или пакеты MySQL Server.
Запустите MySQL Server.
MySQL Server выполнит всю процедуру модернизации MySQL автоматически, отключив двоичное протоколирование во время модернизации.
Запустите репликацию, используя оператор
START REPLICA.
Если есть несколько уровней реплик (реплики-реплики), начните модернизацию реплик, которые находятся дальше от источника, выполняя модернизацию снизу вверх.
Когда все реплики будут модернизированы, и останется только источник, переключитесь на одну из реплик. Другими словами, остановите обновления клиентов на источнике, подождите, пока хотя бы одна реплика применит все изменения, переконфигурируйте топологию репликации, чтобы реплика стала источником, а источник был исключен из топологии репликации. Обновите старый источник в соответствии с процедурой для одного сервера, а затем снова включите его в топологию.
Если вам необходимо понизить версию серверов в топологии репликации, источник необходимо понизить до версии, прежде чем понижать версии реплик. Для реплик необходимо убедиться, что двоичный журнал и журнал реле полностью обработаны, и очистить их, прежде чем продолжить понижение версии.
Процедура поэтапного понижения версии
Остановите обновления.
Подождите, пока реплики получат все обновления. Нет необходимости ждать, пока они применят все изменения. Если они еще не применили все изменения, оставьте их приложение работающим, чтобы они могли обрабатывать полученные транзакции в фоновом режиме.
Понизьте версию сервера-источника, следуя инструкциям для понижения версии одного сервера.
Вставьте пониженный сервер-источник обратно в топологию.
Разрешите обновления снова.
Подождите, пока все реплики применят все оставшиеся транзакции от предыдущего первичного сервера.
Для каждой реплики удалите её из топологии, подождите, пока она обработает весь свой журнал реле, понизьте ее версию, следуя инструкциям для понижения версии одного сервера, и снова включите ее в топологию. Если есть несколько уровней реплик (реплики-реплики), то понижайте версию сверху вниз, начиная с реплик, ближайших к серверу-источнику.
© 2025 Oracle
Licensed under the GPLv2 License.
