Обновление версии MySQL®
Вы можете обновить кластер Managed Service for MySQL® до любой поддерживаемой версии: минорной или мажорной.
В однохостовых кластерах на обновление выводится единственный хост-мастер. Во время обновления такие кластеры недоступны для чтения и записи, в отличие от кластеров из двух и более хостов. После возобновления работы СУБД потребуется время на «прогрев» буферного пула, что может временно повлиять на производительность запросов — это особенно заметно на больших базах данных с активным использованием индексов.
В многохостовых кластерах обновление проводится в следующем порядке:
-
Хосты-реплики последовательно выводятся на обновление и отключаются. Порядок реплик в очереди определяется случайным образом. После обновления реплики возвращаются в работу. На этом этапе возможно временное снижение производительности операций чтения, так как часть реплик будет недоступна.
-
Мастер закрывается на запись. Среди реплик выбирается новый мастер, который открывается для записи. В результате кластер обновляется с минимальным временем простоя.
-
Исходный мастер отключается, обновляется и возвращается в роли реплики. Обратно мастер не переключается, чтобы минимизировать риски дополнительных переключений.
Примечание
В MySQL® версии 8.0 переключение реплик происходит более надежно и эффективно благодаря улучшенной обработке метаданных.
Об обновлениях в рамках одной версии и обслуживании хостов см. в разделе Техническое обслуживание.
Внимание
-
После обновления СУБД вернуть кластер к предыдущей версии невозможно.
-
Обновляйте кластер в период низкой нагрузки на него — это снизит риски и уменьшит влияние на пользователей.
-
Успешность обновления версии MySQL® зависит от многих факторов, например:
- Настройки кластера и специфические конфигурации.
- Особенности хранимых данных и их структуры.
- Используемые возможности MySQL® (особенно JSON-функциональность и полнотекстовый поиск).
- Совместимость приложений с новой версией.
- Корректность хранимых процедур и триггеров.
- Состояние текущей базы данных и качество данных.
Рекомендуется сначала обновить тестовый кластер, который использует те же данные и настройки.
Перед обновлением версии
При подготовке к обновлению особенно важен комплексный подход к тестированию и анализу совместимости. Наш опыт показывает, что большинство проблем при обновлении можно предотвратить на этапе подготовки:
-
Посмотрите в истории изменений
MySQL®, как обновления могут повлиять на работу ваших приложений.Примеры изменений в MySQL® 8.0
-
Изменения в поведении SQL-функций и оптимизатора запросов:
-- Пример запроса для анализа плана выполнения EXPLAIN ANALYZE SELECT * FROM <имя_таблицы> WHERE complex_condition ORDER BY <поле>;
-
Устаревшие и удаленные возможности, особенно в области безопасности:
-- Проверка механизмов аутентификации SELECT user, host, plugin FROM mysql.user WHERE user NOT LIKE 'mysql.%';
-
Изменения в работе полнотекстового поиска и обработке JSON:
-- Проверка использования JSON-функций SELECT COUNT(*) FROM information_schema.routines WHERE routine_definition LIKE '%JSON%';
-
Новые значения по умолчанию для настроек СУБД.
-
Особенности работы с метаданными и временными таблицами.
-
-
Попробуйте обновить версию на тестовом кластере.
-
Разверните тестовый кластер из резервной копии основного кластера, используя окружение
PRESTABLE
, и обновите его до нужной версии. -
Проверьте работу критичных запросов и хранимых процедур.
-
Проверьте функционал, использующий JSON и полнотекстовый поиск.
-
Проведите нагрузочное тестирование:
-- Мониторинг производительности во время тестов SELECT EVENT_NAME, COUNT_STAR, AVG_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest WHERE SCHEMA_NAME = '<имя_базы_данных>' ORDER BY AVG_TIMER_WAIT DESC LIMIT 10;
-
-
Создайте резервную копию основного кластера непосредственно перед обновлением.
-
Обеспечьте отказоустойчивость кластера:
- Убедитесь, что в основном и тестовом кластере есть хотя бы два хоста-реплики и один хост-мастер. При необходимости добавьте хосты.
- (Опционально) Проверьте состояние репликации и задержки:
-- Проверка статуса репликации SHOW SLAVE STATUS\G -- Проверка задержек репликации SELECT SUBSTRING_INDEX(HOST, ':', 1) AS slave_host, SUBSTRING_INDEX(HOST, ':', -1) AS slave_port, SECONDS_BEHIND_MASTER, SLAVE_IO_RUNNING, SLAVE_SQL_RUNNING FROM information_schema.PROCESSLIST WHERE COMMAND = 'Binlog Dump';
Обновить версию MySQL®
- Перейдите на страницу каталога и выберите сервис Managed Service for MySQL.
- Выберите нужный кластер в списке и нажмите кнопку
Редактировать. - В поле Версия выберите номер новой версии.
- Нажмите кнопку Сохранить изменения.
После запуска обновления кластер переходит в статус Updating. Дождитесь окончания операции и проверьте версию кластера.
Время обновления зависит от многих факторов, например от объема данных или количества баз данных в кластере. Обновление обычно занимает несколько минут, для больших БД — от 10 минут.
Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.
По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>
. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name
или --folder-id
.
Чтобы обновить версию MySQL®:
-
Получите список ваших кластеров MySQL® командой:
yc managed-mysql cluster list
-
Получите информацию о нужном кластере и проверьте версию MySQL®, указанную в свойстве
config.version
:yc managed-mysql cluster get <имя_или_идентификатор_кластера>
-
Запустите обновление MySQL®:
yc managed-mysql cluster update <имя_или_идентификатор_кластера> \ --mysql-version <номер_новой_версии>
Время обновления зависит от многих факторов, например от объема данных или количества баз данных в кластере. Обновление обычно занимает несколько минут, для больших БД — от 10 минут.
-
Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.
О том, как создать такой файл, см. в разделе Создание кластера.
-
Добавьте поле
version
в ресурсyandex_mdb_mysql_cluster
или измените значение поля, если оно уже существует:resource "yandex_mdb_mysql_cluster" "<имя_кластера>" { ... version = "<версия_MySQL®>" ... }
-
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Подробнее см. в документации провайдера Terraform
Ограничения по времени
Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for MySQL®:
- создание кластера, в том числе путем восстановления из резервной копии, — 15 минут;
- изменение кластера, в том числе обновление версии MySQL®, — 60 минут;
- удаление кластера — 15 минут.
Операции, длящиеся дольше указанного времени, прерываются.
Как изменить эти ограничения?
Добавьте к описанию кластера блок timeouts
, например:
resource "yandex_mdb_mysql_cluster" "<имя_кластера>" {
...
timeouts {
create = "1h30m" # Полтора часа
update = "2h" # 2 часа
delete = "30m" # 30 минут
}
}
-
Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:
export IAM_TOKEN="<IAM-токен>"
-
Воспользуйтесь методом Cluster.update и выполните запрос, например, с помощью cURL
:Важно
Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре
updateMask
(одной строкой через запятую).curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mysql/v1/clusters/<идентификатор_кластера>' \ --data '{ "updateMask": "configSpec.version", "configSpec": { "version": "<версия_MySQL®>" } }'
Где:
-
updateMask
— перечень изменяемых параметров в одну строку через запятую.В данном случае передается только один параметр.
-
configSpec.version
— новая версия MySQL®.
Идентификатор кластера можно запросить со списком кластеров в каталоге.
-
-
Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.
-
Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:
export IAM_TOKEN="<IAM-токен>"
-
Клонируйте репозиторий cloudapi
:cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
Далее предполагается, что содержимое репозитория находится в директории
~/cloudapi/
. -
Воспользуйтесь вызовом ClusterService/Update и выполните запрос, например, с помощью gRPCurl
:Важно
Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре
update_mask
(в виде массива строкpaths[]
).Формат перечисления настроек
"update_mask": { "paths": [ "<настройка_1>", "<настройка_2>", ... "<настройка_N>" ] }
grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mysql/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "<идентификатор_кластера>", "update_mask": { "paths": [ "config_spec.version" ] }, "config_spec": { "version": "<версия_MySQL®>" } }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mysql.v1.ClusterService.Update
Где:
-
update_mask
— перечень изменяемых параметров в виде массива строкpaths[]
.В данном случае передается только один параметр.
-
config_spec.version
— новая версия MySQL®.
Идентификатор кластера можно запросить со списком кластеров в каталоге.
-
-
Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.
Время обновления зависит от многих факторов, например от объема данных или количества баз данных в кластере. Обновление обычно занимает несколько минут, для больших БД — от 10 минут.
Примеры
Рассмотрим практический пример обновления кластера с версии 5.7 до 8.0. Этот сценарий особенно интересен, так как включает наиболее существенные изменения в архитектуре MySQL®.
-
Получите список кластеров и узнайте их идентификаторы и имена:
yc managed-mysql cluster list
Пример результата:
+----------------------+------------+---------------------+--------+---------+ | ID | NAME | CREATED AT | HEALTH | STATUS | +----------------------+------------+---------------------+--------+---------+ | c9q8p8j2gaih******** | mysql406 | 2021-10-23 12:44:17 | ALIVE | RUNNING | +----------------------+------------+---------------------+--------+---------+
-
Получите детальную информацию о конкретном кластере:
yc managed-mysql cluster get mysql406
В выводе будет указана текущая версия MySQL®:
id: c9q8p8j2gaih******** ... config: version: "5.7" ...
-
Запустите процесс обновления до версии 8.0:
yc managed-mysql cluster update mysql406 --mysql-version 8.0
После выполнения этой команды начнется процесс обновления, который может занять от нескольких минут до часа, в зависимости от размера базы данных и конфигурации кластера.
-
Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.
-
В поле
version
в ресурсеyandex_mdb_mysql_cluster
укажите значение8.0
:resource "yandex_mdb_mysql_cluster" "<имя_кластера>" { ... version = "8.0" ... }
-
Проверьте корректность настроек:
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Примените изменения:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Terraform автоматически определит необходимость обновления версии и запустит процесс.
После успешного обновления:
-
Проверьте статус всех критичных компонентов:
-- Проверка статуса InnoDB SHOW ENGINE INNODB STATUS\G -- Проверка состояния репликации SHOW SLAVE STATUS\G
-
Убедитесь в корректности работы приложений:
- Проверьте время выполнения критичных запросов.
- Проконтролируйте статистику ошибок.
- Отследите использование ресурсов.
-
Проведите оптимизацию конфигурации под новую версию:
-- Анализ использования буферного пула SELECT POOL_ID, POOL_SIZE, FREE_BUFFERS, DATABASE_PAGES FROM information_schema.INNODB_BUFFER_POOL_STATS; -- Проверка настроек производительности SHOW VARIABLES LIKE '%buffer%';
См. также
- Технический обзор особенностей MySQL® 8.0, рассматривающий изменения в производительности и функциональности новой версии.