Используя 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})

Для объяснения вывода см. Раздел 8.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. Раздел 8.10, «InnoDB ClusterSet Repair and Rejoin» объясняет, как устранить неполадки в кластере, как присоединить кластер к InnoDB ClusterSet и как сделать кластер снова основным кластером.