У меня есть небольшой экземпляр MySQL RDS как часть моей производственной системы, и я хочу обновить его до среднего экземпляра с предоставленным IOPS.

Как администратор базы данных старой школы, я знаю о методе «добавить ведомого; повысить до основного; переключить клиентов», но AWS обещает предоставить волшебный путь обновления в один клик, то есть «экземпляр обновления», «добавить предоставленные IOPS».

Попробовал это на тестовом экземпляре RDS, время простоя слишком велико, ИМХО: около 5 минут для малого и среднего обновления и 30 минут (!!!) для переключения на предоставленный IOPS.

• Это нормальное поведение?
• Есть ли способ запустить обновление RDS без простоя?
• Вы рекомендуете «остановить; создать моментальный снимок; восстановить из моментального снимка в более крупный экземпляр»?

Обновление экземпляра в RDS означает, что RDS будет физически переносить базу данных в новый экземпляр, вероятно, на другой физический хост, поэтому простоев не избежать. Миграция на подготовленные IOPS, скорее всего, будет означать, что ваши данные будут перенесены на новый том EBS (и сервер может быть также перенесен на новый экземпляр с этим изменением, в зависимости от того, являются ли внутренне машины, способные обращаться к томам EBS с подготовленными IOPS, физически отделены от машин, которые не являются таковыми, чтобы они могли быть на другом классе сетевого оборудования), поэтому простои снова были бы неизбежны.

Как представляется, существует способ избежать этого нарушения: развертывание Multi-AZ, которое создает невидимую и недоступную (для вас) реплику в другой зоне доступности в регионе.

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

^{- http://aws.amazon.com/rds/multi-az/}

Это должно обеспечить быстрый и плавный путь миграции, хотя у меня не было возможности протестировать эту возможность. «Изменить» в консоли появляется, чтобы позволить вам преобразовать экземпляр в Multi-AZ. Предположительно, это приведет к кратковременному зависанию ввода-вывода при клонировании экземпляра, поэтому я, конечно, рекомендую протестировать всю эту функциональность, прежде чем пытаться ее выполнить.

С другой стороны, RDS поддерживает внутренний механизм, который должен позволять вам эмулировать операцию «добавить ведомого; повысить до главного; переключить клиентов», что также должно позволить вам достичь почти нулевого времени простоя преобразования:

• Создайте реальную копию чтения RDS вашей базы данных с нужным классом экземпляра.
• Подождите, пока реплика подключится к Интернету и будет синхронизирована с мастером
• Измените конфигурацию реплики, чтобы добавить Provisioned IOPS
• Подождите, пока реплика подключится к Интернету и будет синхронизирована с мастером
• Убедитесь, что обе системы имеют идентичные данные, используя сторонние инструменты
• Отключите ваше приложение от старого мастера
• Проверьте совпадающие координаты binlog на главной и реплике, чтобы убедиться, что все записи приложения реплицированы
• Разделите системы с помощью «Promote Read Replica» на новую реплику в RDS.
• Подключите ваше приложение к новому мастеру

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/

Даже в среде с несколькими AZ у вас будет перерыв в 60-120 секунд. Это был тот случай, когда я неоднократно обращался к нашим экземплярам RDS при выполнении обновления с PostgreSQL db.m3.medium до db.m3.large.

Также возможно избежать простоев во время обновления. Это можно сделать, кратко запустив новую RDS из моментального снимка реплики чтения и сконфигурировав ее как активную / активную репликацию Master на Master. После настройки вы можете переключать трафик приложений на один сервер APP одновременно без простоев. Мы используем этот подход каждый раз, когда AWS объявляет о техобслуживании RDS, чтобы избежать простоев, а также во время наших плановых техобслуживаний.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Вот подробности:

М1 - Оригинальный Мастер

R1 - Считать Реплику М1

SNAP1 - Снимок R1

М2 - Новый Мастер

Последовательность создания M2: M1 → R1 → SNAP1 → M2

• Так как мы не можем использовать привилегию SUPER на RDS, мы не используем mysqldump с — master_data2опцией на M1. Вместо этого мы запускаем R1, чтобы получить из него позицию binlog M1 . Затем создайте снимок (SNAP1) из R1 и затем запустите M2 из SNAP1.

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

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Создать пользователя репликации на M1

  GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Создайте R1 из M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Создайте SNAP1 из R1

• Создать M2 из SNAP1 с атрибутами, полученными из M1

• Назначьте группу параметров для M2 с другим смещением auto_increment_ от M1, чтобы избежать конфликтов ключей репликации M / M

4. Настройка M / M репликации

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, ‘repl’, ‘mypassword’, ‘mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , ‘repl’, ‘mypassword’, ‘mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;

5. Удалите R1 и SNAP1, поскольку они больше не нужны

6. Обновите M2 через Консоль AWS

Используйте стандартную процедуру для изменения экземпляра в соответствии с вашими потребностями.

7. Выполните постепенное переключение на M2

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

Вот больше деталей о том, как это работает.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Это будет работать, однако вы должны убедиться, что конечные точки экземпляра RDS не настроены в вашем приложении как статическая запись. Замена RDS изменит конечные точки.