Используя MySQL Shell, подключитесь к любому серверу-члену в первичном кластере или в одном из реплицирующих кластеров, используя учетную запись администратора InnoDB Cluster (созданную с помощью cluster.setupAdminAccount()). Вы также можете использовать учетную запись конфигурации сервера InnoDB Cluster, которая также имеет необходимые разрешения. Получите объект ClusterSet, используя команду dba.getClusterSet() или cluster.getClusterSet(). Важно использовать учетную запись администратора InnoDB Cluster или учетную запись конфигурации сервера, чтобы учетная запись пользователя по умолчанию, хранящаяся в объекте ClusterSet, имела правильные разрешения. Например:

mysql-js> \connect admin2@127.0.0.1:3310
Creating a session to 'admin2@127.0.0.1:3310'
Please provide the password for 'admin2@127.0.0.1:3310': ********
Save password for 'admin2@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 52
Server version: 8.0.27-commercial MySQL Enterprise Server - Commercial
No default schema selected; type \use <schema> to set one.
<ClassicSession:admin2@127.0.0.1:3310>
mysql-js> myclusterset = dba.getClusterSet()
<ClusterSet:testclusterset>

В этом примере:

Проверьте состояние всего развертывания InnoDB ClusterSet, используя команду clusterSet.status() AdminAPI в MySQL Shell. Используйте опцию extended, чтобы просмотреть подробную информацию обо всех кластерах в развертывании и проверить наличие каких-либо проблем. Например:

mysql-js> myclusterset.status({extended: 1})

Для объяснения вывода см. раздел 9.7 «Состояние и топология InnoDB ClusterSet».

Определите подходящий реплицирующий кластер, который может заменить первичный кластер. Пригодность реплицирующего кластера для управляемого переключения зависит от его глобального состояния, как сообщается командой clusterSet.status():

У реплицирующего кластера с глобальным состоянием OK_NOT_CONSISTENT есть набор транзакций в кластере (набор GTID), который не соответствует набору GTID в первичном кластере. InnoDB ClusterSet не разрешает управляемое переключение на кластер в этом состоянии, потому что клиенты будут получать неверные данные. Аварийный переход возможен, если кластер имеет наиболее актуальный набор транзакций среди доступных вариантов.

Проверьте параметры маршрутизации, которые установлены для каждого экземпляра MySQL Router, и глобальную политику для развертывания InnoDB ClusterSet, выполнив команду clusterSet.routingOptions() в MySQL Shell, подключившись к любому серверу-члену в развертывании InnoDB ClusterSet. Например:

mysql-js> myclusterset.routingOptions()
{
    "domainName": "testclusterset",
    "global": {
        "invalidated_cluster_policy": "drop_all",
        "target_cluster": "primary"
    },
    "routers": {
        "Rome1":  {
            "target_cluster": "primary"
        },
        "Rome2": {}
    }
}

По умолчанию экземпляр MySQL Router отправляет трафик в кластер, который в настоящее время является первичным в развертывании InnoDB ClusterSet. Если все экземпляры MySQL Router настроены на следование первичному ("target_cluster": "primary"), трафик будет автоматически перенаправлен на новый первичный кластер в течение нескольких секунд после переключения. Если параметр маршрутизации не отображается для экземпляра MySQL Router, как в примере выше для Rome2, это означает, что для экземпляра не установлена эта политика, и он следует глобальной политике.

Если какие-либо экземпляры настроены на целевой первичный кластер по имени ("target_cluster": "name_of_primary_cluster"), они не перенаправят трафик на новый первичный. В этой ситуации, если это уместно для приложения, вы можете использовать команду clusterSet.setRoutingOption(), чтобы изменить политику маршрутизации для этих экземпляров. Вы можете изменить эти экземпляры на следование первичному ("target_cluster": "primary"), в этом случае этот параметр можно установить сейчас. Например:

mysql-js> myclusterset.setRoutingOption('Rome1', 'target_cluster', 'primary')
Routing option 'target_cluster' successfully updated in router 'Rome1'.

В этом примере myclusterset — переменная для объекта ClusterSet, а Rome1 — имя экземпляра MySQL Router.

Или вы можете указать реплицирующий кластер, который станет первичным, в этом случае установите параметр ("target_cluster": "name_of_new_primary_cluster") после того, как переключение будет выполнено, когда вы убедитесь, что оно сработало.

Выполните команду clusterSet.setPrimaryCluster(), указав реплицирующий кластер, который станет новым первичным кластером. Используйте объект ClusterSet, который вы получили, используя учетную запись администратора InnoDB Cluster, с помощью команды dba.getClusterSet() или cluster.getClusterSet(). Например:

mysql-js> myclusterset.setPrimaryCluster('clustertwo')
Switching the primary cluster of the clusterset to 'clustertwo'
* Verifying clusterset status
** Checking cluster clustertwo
  Cluster 'clustertwo' is available
** Checking cluster clusterone
  Cluster 'clusterone' is available

* Refreshing replication account of demoted cluster
* Synchronizing transaction backlog at 127.0.0.1:4410
** Transactions replicated  ############################################################  100%
* Updating metadata

* Updating topology
** Changing replication source of 127.0.0.1:3330 to 127.0.0.1:4410
* Acquiring locks in replicaset instances
** Pre-synchronizing SECONDARIES
** Acquiring global lock at PRIMARY
** Acquiring global lock at SECONDARIES

* Synchronizing remaining transactions at promoted primary
** Transactions replicated  ############################################################  100%
* Updating replica clusters
Cluster 'clustertwo' was promoted to PRIMARY of the clusterset. The PRIMARY instance is '127.0.0.1:4410'

Для команды clusterSet.setPrimaryCluster():

При выполнении команды clusterSet.setPrimaryCluster() MySQL Shell проверяет, соответствует ли целевой реплицирующий кластер требованиям для замены первичного кластера, и возвращает ошибку, если нет. Если целевой реплицирующий кластер соответствует требованиям, MySQL Shell выполняет следующие задачи:

Выполните команду clusterSet.status() еще раз, используя опцию extended, чтобы проверить состояние развертывания InnoDB ClusterSet.

Если у вас есть экземпляры MySQL Router, которые нужно переключить на целевой первичный кластер, сделайте это сейчас. Например:

mysql-js> myclusterset.setRoutingOption('Rome1', 'target_cluster', 'clustertwo')
Routing option 'target_cluster' successfully updated in router 'Rome1'.

В этом примере myclusterset — переменная для объекта ClusterSet, Rome1 — имя экземпляра MySQL Router, а clustertwo — имя конкретного целевого кластера. Когда вы закончите, выполните команду clusterSet.routingOptions(), чтобы проверить, что все экземпляры MySQL Router теперь правильно маршрутизируют трафик.

Теперь вы можете работать со старым первичным кластером для устранения неполадок или проведения технического обслуживания. Если вам пришлось сделать недействительными какие-либо реплицируемые кластеры во время процесса переключения, вы также можете восстановить их и добавить обратно в InnoDB ClusterSet. Раздел 9.10, «InnoDB ClusterSet Repair and Rejoin» описывает, как устранить неполадки с кластером, как присоединить кластер к InnoDB ClusterSet и как сделать кластер первичным кластером снова.