7.8.3 Rebooting a Cluster from a Major Outage — MySQL Shell 8.4

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

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

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

Примечание

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

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

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

  JS> var cluster = dba.rebootClusterFromCompleteOutage()

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

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

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

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

Примечание

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

См. Опция принуждения.
Аналогично, MySQL Shell обнаруживает экземпляры, которые в настоящее время недоступны. Добавить или удалить бывших членов в кластер в рамках команды 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): Если истинно, операция должна быть выполнена, даже если некоторые члены кластера недоступны, или выбранный первичный экземпляр имеет расходящийся или меньший набор GTID_SET. См. Опцию принуждения
dryRun: true | false (default): выполняет все проверки и шаги команды, но никаких изменений не вносит. По завершении отображается отчёт. См. Тестирование rebootClusterFromCompleteOutage.
primary: Определение экземпляра, который должен быть выбран в качестве первичного. См. Выбор первичного члена с помощью rebootClusterFromCompleteOutage.
switchCommunicationStack: mysql | xcom: Стек протоколов групповой репликации, который будет использоваться кластером после перезапуска. См. Раздел 7.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). См. .
Подтверждает, что набор выполненных транзакций кластера () не пустой.

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

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

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

Например:

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

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