9.10 InnoDB ClusterSet Repair and Rejoin — MySQL Shell 9.2

9.10 Восстановление и повторное присоединение InnoDB ClusterSet

Используйте эту информацию, если вам необходимо восстановить кластер в развертывании InnoDB ClusterSet. Вы можете использовать эту информацию в следующих ситуациях:

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

Раздел 9.7, «Статус и топология InnoDB ClusterSet» объясняет, как проверить статус кластера InnoDB и всего развертывания InnoDB ClusterSet, а также ситуации, в которых кластеру может потребоваться восстановление. Вы можете определить следующие ситуации из вывода команды clusterSet.status():

Кластер не имеет кворума (то есть, недостаточно узлов находятся в онлайн-режиме, чтобы иметь большинство).
Ни к одному узлу кластера невозможно подключиться.
Канал репликации ClusterSet кластера остановлен.
Канал репликации ClusterSet кластера настроен неправильно.
Набор GTID кластера не согласован с набором GTID основного кластера в InnoDB ClusterSet.
Кластер помечен как недействительный. Если кластер по-прежнему активен, команда предупреждает о возможном возникновении ситуации разделения головного мозга.

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

Контролируемое переключение подходит, если основной кластер функционирует приемлемо, но требует технического обслуживания или имеет незначительные проблемы. Основной кластер, который функционирует приемлемо, имеет глобальный статус OK при проверке с помощью команды clusterSet.status(). Раздел 9.8, «Контролируемое переключение InnoDB ClusterSet» объясняет, как выполнить эту операцию.
Аварийное переключение подходит, если вы не можете связаться с основным кластером. Раздел 9.9, «Аварийное переключение InnoDB ClusterSet» объясняет, как выполнить эту операцию.
Если основной кластер не функционирует должным образом (с глобальным статусом NOT_OK), но с ним можно связаться, попробуйте исправить любые проблемы, используя информацию в этом разделе. Аварийное переключение влечет за собой риск потери транзакций и создания ситуации разделения головного мозга для InnoDB ClusterSet. Если вы не сможете быстро восстановить основной кластер, чтобы восстановить доступность, выполните аварийное переключение, а затем, если это возможно, восстановите его.

Следуйте этой процедуре для восстановления кластера InnoDB, являющегося частью развертывания InnoDB ClusterSet:

С помощью MySQL Shell подключитесь к любому серверу узла в основном кластере или в одном из кластеров реплик, используя учетные данные администратора InnoDB Cluster (созданные с помощью cluster.setupAdminAccount()). Вы также можете использовать учетные данные сервера конфигурации InnoDB Cluster, которые также имеют необходимые разрешения. После установления подключения получите объект ClusterSet, используя команду dba.getClusterSet() или cluster.getClusterSet(). Важно использовать учетные данные администратора 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 42
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 (созданные с помощью cluster.setupAdminAccount()) или учетные данные сервера конфигурации InnoDB Cluster, получите объект Cluster, используя dba.getCluster(). Вы можете подключиться либо к любому узлу кластера, который вы восстанавливаете, либо к любому узлу InnoDB ClusterSet и использовать параметр name в команде dba.getCluster(), чтобы указать нужный кластер. Например:
```
mysql-js> cluster2 = dba.getClusterSet()
<Cluster:clustertwo>
```
Проверьте состояние кластера, используя команду cluster.status() AdminAPI в MySQL Shell. Используйте опцию extended, чтобы получить как можно больше подробностей о кластере. Например:
```
mysql-js> cluster2.status({extended: 2})
```
Объяснение вывода см. в Проверка состояния кластера с помощью Cluster.status().
После аварийного переключения и существует риск того, что наборы транзакций будут отличаться между частями ClusterSet, вам необходимо изолировать кластер либо от записи, либо от всех потоков данных. Раздел 9.10.1, «Изоляция кластеров в InnoDB ClusterSet» объясняет, как изолировать и разблокировать кластер с помощью MySQL Shell 8.0.28.
Если набор транзакций (набор GTID) в кластере не согласован, сначала исправьте это. Команда clusterSet.status() предупреждает вас, если набор GTID кластера реплики не согласован с набором GTID основного кластера в InnoDB ClusterSet. Кластер реплики в таком состоянии имеет глобальный статус OK_NOT_CONSISTENT. Вам также необходимо проверить набор GTID на бывшем основном кластере или кластере реплики, который был помечен как недействительный во время процедуры контролируемого переключения или аварийного переключения. Кластер с дополнительными транзакциями по сравнению с другими кластерами в ClusterSet может продолжать функционировать приемлемо в ClusterSet, пока он остаётся активным. Однако кластер с дополнительными транзакциями не может присоединиться к ClusterSet. Раздел 9.10.2, «Несогласованные наборы транзакций (наборы GTID) в кластерах InnoDB ClusterSet» объясняет, как обнаруживать и устранять проблемы с транзакциями на сервере.
Если существует техническая проблема с сервером узла в кластере или с общим членством в кластере (например, недостаточная отказоустойчивость или потеря кворума), вы можете работать с отдельными серверами узлов или изменить членство в кластере, чтобы исправить это. Раздел 9.10.3, «Восстановление серверов узлов и кластеров в InnoDB ClusterSet» описывает доступные операции для работы с серверами узлов в кластере.
Если вы не можете восстановить кластер, вы можете удалить его из InnoDB ClusterSet с помощью команды clusterSet.removeCluster(). Инструкции по выполнению этой операции см. в разделе 9.10.4, «Удаление кластера из InnoDB ClusterSet». Удаленный кластер InnoDB не может быть добавлен обратно в развертывание InnoDB ClusterSet. Если вы хотите снова использовать экземпляры серверов в развертывании, вам необходимо настроить новый кластер, используя их.
После восстановления кластера или выполнения необходимых операций технического обслуживания вы можете повторно присоединить его к InnoDB ClusterSet с помощью команды clusterSet.rejoin(). Эта команда проверяет, может ли кластер присоединиться, обновляет и запускает канал репликации ClusterSet, а также удаляет любой недействительный статус из кластера. Инструкции по выполнению этой операции см. в разделе 9.10.5, «Повторное присоединение кластера к InnoDB ClusterSet».