ИТ Блог. Работа с базой данных (MySQL, CouchDB, MariaDB, MongoDB)
(1 оценок, среднее: 5,00 из 5)
Загрузка...
Команда разработчиков MySQL с радостью объявляет о выпуске новой версии 8.0 для поддержки MySQL Shell AdminAPI – 8.0.20!
После предыдущего захватывающего выпуска, в котором был представлен InnoDB ReplicaSet, в следующем сосредоточились на улучшении управления ReplicaSets, а также, что наиболее важно, кластера InnoDB.
Здесь вы ознакомитесь и увидите как обновить MySQL Shell до новой версии!
Этот выпуск сфокусирован на улучшениях управления для AdminAPI, а именно:
И как всегда, качество было значительно улучшено с исправлением многих ошибок!
Развертывание кластера InnoDB или ReplicaSet включает настройку учетных записей администратора. Это необходимо для:
Даже если администратор базы данных может свободно использовать учетную запись 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});
...
Для работы InnoDB ReplicaSet требуется объект. Таким образом, аналогично в InnoDB Cluster, AdminAPI предоставляет команду dba.getReplicaSet(), которая возвращает дескриптор ReplicaSet. Однако для кластера InnoDB можно запустить MySQL Shell с уже созданным и заполненным объектом кластера, используя параметр командной строки:
--cluster
Эта функция была теперь перенесена на InnoDB ReplicaSet! Теперь можно запустить MySQL Shell и использовать следующий параметр командной строки, чтобы получить заполненный объект ReplicaSet:
--replicaSet
Пример:
$ mysqlsh --replicaset clusterAdmin@instance1:3306
В рамках этого порта также расширили следующие команды для поддержки ReplicaSet:
Это еще один шаг вперед по удобству использования!
AdminAPI, как панель управления InnoDB ReplicaSets, предоставляет наиболее приятное и простое в использовании решение для пользователей. Тем не менее, он также несет ответственность за обеспечение безопасной среды для таких задач управления.
Даже при том, что не должно быть очень распространенным, что несколько экземпляров Shell одновременно работают на одном и том же ReplicaSet, это было возможно и разрешено. Такие ситуации могут привести к несоответствиям как в метаданных, так и в механизмах репликации, что приведет к неожиданным или нарушенным настройкам. По этой причине улучшили операции ReplicaSet, чтобы гарантировать, что, когда это применимо, операции являются взаимоисключающими.
Давайте проиллюстрируем катастрофический сценарий: администраторы БД AndreyEx и Destroyer работают над одним и тем же ReplicaSet и практически одновременно:
AndreyEx:
mysql-js> // Primary switchover
mysql-js> replicaset.setPrimaryInstance("instance2");
Запуск следующих действий:
Destroyer :
mysql-js> // Добавьте новый экземпляр в набор ReplicaSet
mysql-js> replicaset.addInstance("instance4");
Причина сбоя из-за одного из следующих факторов:
И в конечном итоге приводит к неожиданному/неизвестному результату.
В этом выпуске это больше не проблема, поскольку операции ReplicaSet стали взаимоисключающими!
Внедрили механизм блокировки для операций ReplicaSet, который гарантирует, что никакие операции, которые изменяют топологию метаданных и/или ReplicaSet, не могут быть выполнены одновременно. Блокировки могут быть глобальными или на уровне экземпляра.
Подробно:
Полный список ошибок, исправленных в этом выпуске, можно найти в журнале изменений. Однако есть некоторые, которые заслуживают упоминания.
Благодаря интеграции подключаемого модуля MySQL Clone в InnoDB Cluster и ReplicaSet, подготовка стала такой же простой, как пирог. На сегодняшний день это одна из наиболее важных встроенных технологий, доступных через AdminAPI, обеспечивающая всегда доступную инициализацию с невероятно быстрой скоростью.
Было обнаружено несколько ошибок, которым было уделено особое внимание в этом выпуске.
Использование клона в качестве метода обеспечения для добавления экземпляра в ReplicaSet привело к падению, если целевой экземпляр не поддерживал RESTART. Эта ошибка была исправлена в этом выпуске, и поведение ReplicaSet.addInstance() было расширено, чтобы учитывать такой сценарий, и всякий раз, когда истекает время ожидания операции, команда отменяет и отменяет изменения.
Когда выполняется клонирование для предоставления экземпляра, для завершения процесса требуется перезапуск. Во время этого перезапуска резервирование транзакций применяется к экземпляру, и в зависимости от размера этого отставания процесс может занять больше или меньше времени. Для серверов, которые применяют очень большой резерв транзакций, тайм-аут по умолчанию в 60 секунд может быть недостаточным.
По этой причине был добавлен новый глобальный параметр dba.restartWaitTimeout в Shell, позволяющий пользователям устанавливать правильное значение для времени перезапуска.
mysql-js> // Проверьте текущие параметры на месте
mysql-js> shell.options
mysql-js> // Измените значение dba.restartWaitTimeout
mysql-js> shell.options.set("dba.restartWaitTimeout", 300);
Один из возможных вариантов использования для клонирования – разрешить добавление экземпляра с дивергентным GTID-набором в кластер. Тем не менее, плагин MySQL Clone имеет ограничение в отношении использования IPv6. В частности, если все члены кластера используют IPv6, доноры использовать нельзя, поскольку Clone не поддерживает использование адресов IPv6 для действительного списка доноров. Таким образом, в сценарии, в котором все участники используют IPv6 и был выбран клон, клон завершится ошибкой и откатится к постепенному восстановлению.
В конечном счете, экземпляр будет добавлен в кластер с использованием инкрементного восстановления, но из-за различий набора GTID экземпляр не будет принят в кластере.
Это было улучшено за счет реализации новой проверки, запрещающей использование клона в качестве метода восстановления, когда все члены кластера используют адреса IPv6.
InnoDB Cluster, как основное решение MySQL HA, привлекло внимание несколькими исправлениями ошибок:
В некоторых конкретных ситуациях, в которых .forceQuorumUsingPartitionOf() использовалась разблокировка кластера, потерявшего свой кворум, происходило неопределенное и неожиданное поведение, вызывающее несоответствия в кластере. Эти ситуации были видны только тогда, когда autoRejoinTries имело значение выше нуля.
Это было вызвано ошибкой в AdminAPI, из-за которой не удалось остановить групповую репликацию для всех достижимых экземпляров, которые не были частью видимого членства целевого экземпляра. Это было исправлено путем обеспечения остановки репликации группы в этих случаях.
В предыдущем выпуске 8.0.19 были представлены InnoDB ReplicaSet и новая версия схемы метаданных. Чтобы разрешить непрерывное обновление, была также добавлена команда для обновления метаданных.
Если кластер, созданный с использованием версии оболочки ниже 8.0.19, полностью отключается и выполняется обновление оболочки, требуется перезагрузка кластера после полного сбоя и обновление схемы метаданных. Однако из-за этой ошибки это было невозможно, и пользователь столкнулся с проблемой «куриного яйца», поскольку команды блокировали бы выполнение друг друга.
Это исправлено в этом выпуске путем изменения предварительных условий следующих команд, чтобы разрешить их работу, даже если схема метаданных требует обновления:
dba.rebootClusterFromCompleteOutage() .forceQuorumUsingPartitionOf()
.removeInstance() выполнил некоторые проверки, чтобы убедиться, что удаляемый экземпляр действительно является частью метаданных кластера. Но в некоторых конкретных случаях этого было недостаточно, что приводило к сбоям.
По этой причине .removeInstance() был улучшен, чтобы разрешить удаление экземпляра из кластера, в котором report_host не совпадает с тем, что зарегистрировано в метаданных, но адрес (IP), указанный в команде, соответствует.
Как и в предыдущей ошибке, было невозможно удалить OFFLINE, но достижимый экземпляр из кластера, когда использовался адрес, отличный от адреса, зарегистрированного в метаданных. Это было исправлено в этом выпуске, позволяя удалять такие экземпляры с помощью forceпараметра.
После успешного удаления экземпляра из кластера каналы репликации, которые использовались групповой репликацией, все еще существовали, что позволяло передавать информацию о координатах репликации и т. д. Это было исправлено в этом выпуске путем обеспечения сброса следующих каналов после Cluster.removeInstance() или Cluster.dissolve():
group_replication_applier group_replication_recovery
И, наконец, в InnoDB ReplicaSet также исправлена важная ошибка:
В очень конкретной ситуации может случиться, что AdminAPI выберет недействительный элемент в качестве последнего первичного набора ReplicaSet, что приведет к ошибкам в последующих операциях. Основной причиной этой проблемы был процесс получения основного объекта InnoDB ReplicaSet, который неправильно переподключался к недействительному элементу, если это был последний экземпляр InnoDB ReplicaSet. Это было исправлено, и AdminAPI всегда гарантирует, что выбран правильный первичный.
