8.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, следует поведению, описанному в Разделе 8.4.4 «Добавление экземпляров в кластер InnoDB», с добавлением возможности выбора способа передачи данных, необходимых для восстановления экземпляра из кластера. Способ работы Cluster.addInstance(instance)
Поддерживается ли MySQL Clone.
Возможна ли инкрементная репликация или нет, что зависит от наличия двоичных журналов. Например, если у экземпляра-донора есть все необходимые двоичные журналы (
GTID_PURGEDпусто), то инкрементная репликация возможна. Если ни один экземпляр кластера не имеет всех необходимых двоичных журналов, то инкрементная репликация невозможна.-
Применимо ли инкрементное восстановление или нет. Даже если инкрементное восстановление возможно, из-за потенциального конфликта с данными, уже имеющимися на экземпляре, проверяются наборы GTID донора и получателя, чтобы убедиться, что инкрементное восстановление уместно. Возможные результаты сравнения:
Новый: у получателя пустой набор GTID
GTID_EXECUTEDИдентичный: у получателя набор GTID идентичен набору GTID донора.
Восстанавливаемый: у получателя набор GTID отсутствуют транзакции, но они могут быть восстановлены из донора.
Невосстанавливаемый: у донора набор GTID отсутствуют транзакции, возможно, они были удалены.
Отклонившийся: наборы GTID донора и получателя разошлись.
Если результат сравнения — Идентичный или Восстанавливаемый, инкрементное восстановление считается уместным. Если результат — Невосстанавливаемый или Отклонившийся, инкрементное восстановление не считается уместным.
Для экземпляра, считающегося Новым, инкрементное восстановление не может считаться уместным, поскольку невозможно определить, были ли двоичные журналы удалены или были сброшены переменные
GTID_PURGEDиGTID_EXECUTED. Или, возможно, сервер уже обработал транзакции до включения двоичных журналов и GTID. Поэтому в интерактивном режиме необходимо подтвердить, что вы хотите использовать инкрементное восстановление. -
Состояние параметра
gtidSetIsComplete. Если вы уверены, что кластер был создан с полным набором GTID, и поэтому экземпляры с пустыми наборами GTID могут быть добавлены без дополнительных подтверждений, установите параметр кластераgtidSetIsCompleteтипа Boolean на значение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 не поддерживается или отключен
нельзя добавить экземпляр в кластер и отображается ошибка ERROR: Целевой экземпляр должен быть либо клонирован, либо полностью подготовлен перед добавлением в целевой кластер. 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.
