8.10 InnoDB ClusterSet Repair and Rejoin — MySQL Shell 8.4

8.10 Ремонт и повторное присоединение InnoDB ClusterSet

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

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

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

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

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

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

Следуйте этой процедуре, чтобы отремонтировать InnoDB Cluster, который является частью развертывания 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})
```
Объяснение вывода см. в разделе 8.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, вы должны изолировать кластер или от операций записи или от всех операций. Раздел 8.10.1, «Блокировка кластеров в InnoDB ClusterSet» объясняет как, изолировать и разблокировать кластер, с помощью MySQL Shell 8.0.28.
Если набор транзакций (набор GTID) в кластере несовместим, сначала исправьте эту проблему. Команда clusterSet.status() предупреждает вас, если набор GTID реплицирующего кластера несовместим с набором GTID первичного кластера в InnoDB ClusterSet. Реплицирующий кластер в этом состоянии имеет глобальный статус OK_NOT_CONSISTENT. Также необходимо проверить набор GTID на бывшем первичном кластере или реплицирующем кластере, который был помечен как недействительный во время управляемого переключения или аварийного переключения. Кластер с дополнительными транзакциями по сравнению с другими кластерами в ClusterSet может продолжать приемлемо работать в ClusterSet, пока он активен. Однако кластер с дополнительными транзакциями не может присоединиться к ClusterSet. Раздел 8.10.2, «Несовместимые наборы транзакций (GTID) в кластерах InnoDB ClusterSet» объясняет, как обнаружить и устранить проблемы с транзакциями на сервере.
Если есть техническая проблема с узлом-сервером в кластере или с общим составом кластера (например, недостаточной отказоустойчивостью или потерей кворума), вы можете работать с отдельными узлами-серверами или корректировать состав кластера для решения этой проблемы. Раздел 8.10.3, «Ремонт узлов серверов и кластеров в InnoDB ClusterSet» объясняет доступные операции для работы с узлами-серверами в кластере.
Если вы не можете отремонтировать кластер, вы можете удалить его из InnoDB ClusterSet с помощью команды clusterSet.removeCluster(). Инструкции см. в разделе 8.10.4, «Удаление кластера из InnoDB ClusterSet». Удаленный InnoDB Cluster не может быть добавлен обратно в развертывание InnoDB ClusterSet. Если вы хотите снова использовать экземпляры серверов в развертывании, вам необходимо настроить новый кластер, используя их.
После ремонта кластера или выполнения необходимых операций технического обслуживания вы можете повторно присоединить его к InnoDB ClusterSet с помощью команды clusterSet.rejoin(). Эта команда проверяет возможность повторного присоединения кластера, обновляет и запускает канал репликации ClusterSet и удаляет любой недействительный статус из кластера. Инструкции см. в разделе 8.10.5, «Повторное присоединение кластера к InnoDB ClusterSet».