9.4 Deploying InnoDB ClusterSet — MySQL Shell 9.2

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

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

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

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

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

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

Подключитесь к любому узловому серверу в существующем кластере InnoDB с помощью MySQL Shell, используя учетные данные конфигурации сервера кластера InnoDB для подключения. Например:
```
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.
- 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. Возвращаемый объект по умолчанию использует учетные данные, с помощью которых он был получен, для операций, требующих разрешений. Некоторые операции во время развертывания 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."
}
```
Для получения дополнительной информации и описания вывода команды clusterSet.status(), см. Раздел 9.7, “InnoDB ClusterSet Status and Topology”.

Если вы хотите получить объект 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 на каждом из автономных экземпляров сервера, которые будут частью реплицируемого кластера, выполнив команду dba.configureInstance() с опцией clusterAdmin. Создаваемый аккаунт — это учетные данные конфигурации сервера кластера InnoDB из основного кластера, которые вы использовали для создания ClusterSet. Не указывайте учетные данные администратора кластера InnoDB (созданные с помощью 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, которые будут созданы на экземпляре. Для повышения безопасности укажите пароль для учетных данных конфигурации сервера кластера InnoDB в интерактивном запросе, как показано в примере, или вы можете предоставить его с помощью опции clusterAdminPassword. Команда dba.configureInstance() автоматически предоставляет учётной записи необходимые права, хотя вы можете настроить учётную запись вручную, предоставив ей права, указанные в Руководстве по настройке учетных записей администратора InnoDB Cluster вручную. Более подробные сведения о команде dba.configureInstance() и её опциях см. в разделе 8.4.2, «Настройка производственных экземпляров для использования с InnoDB Cluster».

При выполнении команды dba.configureInstance(), MySQL Shell проверяет, соответствует ли экземпляр сервера требованиям для использования с InnoDB Cluster. Требования к InnoDB ClusterSet будут проверены при выполнении команд создания реплицируемого кластера и добавления к нему экземпляров.
Подключитесь к любому активному экземпляру в основном кластере, который уже входит в развертывание InnoDB ClusterSet, используя учетные данные конфигурации сервера кластера InnoDB. Убедитесь, что у вас по-прежнему есть объект ClusterSet, который был возвращен при создании InnoDB ClusterSet, или получите его снова, используя команды dba.getClusterSet() или cluster.getClusterSet(). Опять же, это важно, когда вы подключены к экземпляру сервера с помощью учетных данных конфигурации сервера кластера InnoDB. Учетные данные пользователя по умолчанию, хранящиеся в объекте, используются для некоторых операций во время развертывания 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. См. Раздел 8.5.9, «Настройка стека коммуникаций Group Replication».
  
  Если вы используете MySQL 8.0.27 или более позднюю версию, значение по умолчанию и рекомендуемый протокол — MYSQL.
- Опции memberSslMode, ipAllowlist, localAddress, exitStateAction, memberWeight, consistency, expelTimeout и autoRejoinTries доступны, если вы хотите настроить настройку Group Replication для реплики InnoDB Cluster. Эти опции работают так же, как и для InnoDB Cluster, который не является частью ClusterSet. Подробную информацию об этих опциях см. в Разделе 8.5, «Настройка InnoDB Cluster». (Примечание: ipAllowlist и localAddress доступны только для стека коммуникаций XCOM.)
- Можно использовать опции localAddress и groupName для задания локального адреса Group Replication и идентификатора группы. Однако это не рекомендуется, так как неправильные значения могут привести к ошибкам в Group Replication. Используйте эти опции только в случае возникновения проблем со значениями, выбранными процессом настройки InnoDB ClusterSet для этих элементов.
- При создании InnoDB ClusterSet, если у вас есть требования безопасности, чтобы все автоматически создаваемые учетные записи AdminAPI имели строгие требования к аутентификации, можно задать значение для конфигурационного параметра replicationAllowedHost ClusterSet. Опция MySQL Shell replicationAllowedHost позволяет настроить учетные записи репликации, управляемые внутри, для ClusterSet на строгий фильтр на основе подсети вместо значения по умолчанию с подстановкой %. Опция replicationAllowedHost принимает строковое значение. Например, чтобы создать clusterset под названием 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 на экземпляр сервера. Если экземпляр провиженирован путем передачи состояния из бинарного лога, процесс провиженирования включает транзакции, создающие учетные записи, или же учетные записи передаются во время клонирования. В любом случае эти учетные записи становятся доступными на экземпляре сервера. Дополнительную информацию см. в Разделе 9.3, «Учетные записи пользователей для InnoDB ClusterSet».
- Настраивает и запускает Group Replication для кластера реплики. Процесс создания кластера реплики InnoDB ClusterSet перезаписывает любые существующие сохраненные конфигурационные параметры Group Replication, для которых вы укажете новые настройки в команде clusterSet.createReplicaCluster(). Он также всегда перезаписывает следующие конфигурационные параметры, даже если вы их не укажете в команде: , , , (версии 8.0.27 до 8.2.0, только) и . Однако любые другие конфигурационные параметры Group Replication, которые вы изменили на экземпляре сервера до его использования в кластере реплики, останутся неизменными. См. важное примечание об этом в Разделе 9.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 см. в разделе 8.4.4 «Добавление экземпляров в кластер InnoDB».

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

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

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

Убедитесь, что завершенный кластер репликации и развертывание 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."
}

См. раздел 9.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 для маршрутизации трафика только в определенный кластер. Инструкции см. в разделе 9.6 «Интеграция MySQL Router с InnoDB ClusterSet».