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

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

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

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

Если основной кластер не функционирует удовлетворительно (с глобальным статусом NOT_OK) в развертывании InnoDB ClusterSet, но вы можете с ним связаться, сначала попробуйте исправить любые проблемы, используя AdminAPI через MySQL Shell. Например, если основной кластер потерял кворум, его можно восстановить, используя команду cluster.forceQuorumUsingPartitionOf. Инструкции по выполнению этого действия см. в разделе 8.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.

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

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

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