7.4.6.1 Работа с кластером, использующим MySQL Clone
Кластер InnoDB, использующий MySQL Clone, обеспечивает следующее дополнительное поведение.
dba.createCluster() и MySQL Clone
По умолчанию, при создании нового кластера на экземпляре, где доступен плагин MySQL Clone, он автоматически устанавливается, и кластер настраивается для поддержки клонирования. Учетные записи восстановления InnoDB Cluster создаются с необходимыми привилегиями.
Установите параметр disableClone типа Boolean в значение true, чтобы отключить MySQL Clone для кластера. В этом случае добавляется запись метаданных для этой конфигурации, и плагин MySQL Clone будет удален, если он установлен. Вы можете установить параметр disableClone при выполнении команды dba.createCluster() или в любое время, когда кластер работает, используя Cluster.setOption()
Cluster.addInstance(instance)
Cluster.addInstance(instance) MySQL Clone может использоваться для присоединения instance, если новый экземпляр работает под MySQL 8.0.17 или более поздней версии, и в кластере есть хотя бы один донор (включенный в список), работающий под MySQL 8.0.17 или более поздней версии. Кластер, использующий MySQL Clone, следует поведению, описанному в Раздел 7.4.4, «Добавление экземпляров в кластер InnoDB», с добавлением возможного выбора способа передачи данных, необходимых для восстановления экземпляра из кластера. Способ работы Cluster.addInstance(instance)
Поддерживается ли MySQL Clone.
Возможна ли инкрементная репликация или нет, что зависит от наличия двоичных логов. Например, если экземпляр-донор имеет все необходимые двоичные логи (
GTID_PURGEDпусто), то инкрементное восстановление возможно. Если ни один экземпляр кластера не имеет всех необходимых двоичных логов, то инкрементное восстановление невозможно.-
Подходит ли инкрементное восстановление или нет. Даже если инкрементное восстановление возможно, из-за потенциального конфликта с данными на экземпляре, проверяются наборы GTID донора и получателя, чтобы убедиться, что инкрементное восстановление уместно. Возможные результаты сравнения:
Новый: у получателя пустой набор GTID
Идентичный: у получателя набор GTID идентичен набору GTID донора
Восстанавливаемый: у получателя набор GTID отсутствуют транзакции, но их можно восстановить из донора
Невосстанавливаемый: у донора набор GTID отсутствуют транзакции, возможно, они были удалены
Расходящиеся: наборы GTID донора и получателя разошлись
Если результат сравнения — «Идентичный» или «Восстанавливаемый», инкрементное восстановление считается уместным. Если результат — «Невосстанавливаемый» или «Расходящиеся», инкрементное восстановление не считается уместным.
Для экземпляра, обозначенного как «Новый», инкрементное восстановление не может считаться уместным, так как невозможно определить, были ли удалены двоичные логи или даже если были сброшены переменные
GTID_PURGEDиGTID_EXECUTED. В противном случае сервер мог уже обработать транзакции до включения двоичных логов и GTID. Поэтому в интерактивном режиме необходимо подтвердить, что вы хотите использовать инкрементное восстановление. -
Состояние параметра
gtidSetIsComplete. Если вы уверены, что кластер был создан с полным набором GTID, и поэтому экземпляры с пустыми наборами GTID могут быть добавлены без дополнительных подтверждений, установите параметр уровня кластераgtidSetIsCompleteBoolean в значениеtrue.ПредупреждениеУстановка параметра
gtidSetIsCompleteв значениеtrueозначает, что присоединяемые серверы восстанавливаются независимо от содержащихся в них данных. Используйте с осторожностью. Если вы попытаетесь добавить экземпляр, на котором уже применены транзакции, вы рискуете повредить данные.
Сочетание этих факторов влияет на то, как экземпляры присоединяются к кластеру при выполнении команды Cluster.addInstance()recoveryMethod по умолчанию установлен в значение auto, что означает, что в интерактивном режиме MySQL Shell кластер выбирает лучший способ восстановления экземпляра из кластера, и подсказки предлагают, как поступить. Другими словами, кластер рекомендует использовать MySQL Clone или инкрементное восстановление в зависимости от лучшего подхода и того, что поддерживает сервер. Если вы не используете интерактивный режим и выполняете скрипты в MySQL Shell, вы должны установить recoveryMethod в тип восстановления, который вы хотите использовать — либо clone, либо incremental. В этом разделе объясняются различные возможные сценарии.
Когда вы используете MySQL Shell в интерактивном режиме, основная подсказка со всеми возможными вариантами добавления экземпляра выглядит следующим образом:
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
В зависимости от упомянутых факторов вам могут быть предложены не все эти варианты. Описанные далее в этом разделе сценарии объясняют, какие варианты вам предлагаются. Предлагаемые опции в этой подсказке:
Клонирование: выберите этот вариант для клонирования донора на экземпляр, который вы добавляете в кластер, удалив все транзакции, которые есть на экземпляре. Плагин MySQL Clone автоматически устанавливается. Учетные записи восстановления InnoDB Cluster создаются с необходимыми привилегиями. Предполагая, что вы добавляете экземпляр, который либо пуст (не обрабатывал никаких транзакций), либо содержит транзакции, которые вы не хотите сохранять, выберите вариант «Клонирование». Затем кластер использует MySQL Clone для полной перезаписи присоединяемого экземпляра с моментальным снимком из члена донорского кластера. Чтобы использовать этот метод по умолчанию и отключить этот запрос, установите параметр кластера
recoveryMethodв значениеclone.Инкрементное восстановление выберите этот вариант, чтобы использовать инкрементное восстановление для восстановления всех транзакций, обработанных кластером, на присоединяемый экземпляр с использованием асинхронной репликации. Инкрементное восстановление уместно, если вы уверены, что все обновления, когда-либо обработанные кластером, выполнялись с включенными GTID, нет удаленных транзакций и новый экземпляр содержит тот же набор GTID, что и кластер, или подмножество его. Чтобы использовать этот метод по умолчанию, установите параметр
recoveryMethodв значениеincremental.
Сочетание упомянутых факторов влияет на то, какой из этих вариантов доступен в подсказке, следующим образом:
Если системная переменная была изменена вручную вне AdminAPI, кластер может решить использовать восстановление с помощью Clone вместо следования этим сценариям.
-
В сценарии, где
инкрементное восстановление возможно
инкрементное восстановление не уместно
Clone поддерживается
вы можете выбрать любой из вариантов. Рекомендуется использовать MySQL Clone, по умолчанию.
-
В сценарии, где
инкрементное восстановление возможно
инкрементное восстановление уместно
вам не предлагается подсказка, и используется инкрементное восстановление.
-
В сценарии, где
инкрементное восстановление возможно
инкрементное восстановление не уместно
Clone не поддерживается или отключен
вы не можете добавить экземпляр в кластер с помощью MySQL Clone. Вам предлагается подсказка, и рекомендуемый вариант — продолжить с инкрементным восстановлением.
-
В сценарии, где
инкрементное восстановление невозможно
Clone не поддерживается или отключен
вы не можете добавить экземпляр в кластер, и отображается ошибка Ошибка: целевой экземпляр должен быть либо клонирован, либо полностью подготовлен перед добавлением в целевой кластер. Cluster.addInstance: Требуется подготовка экземпляра (RuntimeError). Это может быть результатом удаления двоичных логов из всех экземпляров кластера. Рекомендуется использовать MySQL Clone, либо обновив кластер, либо установив параметр
disableCloneв значениеfalse. -
В сценарии, где
инкрементное восстановление невозможно
Clone поддерживается
вы можете добавить экземпляр в кластер только с помощью MySQL Clone. Это может быть результатом отсутствия двоичных логов в кластере, например, когда они были удалены.
После выбора варианта в подсказке по умолчанию отображается прогресс восстановления транзакций экземпляра из кластера. Этот мониторинг позволяет проверить, работает ли фаза восстановления, а также сколько времени потребуется экземпляру для присоединения к кластеру и выхода в онлайн. Для отмены мониторинга фазы восстановления выполните CONTROL+C.
dba.checkInstanceConfiguration() и MySQL Clone
При выполнении операции dba.checkInstanceConfiguration() над экземпляром, на котором доступен MySQL Clone, но он отключен, отображается предупреждение.
© 2025 Oracle
Licensed under the GPLv2 License.
