8.4 Deploying InnoDB ClusterSet — MySQL Shell 8.4

8.4 Развертывание InnoDB ClusterSet

Следуйте этой процедуре для развертывания песочницы или производственного развертывания InnoDB ClusterSet. Развертывание песочницы подразумевает, что все экземпляры сервера MySQL и другое программное обеспечение работают на одном компьютере. Для производственного развертывания экземпляры сервера и другое программное обеспечение находятся на отдельных компьютерах.

Процедура предполагает, что у вас уже есть следующие компоненты, как указано в разделе 8.1, «Требования к InnoDB ClusterSet»:

Существующий кластер InnoDB, соответствующий требованиям, указанным в разделе 8.1, «Требования к InnoDB ClusterSet». Это основной кластер, который поддерживает развертывание InnoDB ClusterSet.
MySQL Shell, подключенный к существующему кластеру InnoDB. Команды AdminAPI MySQL Shell используются в процедуре развертывания.
MySQL Router для запуска InnoDB ClusterSet. Экземпляры MySQL Router, которые вы уже настроили для работы с существующим кластером InnoDB, можно повторно использовать при развертывании InnoDB ClusterSet, но вам необходимо снова их настроить для реализации конфигурации InnoDB ClusterSet.
Несколько автономных экземпляров сервера MySQL (которые не являются частью кластера InnoDB или InnoDB ReplicaSet) для создания одного или нескольких реплицированных кластеров. Они должны соответствовать требованиям, указанным в разделе 8.1, «Требования к InnoDB ClusterSet». Рекомендуется, чтобы каждый реплицированный кластер состоял из минимум трех серверных узлов для обеспечения отказоустойчивости.

Пользовательская учетная запись, используемая во время процедуры развертывания InnoDB ClusterSet, — это учетная запись конфигурации сервера InnoDB из основного кластера. Это та учетная запись, которая была создана на серверных узлах основного кластера с помощью команды dba.configureInstance() с параметром clusterAdmin. Каждый серверный узел имеет только одну учетную запись конфигурации сервера. Одно и то же имя пользователя и пароль должны использоваться на каждом серверном узле в кластере, и вам необходимо создать их на всех серверах в развертывании InnoDB ClusterSet. Можно использовать учетную запись root в качестве учетной записи конфигурации сервера InnoDB, но это не рекомендуется, поскольку это означает, что учетная запись root на каждом серверном узле в кластере должна иметь одинаковый пароль. Более подробную информацию см. в разделе 8.3, «Учетные записи пользователей для InnoDB ClusterSet».

Для настройки развертывания InnoDB ClusterSet следуйте этой процедуре:

Подключитесь к любому узловому серверу в существующем кластере InnoDB с помощью MySQL Shell, используя учетные данные конфигурации сервера InnoDB Cluster для подключения. Например:
```
mysql-js> \connect icadmin@127.0.0.1:3310

Creating a session to 'icadmin@127.0.0.1:3310'
Please provide the password for 'icadmin@127.0.0.1:3310': **************
Save password for 'icadmin@127.0.0.1:3310'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Closing old connection...
Your MySQL connection id is 59
Server version: 8.0.27-commercial MySQL Enterprise Server - Commercial
No default schema selected; type \use <schema> to set one.
<ClassicSession:icadmin@127.0.0.1:3310>
```
В этом примере:
- icadmin@127.0.0.1:3310 — это строка подключения в формате URI для любого активного узлового сервера в кластере InnoDB.
  
  Строка подключения в формате URI состоит из следующих элементов:
- icadmin — имя пользователя для учетных данных конфигурации сервера InnoDB Cluster.
- 127.0.0.1:3310 — хост и порт узлового сервера, отображаемые командой cluster.status().
Выполните команду dba.getCluster() для получения объекта Cluster, представляющего кластер InnoDB, присвоив его переменной для работы с ним. Например:
```
mysql-js> cluster1 = dba.getCluster()
<Cluster:clusterone>
```
В этом примере clusterone — имя существующего кластера InnoDB, отображаемое в поле clusterName, возвращаемом командой cluster.status(), а возвращаемый объект Cluster присваивается переменной cluster1.

Это важно, когда вы подключены к экземпляру сервера с использованием учетных данных конфигурации сервера InnoDB Cluster. Возвращаемый объект по умолчанию использует учетные данные, с которыми он был получен, для операций, требующих разрешений. Некоторые операции во время процесса развертывания InnoDB ClusterSet требуют разрешений, и по умолчанию используется учетная запись пользователя, хранящаяся в объекте, чтобы процесс не нуждался в хранении других учетных записей.
Выполните команду cluster.createClusterSet(), используя объект Cluster, для создания InnoDB ClusterSet с существующим кластером InnoDB в качестве основного. Например:
```
mysql-js> myclusterset = cluster1.createClusterSet('testclusterset')

A new ClusterSet will be created based on the Cluster 'clusterone'.

* Validating Cluster 'clusterone' for ClusterSet compliance.

* Creating InnoDB ClusterSet 'testclusterset' on 'clusterone'...

* Updating metadata...

ClusterSet successfully created. Use ClusterSet.createReplicaCluster() to add Replica Clusters to it.

<ClusterSet:testclusterset> 
```
В этом примере, clusterone — имя существующего кластера InnoDB, cluster1 — переменная, которой был присвоен возвращаемый объект Cluster, testclusterset — имя создаваемого InnoDB ClusterSet, а myclusterset — переменная, которой присваивается возвращаемый объект ClusterSet.
- Параметр domainName обязателен и указывает имя развертывания InnoDB ClusterSet, которое вы создаёте (testclusterset в примере).
  
  domainName должно быть непустым и не превышать 63 символов. Оно может начинаться только с буквенно-цифрового символа или с _ (подчеркивание) и может содержать только буквенно-цифровые символы, _ (подчеркивание), . (точка) или - (дефис).
- Используйте опцию dryRun, если хотите выполнить проверки и залогировать изменения без их фактического выполнения. Например:
```
mysql-js> myclusterset = cluster1.createClusterSet('testclusterset', {dryRun: true})
* Validating Cluster 'clusterone' for ClusterSet compliance.

NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
* Creating InnoDB ClusterSet 'clusterset' on 'clusterone'...

* Updating metadata...
dryRun finished.
```
- Используйте опцию clusterSetReplicationSslMode, если хотите потребовать или отключить шифрование (TLS/SSL) для каналов репликации в развертывании InnoDB ClusterSet. Значение по умолчанию, AUTO, включает шифрование, если экземпляр сервера его поддерживает, и отключает, если нет. REQUIRED включает шифрование для всех каналов репликации, а DISABLED отключает шифрование для всех каналов репликации. Например:
```
mysql-js> myclusterset = cluster1.createClusterSet("testclusterset", {clusterSetReplicationSslMode: 'REQUIRED'})
```
clusterSetReplicationSslMode поддерживает VERIFY_CA и VERIFY_IDENTITY. Например:
```
mysql-js> myclusterset = cluster.createClusterSet("testclusterset", {"clusterSetReplicationSslMode":"VERIFY_IDENTITY"});
        
```
При выполнении команды cluster.createClusterSet() MySQL Shell проверяет, соответствует ли целевой кластер InnoDB требованиям для назначения его основным в развертывании InnoDB ClusterSet, и возвращает ошибку, если нет. Если целевой кластер InnoDB соответствует требованиям, MySQL Shell выполняет следующие задачи настройки:
- Обновляет схему метаданных, чтобы включить метаданные InnoDB ClusterSet.
- Устанавливает системную переменную на ON на всех узловых серверах, чтобы потоки репликации не запускались автоматически.
- Добавляет целевой кластер InnoDB в InnoDB ClusterSet в метаданных и помечает его как основной.
- Возвращает объект ClusterSet, представляющий InnoDB ClusterSet.
Проверьте работоспособность созданного развертывания InnoDB ClusterSet, выполнив команду clusterSet.status(), используя возвращённый объект ClusterSet. Например:
```
mysql-js> myclusterset.status()
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310"
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}
```
Также можно использовать команду cluster.status() для просмотра самого кластера. Кроме того, можно выбрать расширенный вывод для clusterSet.status(), чтобы увидеть подробный статус кластеров в топологии InnoDB ClusterSet. Например:
```
mysql-js> myclusterset.status({extended: 1})
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-86,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}
```
См. Раздел 8.7, «Состояние и топология InnoDB ClusterSet» для получения дополнительной информации и описания вывода от команды clusterSet.status().

Если вам нужно получить объект ClusterSet, представляющий InnoDB ClusterSet для подключённого экземпляра сервера в любое время, например после перезапуска MySQL Shell, используйте команду dba.getClusterSet() или cluster.getClusterSet(). Например:
```
mysql-js> myclusterset = dba.getClusterSet()
<ClusterSet:testclusterset>
```
Присвоение возвращаемого объекта Cluster или ClusterSet переменной позволяет выполнять дальнейшие операции с кластером или ClusterSet, используя методы объекта. Возвращаемый объект использует новую сессию, независимую от глобальной сессии MySQL Shell. Это гарантирует, что если вы измените глобальную сессию MySQL Shell, объект Cluster или ClusterSet сохранит свою сессию с экземпляром сервера. Обратите внимание, что при использовании объекта экземпляр сервера, с которого вы его получили, должен оставаться активным в InnoDB ClusterSet. Если этот экземпляр сервера выходит из строя, объект перестаёт работать, и вам необходимо получить его снова с сервера, который всё ещё активен.
Создайте учетную запись конфигурации сервера InnoDB Cluster на каждом автономном экземпляре сервера, который будет частью кластера реплики, выполнив команду dba.configureInstance() с опцией clusterAdmin. Создаваемая учетная запись — это учетная запись конфигурации сервера InnoDB Cluster из основного кластера, которую вы использовали для создания ClusterSet. Не указывайте никакие учетные записи администратора InnoDB Cluster (созданные с помощью cluster.setupAdminAccount()). Они будут автоматически перенесены из основного кластера в кластеры реплик во время процесса подготовки.

Вам не нужно предварительно подключаться к автономным экземплярам серверов, так как строка подключения включена в команду. В строке подключения используйте учетную запись с полными правами MySQL-администратора, включая права на создание учетных записей (WITH GRANT OPTION). В этом примере используется учетная запись root:
```
mysql-js> dba.configureInstance('root@127.0.0.1:4410', {clusterAdmin: 'icadmin'})

Please provide the password for 'root@127.0.0.1:4410': ***************
Save password for 'root@127.0.0.1:4410'? [Y]es/[N]o/Ne[v]er (default No):
Configuring local MySQL instance listening at port 4410 for use in an InnoDB cluster...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.

This instance reports its own address as 127.0.0.1:4410
Password for new account: **************
Confirm password: **************

applierWorkerThreads will be set to the default value of 4.

The instance '127.0.0.1:4410' is valid to be used in an InnoDB cluster.

Cluster admin user 'icadmin' created.
The instance '127.0.0.1:4410' is already ready to be used in an InnoDB cluster.

Successfully enabled parallel appliers.
```
В этом примере, root@127.0.0.1:4410 — это строка подключения в формате URI для автономного сервера, а icadmin — имя пользователя для учетной записи конфигурации сервера InnoDB Cluster, которая будет создана на экземпляре. Для повышения безопасности укажите пароль для учетной записи конфигурации сервера InnoDB Cluster в интерактивном запросе, как показано в примере, или вы можете предоставить его с помощью опции clusterAdminPassword. Команда dba.configureInstance() автоматически предоставляет учетной записи необходимые разрешения, хотя вы можете настроить учетную запись вручную, если хотите, предоставив ей разрешения, указанные в Руководство по настройке учетных записей администратора InnoDB Cluster вручную. Более подробная информация о команде dba.configureInstance() и ее опциях доступна в Разделе 7.4.2, «Настройка производственных экземпляров для использования InnoDB Cluster».

При выполнении команды dba.configureInstance() MySQL Shell проверяет, соответствует ли экземпляр сервера требованиям для использования с InnoDB Cluster. Требования к InnoDB ClusterSet будут проверяться при выполнении команд создания кластера реплик и добавления к нему экземпляров.
Подключитесь к любому активному экземпляру в основном кластере, уже включенном в развертывание InnoDB ClusterSet, используя учетные данные конфигурации сервера InnoDB Cluster. Убедитесь, что у вас всё ещё есть объект ClusterSet, возвращённый при создании InnoDB ClusterSet, или получите его снова с помощью dba.getClusterSet() или cluster.getClusterSet(). Опять же, это важно, когда вы подключены к экземпляру сервера с использованием учетных данных конфигурации сервера InnoDB Cluster. Учетная запись пользователя по умолчанию, хранящаяся в объекте, используется для некоторых операций во время процесса развертывания InnoDB ClusterSet независимо от учетной записи, которую вы указываете при подключении.

Выполните команду clusterSet.createReplicaCluster() с помощью объекта ClusterSet, чтобы создать кластер реплик, указав имя одного из экземпляров автономного сервера. Этот экземпляр сервера будет основным для кластера реплик. Команда возвращает объект Cluster для кластера реплик, и вы можете присвоить его переменной, если хотите. Например:
```
mysql-js> cluster2 = myclusterset.createReplicaCluster("127.0.0.1:4410", "clustertwo", {recoveryProgress: 1, timeout: 10})
Setting up replica 'clustertwo' of cluster 'clusterone' at instance '127.0.0.1:4410'.

A new InnoDB cluster will be created on instance '127.0.0.1:4410'.

Validating instance configuration at 127.0.0.1:4410...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.

This instance reports its own address as 127.0.0.1:4410

Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44101'. Use the
localAddress option to override.


* Checking transaction state of the instance...

NOTE: The target instance '127.0.0.1:4410' has not been pre-provisioned (GTID set is empty). The
Shell is unable to decide whether replication can completely recover its state.
The safest and most convenient way to provision a new instance is through automatic clone
provisioning, which will completely overwrite the state of '127.0.0.1:4410' with a physical
snapshot from an existing clusterset member. To use this method by default, set the
'recoveryMethod' option to 'clone'.

WARNING: It should be safe to rely on replication to incrementally recover the state of the new
Replica Cluster if you are sure all updates ever executed in the ClusterSet were done with GTIDs
enabled, there are no purged transactions and the instance used to create the new Replica Cluster
contains the same GTID set as the ClusterSet or a subset of it. To use this method by default,
set the 'recoveryMethod' option to 'incremental'.


Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
Waiting for clone process of the new member to complete. Press ^C to abort the operation.
* Waiting for clone to finish...
NOTE: 127.0.0.1:4410 is being cloned from 127.0.0.1:3310
** Stage DROP DATA: Completed

NOTE: 127.0.0.1:4410 is shutting down...

* Waiting for server restart... ready
* 127.0.0.1:4410 has restarted, waiting for clone to finish...
** Stage FILE COPY: Completed
** Stage PAGE COPY: Completed
** Stage REDO COPY: Completed
** Stage FILE SYNC: Completed
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)

Creating InnoDB cluster 'clustertwo' on '127.0.0.1:4410'...

Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.

* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4410 to 127.0.0.1:3310

* Waiting for instance to synchronize with PRIMARY Cluster...
** Transactions replicated  ############################################################  100%
* Updating topology

Replica Cluster 'clustertwo' successfully created on ClusterSet 'testclusterset'.

<Cluster:clustertwo>
```
Для команды clusterSet.createReplicaCluster():
- Параметр instance обязателен и указывает хост и номер порта экземпляра MySQL Server автономного сервера. Это экземпляр сервера, который станет основным в кластере реплик. В примере команды выше это 127.0.0.1:4410.
- Параметр clusterName обязателен и указывает идентификатор кластера реплик. В примере команды выше используется clustertwo. Имя должно быть уникальным в InnoDB ClusterSet и должно соответствовать требованиям именования InnoDB Cluster. Разрешены только буквенно-цифровые символы, дефисы (-), подчёркивания (_) и точки (.). Имя не должно начинаться с цифры. Максимальная длина — 63 символа. Имя кластера чувствительно к регистру.
- Используйте опцию dryRun, если хотите выполнить валидацию и записать изменения без фактического их выполнения.
- Используйте опцию recoveryMethod, если хотите выбрать метод развёртывания. Если вы не укажете эту опцию, используется значение по умолчанию AUTO. В этом случае функция сравнивает набор GTID на экземпляре сервера с набором GTID на основном кластере и пытается определить наиболее подходящий метод развёртывания. Если это невозможно определить, функция попросит вас выбрать метод развёртывания или отменит операцию, если вы не работаете в интерактивном режиме.
  
  Процесс развёртывания, который называется распределённым восстановлением, может использовать клонирование, где состояние экземпляра сервера полностью перезаписывается физической копией, взятой с существующего сервера-члена кластера. Чтобы выбрать это заранее, укажите значение CLONE. Альтернативой является инкрементальная передача состояния из двоичного журнала существующего сервера-члена, в данном случае члена основного кластера. В этом случае экземпляр сервера получает и применяет транзакции из основного кластера, которых у него ещё нет. Чтобы выбрать это заранее, укажите значение INCREMENTAL.
- Используйте опцию cloneDonor, если хотите выбрать определённый сервер для предоставления моментальной копии, которая перезапишет текущий сервер, если распределённое восстановление выполняется методом клонирования. По умолчанию операция выбирает вторичного члена основного кластера или основной член, если вторичных членов нет. Выбранный экземпляр сервера должен быть членом основного кластера в InnoDB ClusterSet. Укажите хост и номер порта. IPv6-адреса для этой опции не поддерживаются.
- Используйте опцию recoveryProgress для указания уровня детализации (0, 1 или 2) для процесса распределённого восстановления. Значение 0 не отображает информацию о прогрессе, 1 отображает подробную статическую информацию о прогрессе, а 2 отображает подробную динамическую информацию о прогрессе с помощью полос прогресса. Значение 2 является значением по умолчанию, если стандартный вывод — терминал, в противном случае значением по умолчанию является 1.
- Используйте опцию timeout, если хотите установить таймаут для ожидания синхронизации экземпляра сервера с основным кластером после его развёртывания и создания канала репликации ClusterSet. По умолчанию таймаут не установлен.
- Используйте опцию manualStartOnBoot, чтобы указать, запускается ли Group Replication автоматически и присоединяется ли к кластеру при запуске сервера MySQL, или его нужно запускать вручную. Значение по умолчанию, false, означает, что Group Replication запускается автоматически.
- Используйте опцию communicationStack, чтобы определить, как члены общаются друг с другом, используя протоколы XCOM или MYSQL. См. Раздел 7.5.9 «Настройка стека коммуникаций Group Replication».
  
  Если вы используете MySQL 8.0.27 или более позднюю версию, протокол по умолчанию и рекомендуемый протокол — MYSQL.
- Опции memberSslMode, ipAllowlist, localAddress, exitStateAction, memberWeight, consistency, expelTimeout и autoRejoinTries доступны, если вы хотите настроить установку Group Replication для реплики InnoDB Cluster. Эти опции работают так же, как и для InnoDB Cluster, который не является частью ClusterSet. Подробнее об опциях см. Раздел 7.5 «Настройка InnoDB Cluster». (Примечание: ipAllowlist и localAddress доступны только для стека коммуникаций XCOM.)
- Можно использовать опции localAddress и groupName для задания локального адреса Group Replication и идентификатора группы. Однако это не рекомендуется, так как неправильные значения могут привести к ошибкам в Group Replication. Используйте эти опции только в случае возникновения проблем со значениями, выбранными процессом настройки InnoDB ClusterSet для этих элементов.
- При создании InnoDB ClusterSet, если у вас есть требования безопасности, чтобы все автоматически создаваемые учетные записи AdminAPI имели строгие требования аутентификации, вы можете установить значение для конфигурационной опции replicationAllowedHost ClusterSet. Опция MySQL Shell replicationAllowedHost позволяет установить внутренние управляемые учетные записи репликации для ClusterSet на строгий фильтр на основе подсети вместо значения по умолчанию — подстановочного знака %. Опция replicationAllowedHost принимает строковое значение. Например, чтобы создать кластер с именем my_clusterset_domain и установить опцию replicationAllowedHost на значение 192.0.2.0/24, выполните команду:
```
mysql-js> <Cluster>.createClusterSet('my_clusterset_domain', {replicationAllowedHost:'192.0.2.0/24'})
```
  При изменении replicationAllowedHost в ClusterSet, учетная запись, используемая для канала репликации между кластерами, изменяется, чтобы разрешить подключения только с указанного значения для replicationAllowedHost. Хост должен быть доступен как в основном, так и в реплицируемом кластерах. В противном случае репликация между кластерами невозможна.
  
  ClusterSet можно изменить после создания, чтобы установить replicationAllowedHost, выполнив команду:
```
mysql-js> <Clusterset>.setOption('replicationAllowedHost','192.0.2.0/24')
```
При выполнении команды clusterSet.createReplicaCluster() MySQL Shell проверяет, соответствует ли целевой экземпляр сервера требованиям для того, чтобы стать основным сервером в реплицируемом InnoDB Cluster в развертывании InnoDB ClusterSet, и возвращает ошибку, если не соответствует. Если экземпляр соответствует требованиям, MySQL Shell выполняет следующие задачи настройки:
- Создаёт канал репликации ClusterSet clusterset_replication и создаёт пользователя репликации с случайным паролем. Это асинхронный канал репликации между целевым экземпляром и основным сервером основного кластера, который управляется InnoDB ClusterSet. Шифрование для канала настраивается в соответствии с опцией clusterSetReplicationSslMode для InnoDB ClusterSet. MySQL Shell проверяет, работает ли настройка репликации, и возвращает ошибку, если не работает.
- Развёртывает экземпляр MySQL Server с набором данных из основного InnoDB Cluster и синхронизирует набор GTID, используя выбранный метод восстановления. Обратите внимание, что при большом объёме данных на серверах-членах ClusterSet распределённое восстановление может занять несколько часов.
- Добавляет учётные записи администратора InnoDB Cluster и учётные записи администратора MySQL Router на экземпляр сервера. Если экземпляр развёртывается путём передачи состояния из двоичного журнала, процесс развёртывания включает транзакции, создающие учетные записи, либо учетные записи передаются при клонировании. В любом случае эти учетные записи становятся доступны на экземпляре сервера. См. Раздел 8.3 «Учетные записи пользователей для InnoDB ClusterSet» для получения дополнительной информации.
- Настраивает и запускает Group Replication для кластера реплик. Процесс создания реплицируемого кластера InnoDB ClusterSet перезаписывает все существующие сохранённые конфигурационные опции Group Replication, для которых вы задаёте новые настройки в команде clusterSet.createReplicaCluster(). Также всегда перезаписывает следующие конфигурационные опции, даже если вы их не указываете в команде: , , , (только версии 8.0.27 до 8.2.0) и . Однако любые другие конфигурационные опции Group Replication, которые вы изменили на экземпляре сервера до его использования в реплицируемом кластере, остаются без изменений. См. важное примечание в Раздел 8.1 «Требования к InnoDB ClusterSet».
- Устанавливает системную переменную на ON, чтобы потоки репликации не запускались автоматически на сервере, и устанавливает системную переменную, чтобы клиенты не могли записывать транзакции на сервер.
- Отключает действие члена Group Replication mysql_disable_super_read_only_if_primary, чтобы значение оставалось установленным на главном сервере кластера после изменения вида.
- Включает действие члена Group Replication mysql_start_failover_channels_if_primary, чтобы обеспечить асинхронную переадресацию подключения для реплик для канала репликации ClusterSet. При включённой этой функции, если основной сервер, который выполняет репликацию, становится недоступен или переходит в состояние ошибки, новый основной сервер запускает репликацию на том же канале, когда его выбирают.
- Передаёт метаданные ClusterSet на экземпляр сервера, создаёт кластер реплик в InnoDB ClusterSet и добавляет целевой экземпляр сервера в него как основной.
- Возвращает объект Cluster для кластера реплик.

Используя объект Cluster, который был возвращён для кластера реплик командой clusterSet.createReplicaCluster(), выполните команду cluster.addInstance, указав имя другого из автономных серверных экземпляров. Этот серверный экземпляр будет вторичным в кластере реплик. Например:

mysql-js> cluster2.addInstance('icadmin@127.0.0.1:4420')

NOTE: The target instance '127.0.0.1:4420' has not been pre-provisioned (GTID set is empty). The
Shell is unable to decide whether clone based recovery is safe to use.
The safest and most convenient way to provision a new instance is through automatic clone
provisioning, which will completely overwrite the state of '127.0.0.1:4420' with a physical
snapshot from an existing cluster member. To use this method by default, set the
'recoveryMethod' option to 'clone'.

Please select a recovery method [C]lone/[A]bort (default Clone): c
Validating instance configuration at localhost:4420...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.

This instance reports its own address as 127.0.0.1:4420

Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44201'. Use the
localAddress option to override.

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...

* Waiting for the Cluster to synchronize with the PRIMARY Cluster...
** Transactions replicated  ############################################################  100%
* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4420 to 127.0.0.1:3310

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: 127.0.0.1:4420 is being cloned from 127.0.0.1:4410
** Stage DROP DATA: Completed
** Clone Transfer
    FILE COPY  ############################################################  100%  Completed
    PAGE COPY  ############################################################  100%  Completed
    REDO COPY  ############################################################  100%  Completed

NOTE: 127.0.0.1:4420 is shutting down...

* Waiting for server restart... ready
* 127.0.0.1:4420 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)

State recovery already finished for '127.0.0.1:4420'

The instance '127.0.0.1:4420' was successfully added to the cluster.

Более подробную информацию о команде cluster.addInstance см. в разделе 7.4.4 «Добавление экземпляров в кластер InnoDB».

Если вам необходимо снова получить объект Cluster для кластера реплик, подключитесь к любому активному экземпляру в кластере реплик с помощью учетных данных сервера InnoDB Cluster и выполните команду dba.getCluster(). Эти учетные данные используются для некоторых операций в процессе настройки. Если в процессе настройки обнаружится, что учетные данные отсутствуют на автономном серверном экземпляре, будет возвращено сообщение об ошибке, и вам потребуется выполнить команду dba.configureInstance() для создания учетных данных.

При успешном выполнении команды серверный экземпляр добавляется в кластер реплик и снабжается данными для InnoDB ClusterSet. Источник для операции клонирования будет из кластера реплик, а не из основного кластера.

Повторите операцию cluster.addInstance, чтобы добавить все автономные серверные экземпляры в кластер реплик. Минимальное количество экземпляров для обеспечения отказоустойчивости рекомендуется три. Вы можете иметь до девяти серверных узлов в кластере реплик, что является ограничением, встроенным в технологию групповой репликации.

Убедитесь, что завершённый кластер реплик и развертывание InnoDB ClusterSet работоспособны. Вы можете сделать это, используя команду cluster.status() для просмотра кластера реплик и команду clusterSet.status() для просмотра развертывания InnoDB ClusterSet. Кроме того, вы можете выбрать расширенный вывод для clusterSet.status(), чтобы увидеть подробный статус всех кластеров. Например:

mysql-js> myclusterset.status({extended: 1})
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierStatus": "APPLIED_ALL",
                "applierThreadState": "Waiting for an event from Coordinator",
                "applierWorkerThreads": 4,
                "receiver": "127.0.0.1:4410",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "source": "127.0.0.1:3310"
            },
            "clusterSetReplicationStatus": "OK",
            "globalStatus": "OK",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:4410": {
                    "address": "127.0.0.1:4410",
                    "memberRole": "PRIMARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4420": {
                    "address": "127.0.0.1:4420",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4430": {
                    "address": "127.0.0.1:4430",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "0f6ff279-2764-11ec-ba06-00059a3c7a00:1-5,953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8",
            "transactionSetConsistencyStatus": "OK",
            "transactionSetErrantGtidSet": "",
            "transactionSetMissingGtidSet": ""
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

См. раздел 8.7 «Статус и топология InnoDB ClusterSet» для получения дополнительной информации о выводе команды clusterSet.status().

Добавьте дополнительные кластеры реплик по мере необходимости, повторив вышеуказанные шаги с другим набором автономных экземпляров. Ограничений на количество кластеров реплик, которые вы можете иметь в развертывании InnoDB ClusterSet, нет. Процесс в каждом случае одинаковый, как суммировано здесь:
- Создайте учетные данные сервера InnoDB Cluster на каждом из автономных серверных экземпляров, выполнив команду dba.configureInstance() с опцией clusterAdmin.
- Получите объект ClusterSet, используя команды dba.getClusterSet() или cluster.getClusterSet(), когда вы подключены к участнику InnoDB ClusterSet с помощью учетных данных сервера InnoDB Cluster. Вы можете получить объект с любого серверного узла в основном кластере или в одном из кластеров реплик, которые вы уже создали.
- Выполните команду clusterSet.createReplicaCluster(), используя объект ClusterSet, чтобы создать кластер реплик, указав имя одного из автономных серверных экземпляров.
- Используя объект Cluster, который был возвращён для кластера реплик командой clusterSet.createReplicaCluster(), выполните команду cluster.addInstance, указав имя другого из автономных серверных экземпляров.
- Повторите операцию cluster.addInstance, чтобы добавить все автономные серверные экземпляры в кластер реплик.
- Проверьте работоспособность завершённого кластера реплик и развертывания InnoDB ClusterSet, например, используя команду clusterSet.status() с расширенным выводом.
Запустите экземпляры MySQL Router против InnoDB ClusterSet для управления трафиком приложений и настройте их должным образом. По умолчанию MySQL Router направляет все запросы чтения и записи в тот кластер, который в данный момент является основным в развертывании InnoDB ClusterSet, но вы можете настроить экземпляр MySQL Router для маршрутизации трафика только в определённый кластер. Инструкции см. в разделе 8.6 «Интеграция MySQL Router с InnoDB ClusterSet».