8.8.3 Rebooting a Cluster from a Major Outage — MySQL Shell 9.2

8.8.3 Перезапуск кластера после крупного сбоя

Если ваш кластер полностью вышел из строя, вы можете перенастроить его, используя dba.rebootClusterFromCompleteOutage(). Эта операция позволяет вам подключиться к одному из экземпляров MySQL кластера и использовать его метаданные для восстановления кластера.

Полный сбой означает, что групповая репликация остановлена на всех экземплярах-членах.

Примечание

Убедитесь, что все члены кластера запущены перед выполнением dba.rebootClusterFromCompleteOutage(). Команда завершится ошибкой, если какой-либо из членов кластера недоступен.

Эта проверка игнорируется, если кластер помечен как НЕВАЛИДНЫЙ и является членом набора кластеров.

Подключитесь к самому последнему экземпляру и выполните следующую команду:

  JS> var cluster = dba.rebootClusterFromCompleteOutage()

Если у всех членов установлен одинаковый набор GTID, член, к которому вы сейчас подключены, становится первичным. См. Выбор первичного члена с rebootClusterFromCompleteOutage.

Операция dba.rebootClusterFromCompleteOutage() выполняется по этим шагам, чтобы обеспечить правильную перенастройку кластера:

Метаданные кластера и топология кластера извлекаются из текущего экземпляра.
Если член кластера находится в состоянии ВОССТАНОВЛЕНИЯ или ОШИБКА, а все остальные члены — в состоянии ОФФЛАЙН или ОШИБКА, dba.rebootClusterFromCompleteOutage() пытается остановить групповую репликацию на этом члене. Если групповая репликация не может быть остановлена, команда завершается и отображается ошибка.
Проверяются метаданные InnoDB кластера, найденные на экземпляре, к которому в настоящее время подключена оболочка MySQL, чтобы увидеть, содержит ли он супермножество GTID. Если текущий подключенный экземпляр не содержит супермножество GTID, операция прерывается с этой информацией.

См. Супермножество GTID.
Если экземпляр содержит супермножество GTID, кластер восстанавливается на основе метаданных, хранящихся в этом экземпляре.
Оболочка MySQL проверяет, какие экземпляры кластера в настоящее время доступны, и завершается ошибкой, если какой-либо член в настоящее время недоступен.

Примечание

Можно обойти эту проверку, используя опцию force. Это перезапускает кластер, используя оставшиеся доступные члены.

См. Опцию принудительного режима.
Аналогично, оболочка MySQL определяет экземпляры, которые в настоящее время недоступны. Добавить или удалить бывших членов в кластер как часть команды dba.rebootClusterFromCompleteOutage(), если они в настоящее время недоступны, нельзя.
Если включено на первичном экземпляре кластера, в режиме с единой первичной копией, оно отключено.

Супермножество GTID

Для перезапуска кластера необходимо подключиться к члену с супермножеством GTID, что означает экземпляр, который применил больше всего транзакций до сбоя.

Чтобы определить, какой член имеет супермножество GTID, выполните одно из следующих действий:

Подключитесь к экземпляру и выполните dba.rebootClusterFromCompleteOutage() с dryRun: true. Сгенерированный отчет возвращает информацию, подобную следующей:
```
              Switching over to instance '127.0.0.1:4001' to be used as seed.
            
```
Это указывает на член с супермножеством GTID.

Выполнение dba.rebootClusterFromCompleteOutage() на члене с меньшим набором GTID приводит к ошибке.
Подключитесь к каждому экземпляру по очереди и выполните следующую команду в режиме SQL:
```
SHOW VARIABLES LIKE 'gtid_executed';
```
Экземпляр, который применил наибольшее количество транзакций, содержит супермножество GTID.

Примечание

Можно переопределить это поведение и использовать экземпляр с меньшим набором GTID, выполнив dba.rebootClusterFromCompleteOutage() с опцией force.

Это делает выбранный член первичным и отбрасывает любые транзакции, не включенные в набор GTID выбранного члена.

Если этот процесс завершается ошибкой и метаданные кластера сильно повреждены, возможно, потребуется удалить метаданные и создать кластер заново. Вы можете удалить метаданные кластера, используя dba.dropMetadataSchema().

Предупреждение

Метод dba.dropMetadataSchema() должен использоваться только в крайних случаях, когда восстановление кластера невозможно. Его нельзя отменить.

Если вы используете MySQL Router с кластером, при удалении метаданных все текущие соединения будут закрыты, а новые соединения запрещены. Это приводит к полному сбою.

Параметры

dba.rebootClusterFromCompleteOutage() имеет следующие параметры:

force: true | false (default): Если значение true, операция должна быть выполнена, даже если некоторые члены кластера недоступны или выбранный первичный экземпляр имеет расхождения или меньший набор GTID. См. Опцию принудительного режима
dryRun: true | false (default): выполняет все проверки и шаги команды, но без внесения изменений. После завершения отображается отчет. См. Тестирование rebootClusterFromCompleteOutage.
primary: Определение экземпляра, который должен быть выбран в качестве первичного. См. Выбор первичного члена с rebootClusterFromCompleteOutage.
switchCommunicationStack: mysql | xcom: Протокол стека групповой репликации, который будет использоваться кластером после перезапуска. См. Раздел 8.5.9, «Настройка стека коммуникаций групповой репликации».
ipAllowList: Список хостов, разрешенных для подключения к экземпляру для трафика групповой репликации при использовании протокола XCOM.
localAddress: строковое значение с локальным адресом групповой репликации, используемым вместо автоматически сгенерированного, при использовании протокола XCOM.

Опция принудительного режима

Опция force позволяет игнорировать доступность членов кластера или расхождение наборов GTID в выбранном члене и перезапустить кластер.

Например, перезапуск кластера myCluster:

  JS> var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{force: true})

Опция force не допускается в следующих ситуациях:

Если кластер принадлежит набору кластеров и помечен как НЕВАЛИДНЫЙ, или первичный кластер не находится в глобальном статусе OK.
Если кластер принадлежит набору кластеров, является первичным кластером и помечен как НЕВАЛИДНЫЙ.

Добавление или повторное подключение экземпляров с помощью rebootClusterFromCompleteOutage невозможно. Если вы использовали force для игнорирования недоступных членов и перезапуска вашего кластера, вы должны использовать cluster.rejoinInstance() для добавления недоступных членов в кластер.

Выбор первичного члена с rebootClusterFromCompleteOutage

Вы можете определить первичный член кластера следующими способами:

Определите опцию primary в команде dba.rebootClusterFromCompleteOutage().

Например, перезапуск кластера myCluster и установка члена, запущенного на локальной машине на порту 4001, в качестве первичного:
```
var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001"})
          
```
Используя опцию primary с опцией force на члене кластера с меньшим набором GTID, чем у другого члена.

Тестирование rebootClusterFromCompleteOutage

Вы можете протестировать изменения, используя опцию dryRun. Эта опция валидирует команду и её параметры, генерирует журнал результатов. Если с предлагаемыми изменениями есть проблема, будет выброшено исключение.

Следующий пример демонстрирует пробный запуск перезапуска кластера, myCluster, установку первичного члена на локальный член, работающий на порту 4001, и возвращаемое сообщение журнала:

JS > var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001", dryRun: true})

NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
Cluster instances: '127.0.0.1:4000' (OFFLINE), '127.0.0.1:4001' (OFFLINE), '127.0.0.1:4002' (OFFLINE)
Switching over to instance '127.0.0.1:4001' to be used as seed.
dryRun finished.

Учет наборов кластеров и реплик

rebootClusterFromCompleteOutage выполняет следующие проверки и генерирует предупреждение, если кластер не соответствует требованиям:

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

Команда автоматически повторно подключает кластер реплик к набору кластеров, обеспечивая, что канал репликации набора кластеров настроен для всех членов кластера.

END_OF_DOCUMENT_MARKER

Переключение стека коммуникаций

Вы можете переключить стек коммуникаций во время операции dba.rebootClusterFromCompleteOutage().

Например:

        js> dba.rebootClusterFromCompleteOutage("testcluster", {switchCommunicationStack: "mysql"})

Переключение с протокола MYSQL на XCOM требует дополнительного сетевого адреса для localAddress и, возможно, также потребует определения значений ipAllowList.