8.4.4 Добавление экземпляров в InnoDB кластер
Для обеспечения отказоустойчивости к одному экземпляру в InnoDB кластере необходимо минимум три экземпляра. Добавление дополнительных экземпляров увеличивает отказоустойчивость InnoDB кластера.
Реализация Group Replication использует политики совместимости, которые учитывают версию экземпляров, и операция обнаруживает это и в случае несовместимости операция завершается ошибкой. См. Проверка версии MySQL на экземплярах и .Cluster.addInstance()
Используйте функцию для добавления экземпляра в кластер, где Cluster.addInstance(instance)instance — это информация о подключении к настроенному экземпляру, см. Раздел 8.4.2, «Настройка производственных экземпляров для использования в InnoDB кластере». Например:
mysql-js> cluster.addInstance('icadmin@ic-2:3306')
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Please provide the password for 'icadmin@ic-2:3306': ********
Adding instance to the cluster ...
Validating instance at ic-2:3306...
This instance reports its own address as ic-2
Instance configuration is suitable.
The instance 'icadmin@ic-2:3306' was successfully added to the cluster.
Словарь опций функции addInstance(instance[,
options]) предоставляет следующие атрибуты:
-
label: идентификатор добавляемого экземпляра.Метка должна быть непустой и не превышать 256 символов. Она должна быть уникальной в пределах кластера и может содержать только алфавитно-цифровые символы, _ (подчеркивание), . (точка), - (дефис) или : (двоеточие).
recoveryMethod: Предпочтительный метод восстановления состояния. Может быть auto, clone или incremental. По умолчанию используется auto.-
recoveryProgress: Целочисленное значение, определяющее уровень детализации процесса восстановления.0: не отображать никакой информации о прогрессе.
1: отображать подробную статическую информацию о прогрессе.
2: отображать подробную динамическую информацию о прогрессе с использованием полосок прогресса.
ipAllowlist: Список хостов, разрешенных для подключения к экземпляру для групповой репликации.localAddress: Строковое значение с локальным адресом Group Replication, которое должно быть использовано вместо автоматически сгенерированного.exitStateAction: Строковое значение, указывающее действие при выходе из состояния групповой репликации.memberWeight: Целочисленное значение с весом в процентах для автоматического выбора первичного экземпляра при переключении.autoRejoinTries: Целочисленное значение, определяющее количество попыток повторного подключения экземпляра к кластеру после удаления.
При добавлении нового экземпляра в кластер локальный адрес этого экземпляра автоматически добавляется в переменную на всех онлайн-экземплярах кластера, чтобы они могли использовать новый экземпляр для повторного присоединения к группе, если это необходимо.
Экземпляры, перечисленные в , используются в порядке их появления в списке. Это гарантирует, что пользовательские настройки применяются в первую очередь и предпочтительны. Дополнительную информацию см. в Разделе 8.5.2, «Настройка серверов узлов InnoDB кластера».
Если вы используете MySQL 8.0.17 или более позднюю версию, вы можете выбрать, как экземпляр восстановит транзакции, необходимые для синхронизации с кластером. Только когда присоединяющийся экземпляр восстановит все транзакции, которые ранее обрабатывались кластером, он может присоединиться как онлайн-экземпляр и начать обработку транзакций. Более подробную информацию см. в Разделе 8.4.6, «Использование MySQL Clone с InnoDB кластером».
Вы можете настроить поведение , позволяя операциям восстановления выполняться в фоновом режиме или контролировать различные уровни прогресса в MySQL Shell.Cluster.addInstance()
В зависимости от выбранного вами варианта восстановления экземпляра из кластера, в MySQL Shell отображается различный вывод. Предположим, что вы добавляете экземпляр ic-2 в кластер, а ic-1 — это начальный или донорский экземпляр.
-
При использовании MySQL Clone для восстановления экземпляра из кластера вывод выглядит следующим образом:
Validating instance at ic-2:3306... This instance reports its own address as ic-2:3306 Instance configuration is suitable. A new instance will be added to the InnoDB cluster. Depending on the amount of data on the cluster this might take from a few seconds to several hours. Adding instance to the cluster... Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background. Clone based state recovery is now in progress. NOTE: A server restart is expected to happen as part of the clone process. If the server does not support the RESTART command or does not come back after a while, you may need to manually start it back. * Waiting for clone to finish... NOTE: ic-2:3306 is being cloned from ic-1:3306 ** Stage DROP DATA: Completed ** Clone Transfer FILE COPY ############################################################ 100% Completed PAGE COPY ############################################################ 100% Completed REDO COPY ############################################################ 100% Completed NOTE: ic-2:3306 is shutting down... * Waiting for server restart... ready * ic-2:3306 has restarted, waiting for clone to finish... ** Stage RESTART: Completed * Clone process has finished: 2.18 GB transferred in 7 sec (311.26 MB/s) State recovery already finished for 'ic-2:3306' The instance 'ic-2:3306' was successfully added to the cluster.
Следует обратить внимание на предупреждения о перезапуске сервера; вам может потребоваться вручную перезапустить экземпляр. См. .
-
При использовании инкрементного восстановления для восстановления экземпляра из кластера вывод выглядит следующим образом:
Incremental distributed state recovery is now in progress. * Waiting for incremental recovery to finish... NOTE: 'ic-2:3306' is being recovered from 'ic-1:3306' * Distributed recovery has finished
Для отмены мониторинга фазы восстановления выполните CONTROL+C. Это останавливает мониторинг, но процесс восстановления продолжается в фоновом режиме. Целочисленная опция recoveryProgress может быть использована с операцией для отображения прогресса фазы восстановления.Cluster.addInstance()
Чтобы проверить, был ли экземпляр добавлен, используйте функцию status() экземпляра кластера. Например, это выходной статус тестового кластера после добавления второго экземпляра:
mysql-js> cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-1:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",
"topology": {
"ic-1:3306": {
"address": "ic-1:3306",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
},
"ic-2:3306": {
"address": "ic-2:3306",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
}
}
},
"groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}
Дальнейшие действия зависят от того, является ли экземпляр локальным или удалённым по отношению к экземпляру MySQL Shell, и от того, поддерживает ли экземпляр автоматическое сохранение изменений конфигурации, см. Раздел 6.2.3, «Сохранение настроек». Если экземпляр поддерживает автоматическое сохранение изменений конфигурации, вам не нужно вручную сохранять настройки, и вы можете либо добавить больше экземпляров, либо перейти к следующему шагу. Если экземпляр не поддерживает автоматическое сохранение изменений конфигурации, вам необходимо настроить экземпляр локально. Это необходимо для обеспечения того, что экземпляры присоединяются к кластеру в случае выхода из него.
Если у экземпляра есть , вам может потребоваться подтвердить, что AdminAPI может установить . Более подробную информацию см. в Конфигурации экземпляра в режиме супер-только чтения.
После развертывания кластера вы можете настроить MySQL Router для обеспечения высокой доступности, см. Главу 7, MySQL Router и AdminAPI.
© 2025 Oracle
Licensed under the GPLv2 License.