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

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

mysql-js> \connect admin2@127.0.0.1:4410
Creating a session to 'admin2@127.0.0.1:4410'
Please provide the password for 'admin2@127.0.0.1:4410': ********
Save password for 'admin2@127.0.0.1:4410'? [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 71
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:4410>

mysql-js> myclusterset = dba.getClusterSet()
<ClusterSet:testclusterset>

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

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

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

InnoDB Cluster может переносить некоторые проблемы и работать достаточно хорошо, чтобы продолжить как часть развертывания InnoDB ClusterSet. Основной кластер, который работает приемлемо, имеет глобальный статус OK при проверке с помощью команды clusterSet.status(). Например, если один из серверов-членов кластера выходит из строя, даже если этот сервер является основным, технология Group Replication может справиться с этой ситуацией и переконфигурировать себя.

Если основной кластер всё ещё функционирует приемлемо в развертывании InnoDB ClusterSet в соответствии с отчётом о состоянии, но вам необходимо выполнить техническое обслуживание или устранить незначительные проблемы для улучшения работы основного кластера, вы можете выполнить контролируемую смену на кластер реплик. Затем вы можете вывести основной кластер из работы, при необходимости, исправить любые проблемы и запустить его повторно в развертывании InnoDB ClusterSet. Инструкции по выполнению этого действия см. в Разделе 9.8 «Контролируемая смена InnoDB ClusterSet».

Если основной кластер не работает приемлемо (с глобальным статусом NOT_OK) в развертывании InnoDB ClusterSet, но вы можете с ним связаться, сначала попробуйте исправить любые проблемы с помощью AdminAPI через MySQL Shell. Например, если основной кластер потерял кворум, его можно восстановить с помощью команды cluster.forceQuorumUsingPartitionOf. Инструкции по выполнению этого действия см. в Разделе 9.10 «Восстановление и повторное подключение InnoDB ClusterSet».

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

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

Проверьте параметры маршрутизации, заданные для каждого экземпляра 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 настроены на следование основному кластеру ("target_cluster": "primary"), трафик будет автоматически перенаправлен на новый основной кластер в течение нескольких секунд после переключения. Если для экземпляра MySQL Router параметр маршрутизации не отображается, как в примере выше с "target_cluster" для Rome2, это означает, что для этого экземпляра не задана эта политика, и он следует глобальной политике.

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

Если возможно, попытайтесь убедиться, что исходный основной кластер отключён, а если он подключён, попробуйте его остановить. Если он остаётся подключённым и продолжает получать трафик от клиентов, может возникнуть ситуация раскола, в которой отдельные части InnoDB ClusterSet расходятся.

Для продолжения аварийного переключения выполните команду clusterSet.forcePrimaryCluster(), указав кластер реплик, который станет новым основным кластером. Например:

mysql-js> myclusterset.forcePrimaryCluster("clustertwo")
Failing-over primary cluster of the clusterset to 'clustertwo'
* Verifying primary cluster status
None of the instances of the PRIMARY cluster 'clusterone' could be reached.
* Verifying clusterset status
** Checking cluster clustertwo
  Cluster 'clustertwo' is available
** Checking whether target cluster has the most recent GTID set
* Promoting cluster 'clustertwo'
* Updating metadata

PRIMARY cluster failed-over to 'clustertwo'. The PRIMARY instance is '127.0.0.1:4410'
Former PRIMARY cluster was INVALIDATED, transactions that were not yet replicated may be lost.

В команде clusterSet.forcePrimaryCluster():

При выполнении команды clusterSet.forcePrimaryCluster() MySQL Shell проверяет, соответствует ли целевой кластер реплик требованиям для перехода в роль основного кластера, и возвращает ошибку, если этого не происходит.

Если целевой кластер реплик удовлетворяет требованиям, MySQL Shell выполняет следующие задачи:

Во время аварийного переключения MySQL Shell не пытается синхронизировать целевой кластер реплик с текущим основным кластером и не блокирует текущий основной кластер. Если исходный основной кластер остаётся подключённым, он должен быть остановлен, как только с ним можно будет связаться.

Если у вас есть экземпляры MySQL Router, которые нужно переключить на целевой новый основной кластер, сделайте это сейчас. Вы можете настроить их на следование основному кластеру ("target_cluster": "primary") или указать кластер реплик, который принял на себя роль основного кластера ("target_cluster": "name_of_new_primary_cluster"). Например:

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

Выполните команду clusterSet.routingOptions(), чтобы проверить, что все экземпляры MySQL Router теперь правильно маршрутизируют.

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

Если и когда вы сможете снова связаться со старым основным кластером, сначала убедитесь, что к нему не направляется трафик приложений, и отключите его. Затем выполните процедуру в разделе 9.10 «Восстановление и повторное присоединение InnoDB ClusterSet», чтобы проверить транзакции и определить, как организовать топологию InnoDB ClusterSet в дальнейшем.

После аварийного переключения, и существует риск различий наборов транзакций между частями ClusterSet, необходимо изолировать кластер либо от записи трафика, либо от всего трафика. Более подробную информацию см. в Разделе «Изоляция кластеров в InnoDB ClusterSet».

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