Можно ли обновлять инстансы Amazon RDS?

Question

Смогу ли я переключаться (я имею в виду обновление или понижение) экземпляра Amazon RDS по мере необходимости или мне нужно заново создать новый и пройти миграцию?

Answer 1

Да , экземпляры Amazon RDS можно обновить с помощью команды modify-db-instance. Нет необходимости в переносе данных.

Из документации Amazon RDS :

"Если вы не уверены, сколько процессорного времени вам нужно, мы рекомендуем начать с класса экземпляра БД db.m1.small и отслеживать загрузку процессора с помощью сервиса Amazon CloudWatch. Если ваш экземпляр БД привязан к процессору, вы можете легко перейти на больший класс инстанса БД с помощью команды rds-modify-db-instance.

Amazon RDS выполнит обновление во время следующего окна обслуживания. Если вы хотите, чтобы обновление выполнялось сейчас, а не в ожидании окна обслуживания, укажите параметр --apply-немедленно. Предупреждение: изменение класса инстанса БД требует кратковременного отключения вашего инстанса БД. "

Answer 2

RE: время простоя : у нас есть экземпляр RDS SQL Server 2012 (1 ТБ, не IOPS-диск), и он идет от дБ.м1.xlarge до дБ. m3.xlarge (больше ЦП, меньше $$) из-за простоя более 4 минут.

ПРИМЕЧАНИЕ. Мы выполнили обновление из графического интерфейса консоли AWS и выбрали «Применить немедленно», но прошло всего 10 минут, прежде чем фактически началось отключение. Состояние RDS показывало «Изменение» сразу после того, как мы инициировали обновление, и оно оставалось таким же в течение времени ожидания и времени простоя.

Надеюсь, это поможет!

Грег

Answer 3

Я только что выполнил обновление со среднего экземпляра RDS до большого, когда мы столкнулись с неожиданным трафиком (хорошо, правда? :)). Так как у нас есть инстанс с несколькими азимутами, мы падали на 2-3 минуты. В документации Amazon говорится, что время простоя будет коротким, если у вас есть экземпляр с несколькими AZ.

Answer 4

Для всех, кто заинтересовался, мы просто изменили экземпляр RDS (MySQL, 15 ГБ HD, остальные стандартные параметры), изменив его с микро на маленький. Время простоя составило 5 минут.

Answer 5

RE: Время простоя: мы только что обновили postgresql 9.3, немедленно запросив следующие изменения:

• обновив postgresql 9.3.3 до 9.3.6
• изменение размера экземпляра с m3.large до m3.2xlarge
• изменение типа хранилища на выделенный IOPS
• расширение хранилища с 200G до 500G (самая дорогая операцияс точки зрения времени)

Нам потребовалось почти 5 часов, чтобы завершить всю эту операцию.База данных содержит около 100G данных на момент обновления.Вы можете следить за ходом обновления в разделе События в консоли RDS.Во время обновления RDS делает пару резервных снимков, ход выполнения которых можно отслеживать в разделе Snapsnots .

Answer 6

Мы только что выполнили обновление с db.m3.large до db.m3.xlarge с 200 ГБ данных не-IOPS под управлением SQL Server 2012. Время простоя составило примерно 5 минут.

Answer 7

Обновление MySQL RDS с db.t2.small до db.t2.medium для 25G данных заняло 6 минут.

Answer 8

Да, они могут быть обновлены. Обновленный экземпляр RDS с SQL Server 2008 до SQL Server 2012 с размером экземпляра около 36 ГБ, классом db-m1-small, хранилищем 200 ГБ и без операций ввода-вывода в секунду или Multi AZ. Простоев не было, этот процесс занял всего 10 минут.

Answer 9

У нас был оператор Alter для большой таблицы (около 53 миллионов записей), и он не смог завершить операцию.

Существующее использование размера было 48 ГБ. Мы решили увеличить выделенное хранилище в AWS - RDS Instance Вся операция заняла 2 часа MYSQL db.r3.8xlarge от 100 г до 200 г

Оператор Alter занял около 40 минут, но сработал.

Answer 10

На мульти-аз произойдет аварийное переключение, но в противном случае оно будет плавным. Вот данные временной шкалы от моего последнего понижения типа экземпляра db с r3.4xlarge до r3.2xlarge на Postgres, настроенном для Multi-Az 9.3, с 3 ТБ диска (фактические данные - всего ~ 800 ГБ)

time (utc-8) event Mar 11 10:28 AM Finished applying modification to DB instance class Mar 11 10:09 AM Multi-AZ instance failover completed Mar 11 10:08 AM DB instance restarted Mar 11 10:08 AM Multi-AZ instance failover started