Восстановление снимка RDS занимает слишком много времени

В рамках нашей сине-зеленой стратегии развертывания мы делаем снимок экземпляра prod RDS, а затем восстанавливаем этот снимок в новый экземпляр, применяя миграции баз данных после него и связывая с ним новое зеленое приложение.

Наш экземпляр RDS имеет 100 ГБ места, но наша БД на данный момент использует только 10 МБ.

Создание снимка занимает примерно ‹2 минуты

Восстановление из снимка занимает 25 минут!

25 минут для восстановления - это слишком долго, учитывая, что пользователи вынуждены оставаться в режиме только для чтения все это время, а размер нашей БД на данный момент составляет менее 10 МБ.

Мне интересно, является ли это время восстановления обычным временем для Amazon RDS или мы делаем что-то не так.

  • Amazon RDS Postgres.
  • Multi AZ: Да
  • Класс экземпляра: средний
  • Общего назначения (SSD)
  • IOPS: отключено.

postgresql amazon-web-services database-restore rds blue-green-deployment
person user1990009    schedule 18.02.2016    source источник
comment
Какой класс экземпляра вы используете? SSD-накопитель? Это Multi-AZ?   -  person Matt Houser    schedule 18.02.2016
comment
Это не будет особенно хорошо или масштабируемо, если вы ожидаете, что ваша база данных будет расти. Рассматривали ли вы какие-либо альтернативные решения, такие как продвижение реплик чтения в мастер или сервис миграции баз данных AWS?   -  person Anthony Neace    schedule 19.02.2016
comment
@MattHouser: Я обновил пост, добавив ответы на ваши вопросы   -  person user1990009    schedule 19.02.2016

Ответы (1)


arrow_upward
7
arrow_downward

После некоторых экспериментов нам удалось сократить время восстановления с 25 до 5 минут. Это было связано с тем, что RDS сначала пытается восстановить снимок. (В нашем случае это заняло 5 минут). А затем применил изменение Multi Az к новому экземпляру. (это заняло около 20 минут)

Раньше мы ждали, пока БД завершит изменение MULTI AZ, а status = "available" продолжит развертывание, но после обращения в AWS они подтвердили, что можно безопасно начать использовать новый экземпляр, даже когда экземпляр модифицируется. , чтобы применить изменение MULTI AZ. Поэтому мы продолжаем процесс развертывания, как только статус восстановленного экземпляра изменится с «создание» на «изменение».

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

Мы считаем этот подход очень безопасным, поскольку любые изменения схемы БД не повлияют на живую БД, и мы можем безопасно протестировать весь ЗЕЛЕНЫЙ стек перед переключением на PROD. Единственное предостережение здесь в том, что приложение должно быть в режиме только для чтения, чтобы не терять информацию между синей и зеленой средами.

person user1990009    schedule 24.02.2016