Команда разработчиков MySQL с радостью объявляет о выпуске новой версии 8.0 для поддержки MySQL Shell AdminAPI — 8.0.20!

После предыдущего захватывающего выпуска, в котором был представлен InnoDB ReplicaSet, в следующем сосредоточились на улучшении управления ReplicaSets, а также, что наиболее важно, кластера InnoDB.

Здесь вы ознакомитесь и увидите как обновить MySQL Shell до новой версии!

MySQL Shell AdminAPI

Этот выпуск сфокусирован на улучшениях управления для AdminAPI, а именно:

• Упрощение и улучшение обработки учетных записей администратора: новые команды для настройки учетных записей администратора кластера MySQL InnoDB, ReplicaSet и Router.
• Интеграция MySQL Shell с InnoDB ReplicaSet: аналогично для InnoDB Cluster, сама Shell получила расширения, обеспечивающие простоту использования при управлении ReplicaSets.
• Создание взаимоисключающих операций ReplicaSet: убедитесь, что операции ReplicaSet заблокированы, чтобы избежать различных операций по выполнению изменений в одном и том же ReplicaSet.

И как всегда, качество было значительно улучшено с исправлением многих ошибок!

Управление учетными записями администратора

Развертывание кластера InnoDB или ReplicaSet включает настройку учетных записей администратора. Это необходимо для:

1. Администрируйте кластер/репликацию через AdminAPI Shell.
2. Загрузчик MySQL Router в кластере/репликации.
3. Разрешить MySQL Router работать в кластере/репликации.

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

Для этой цели AdminAPI предоставляет пользователям очень простой способ выполнить это:

Использование dba.configureInstance() с опцией clusterAdmin.

Например, типичная настройка кластера InnoDB будет состоять из следующей последовательности шагов:

mysql-js> // Настройте экземпляры для использования IDC + создайте учетную запись администратора
mysql-js> dba.configureInstance("root@instance1:3306", {clusterAdmin: "myAdmin"});
mysql-js> dba.configureInstance("root@instance2:3306", {clusterAdmin: "myAdmin"});
mysql-js> dba.configureInstance("root@instance3:3306",
{clusterAdmin: "myAdmin"});
mysql-js>
mysql-js> // Подключитесь с помощью вновь созданной учетной записи администратора и создайте кластер
mysql-js> \c myAdmin@instance1:3306
mysql-js> var cluster = dba.createCluster("myCluster");
mysql-js>
mysql-js> // Добавьте экземпляры в кластер
mysql-js> cluster.addInstance("myAdmin@instance2:3306");
mysql-js> cluster.addInstance("myAdmin@instance3:3306");
mysql-js>
mysql-js> // Выйдите из mysqlsh и загрузите маршрутизатор
mysql-js> \quit
Bye!

$ mysqlrouter --bootstrap myAdmin@instance1:3306 ...

Частые препятствия

Учитывая вышесказанное, следующие сценарии стали обычными в любой рабочей среде высокой доступности:

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

Учитывая это, а также постоянную заботу о предоставлении наиболее простого, но мощного AdminAPI,упростили все управление учетными записями.

Новый подход

В этом выпуске вы сможете использовать следующие новые команды:

.setupRouterAccount(user, [options])
.setupRouterAccount(user, [options])

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

И, следующие новые команды:

.setupAdminAccount(user, [options])
.setupAdminAccount(user, [options])

… Настроить централизованную учетную запись администратора кластера/репликации, избегая необходимости создавать clusterAdminучетные записи на каждом элементе кластера с одинаковыми учетными данными.

Переформулировка типичной последовательности шагов для настройки кластера InnoDB на следующие:

mysql-js> // Настройте экземпляры для использования IDC
mysql-js> dba.configureInstance("root@instance1:3306")
mysql-js> dba.configureInstance("root@instance2:3306")
mysql-js> dba.configureInstance("root@instance2:3306")
mysql-js>
mysql-js> // Подключитесь к целевому экземпляру и создайте кластер
mysql-js> \c root@instance1:3306
mysql-js> var cluster = dba.createCluster("myCluster")
mysql-js>
mysql-js> // Создание учетной записи администратора кластера
mysql-js> cluster.setupAdminAccount("clusterAdmin")
mysql-js>
mysql-js> // Подключитесь с помощью недавно созданной учетной записи администратора кластера и выполните управление/настройку кластера
mysql-js> \c clusterAdmin@instance1:3306
mysql-js> var cluster = dba.getCluster()
mysql-js> cluster.addInstance("root@instance2:3306");
mysql-js> cluster.addInstance("root@instance3:3306");
mysql-js>
mysql-js> // Создайте учетную запись администратора маршрутизатора
mysql-js> cluster.setupRouterAccount("routerAccount");
mysql-js>
mysql-js> // Выход mysqlsh и начальной загрузки маршрутизатора, используя вновь созданную учетную запись администратора роутера
mysql-js> \quit
Bye!

$ mysqlrouter --bootstrap clusterAdmin@instance1:3306 --account=routerAccount ...

Новые права на обработку метаданных

С новой схемой метаданных и функцией обновления, представленной в 8.0.19, текущий набор привилегий, предоставленных учетным записям clusterAdmin, созданным с использованием, dba.configureInstance()стал недостаточным.

Чтобы пользователи могли обновить свои текущие кластеры до последней схемы метаданных, используя те же учетные записи clusterAdmin, новые команды также могут использоваться для обновления учетных записей, чтобы включить все необходимые привилегии. Это достигается путем использования updateопции:

mysql-js> // Обновите привилегии учетных записей clusterAdmin
mysql-js> cluster.setupAdminAccount("myAdmin@instance1", {update: true});
...
mysql-js> cluster.setupAdminAccount("myAdmin@instance2", {update: true});
...

Интеграция MySQL Shell с ReplicaSet

Для работы InnoDB ReplicaSet требуется  объект. Таким образом, аналогично в InnoDB Cluster, AdminAPI предоставляет команду dba.getReplicaSet(), которая возвращает дескриптор ReplicaSet. Однако для кластера InnoDB можно запустить MySQL Shell с уже созданным и заполненным объектом кластера, используя параметр командной строки:

--cluster

Эта функция была теперь перенесена на InnoDB ReplicaSet! Теперь можно запустить MySQL Shell и использовать следующий параметр командной строки, чтобы получить заполненный объект ReplicaSet:

--replicaSet

Пример:

$ mysqlsh --replicaset clusterAdmin@instance1:3306

В рамках этого порта также расширили следующие команды для поддержки ReplicaSet:

• —redirect-primary : Подключение к первичному серверу ReplicaSet;
• —redirect-secondary : Подключение к вторичному серверу ReplicaSet;

Это еще один шаг вперед по удобству использования!

Более безопасное управление InnoDB ReplicaSet

AdminAPI, как панель управления InnoDB ReplicaSets, предоставляет наиболее приятное и простое в использовании решение для пользователей. Тем не менее, он также несет ответственность за обеспечение безопасной среды для таких задач управления.

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

Давайте проиллюстрируем катастрофический сценарий: администраторы БД AndreyEx и Destroyer  работают над одним и тем же ReplicaSet и практически одновременно:

AndreyEx:

mysql-js> // Primary switchover
mysql-js> replicaset.setPrimaryInstance("instance2");

Запуск следующих действий:

1. Метаданные обновлены и зарегистрировано изменение топологии (view_id)
2. «Старый» основной становится доступным только для чтения

Destroyer :

mysql-js> // Добавьте новый экземпляр в набор ReplicaSet
mysql-js> replicaset.addInstance("instance4");

Причина сбоя из-за одного из следующих факторов:

1. Обновление метаданных для включения нового экземпляра происходит сбой, поскольку основной стал R/O
2. Изменение топологии view_id в метаданных конфликтует, поскольку оно уже существует с тем же идентификатором.

И в конечном итоге приводит к неожиданному/неизвестному результату.

В этом выпуске это больше не проблема, поскольку операции ReplicaSet стали взаимоисключающими!

Замки на помощь

Внедрили механизм блокировки для операций ReplicaSet, который гарантирует, что никакие операции, которые изменяют топологию метаданных и/или ReplicaSet, не могут быть выполнены одновременно. Блокировки могут быть глобальными или на уровне экземпляра.

Подробно:

• dba.upgradeMetadata() и dba.createReplicaSet() являются глобально исключительными операциями. Никакие другие операции не могут быть выполнены в том же ReplicaSet или любом из его экземпляров, пока они выполняются.
• <ReplicaSet>.forcePrimaryInstance() и <ReplicaSet>.setPrimaryInstance() являются операциями, которые изменяют основной, поэтому требуется особое внимание. Принятый подход гарантирует, что никакие другие операции, которые изменяют первичные обновления или обновления экземпляра, не могут быть выполнены, пока первая операция не завершится.
• <ReplicaSet>.addInstance(), <ReplicaSet>.rejoinInstance() и <ReplicaSet>.removeInstance() — это операции, которые изменяют экземпляр. Для этих операций была реализована блокировка на уровне экземпляра, обеспечивающая выполнение операции за раз для каждого экземпляра, но позволяющая одновременно выполнять несколько операций в разных экземплярах.

Исправлены заметные ошибки

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

Ошибки, связанные с клоном

Благодаря интеграции подключаемого модуля MySQL Clone в InnoDB Cluster и ReplicaSet, подготовка стала такой же простой, как пирог. На сегодняшний день это одна из наиболее важных встроенных технологий, доступных через AdminAPI, обеспечивающая всегда доступную инициализацию с невероятно быстрой скоростью.

Было обнаружено несколько ошибок, которым было уделено особое внимание в этом выпуске.

Ошибка # 30657911 — <REPLICASET>.ADDINSTANCE() USING CLONE SEGFAULTS WHEN RESTART IS NOT AVAILABLE

Использование клона в качестве метода обеспечения для добавления экземпляра в ReplicaSet привело к падению, если целевой экземпляр не поддерживал RESTART. Эта ошибка была исправлена ​​в этом выпуске, и поведение ReplicaSet.addInstance() было расширено, чтобы учитывать такой сценарий, и всякий раз, когда истекает время ожидания операции, команда отменяет и отменяет изменения.

Ошибка # 30866632 — TIMEOUT FOR SERVER RESTART AFTER CLONE TOO SHORT

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

По этой причине был добавлен новый глобальный параметр dba.restartWaitTimeout в  Shell, позволяющий пользователям устанавливать правильное значение для времени перезапуска.

mysql-js> // Проверьте текущие параметры на месте
mysql-js> shell.options
mysql-js> // Измените значение dba.restartWaitTimeout
mysql-js> shell.options.set("dba.restartWaitTimeout", 300);

Ошибка # 30645697 — RECOVERYMETHOD:CLONE WHEN ALL MEMBERS ARE IPV6 WILL ALLOW ERRANT GTIDS

Один из возможных вариантов использования для клонирования — разрешить добавление экземпляра с дивергентным GTID-набором в кластер. Тем не менее, плагин MySQL Clone имеет ограничение в отношении использования IPv6. В частности, если все члены кластера используют IPv6, доноры использовать нельзя, поскольку Clone не поддерживает использование адресов IPv6 для действительного списка доноров. Таким образом, в сценарии, в котором все участники используют IPv6 и был выбран клон, клон завершится ошибкой и откатится к постепенному восстановлению.

В конечном счете, экземпляр будет добавлен в кластер с использованием инкрементного восстановления, но из-за различий набора GTID экземпляр не будет принят в кластере.

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

Ошибки, связанные с кластером InnoDB

InnoDB Cluster, как основное решение MySQL HA, привлекло внимание несколькими исправлениями ошибок:

Ошибка # 30739252 — RACE CONDITION IN FORCEQUORUM

В некоторых конкретных ситуациях, в которых .forceQuorumUsingPartitionOf() использовалась разблокировка кластера, потерявшего свой кворум, происходило неопределенное и неожиданное поведение, вызывающее несоответствия в кластере. Эти ситуации были видны только тогда, когда autoRejoinTries имело значение выше нуля.

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

Ошибка # 30661129 — DBA.UPGRADEMETADATA() AND DBA.REBOOTCLUSTERFROMCOMPLETEOUTAGE() BLOCK EACH OTHER

В предыдущем выпуске 8.0.19 были представлены InnoDB ReplicaSet и новая версия схемы метаданных. Чтобы разрешить непрерывное обновление, была также добавлена команда для обновления метаданных.

Если кластер, созданный с использованием версии оболочки ниже 8.0.19, полностью отключается и выполняется обновление оболочки, требуется перезагрузка кластера после полного сбоя и обновление схемы метаданных. Однако из-за этой ошибки это было невозможно, и пользователь столкнулся с проблемой «куриного яйца», поскольку команды блокировали бы выполнение друг друга.

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

dba.rebootClusterFromCompleteOutage()
.forceQuorumUsingPartitionOf()

Ошибка № 30501628 — REMOVEINSTANCE, SETPRIMARY ETC SHOULD WORK WITH ANY FORM OF ADDRESS

.removeInstance() выполнил некоторые проверки, чтобы убедиться, что удаляемый экземпляр действительно является частью метаданных кластера. Но в некоторых конкретных случаях этого было недостаточно, что приводило к сбоям.

По этой причине .removeInstance() был улучшен, чтобы разрешить удаление экземпляра из кластера, в котором report_host не совпадает с тем, что зарегистрировано в метаданных, но адрес (IP), указанный в команде, соответствует.

Ошибка # 30625424 — REMOVEINSTANCE() FORCE:TRUE SAYS INSTANCE REMOVED, BUT NOT REALLY

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

Ошибка № 29922719 и Ошибка № 30878446 — REPLICATION COORDINATES LEFT BEHIND AFTER REMOVEINSTANCE

После успешного удаления экземпляра из кластера каналы репликации, которые использовались групповой репликацией, все еще существовали, что позволяло передавать информацию о координатах репликации и т. д. Это было исправлено в этом выпуске путем обеспечения сброса следующих каналов после Cluster.removeInstance() или Cluster.dissolve():

group_replication_applier
group_replication_recovery

Ошибки связанные с InnoDB ReplicaSet

И, наконец, в InnoDB ReplicaSet также исправлена важная ошибка:

Ошибка # 30735124 — INNODB REPLICASET: ADMINAPI TAKES WRONG MEMBER AS HAVING LATEST VIEW/PRIMARY

В очень конкретной ситуации может случиться, что AdminAPI выберет недействительный элемент в качестве последнего первичного набора ReplicaSet, что приведет к ошибкам в последующих операциях. Основной причиной этой проблемы был процесс получения основного объекта InnoDB ReplicaSet, который неправильно переподключался к недействительному элементу, если это был последний экземпляр InnoDB ReplicaSet. Это было исправлено, и AdminAPI всегда гарантирует, что выбран правильный первичный.

0 0 голоса

Рейтинг статьи

Подписаться

авторизуйтесь

Уведомить о

новых последующих комментарияхновых ответах на мои комментарии

Label

{} [+]

Имя*

Email*

Веб-сайт

**ссылки nofollow

Δ

Label

{} [+]

Имя*

Email*

Веб-сайт

**ссылки nofollow

Δ

0 комментариев

Межтекстовые Отзывы

Посмотреть все комментарии