Время простоя для увеличения хранилища AWS RDS?

Я надеюсь увеличить объем хранилища для двух экземпляров RDS (только выделенное пространство для хранения, а не тип экземпляра или другие параметры). Документация по адресу https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting предлагает:

Вы можете перейти от стандартного хранилища к выделенному хранилищу IOPS или от обеспеченного хранилища IOPS к стандартному хранилищу, а также увеличить объем хранилища практически без простоев.

Я определенно запланировал бы период обслуживания перед выполнением изменения. Но документация кажется немного расплывчатой ​​в этой области. Для кого-то, кто мог бы сделать это раньше, что такое «время простоя практически нет»? Можно ли ожидать 5 секунд или это больше похоже на 5 минут?

Обновление июль 2019 года:

Я обновил ссылку на правильную и обновленную документацию AWS (которая была повреждена). В новой документации есть реклама, которая также помогает ответить на исходный вопрос:

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

Тем не менее, особый случай, если у вас есть экземпляр БД SQL Server и вы не изменили конфигурацию хранилища с ноября 2017 года. В этом случае вы можете испытать кратковременное отключение в течение нескольких минут при изменении экземпляра БД для увеличения выделенного место хранения. После сбоя экземпляр БД подключен, но находится в состоянии оптимизации хранения. Производительность может быть снижена во время оптимизации хранилища.

Во-первых, обратите внимание, что вы, возможно, просматриваете неправильную операцию - вы описываете, что хотите изменить размер хранилища , но цитировали документацию, описывающую тип хранилища . Это важный момент: RDS рекомендует не прерывать работу при изменении размера хранилища, но что при смене типа хранения у вас возникнет сбой.

Ожидайте снижения производительности при изменении размера хранилища, продолжительность и влияние которого будут зависеть от нескольких факторов:

• Ваш тип экземпляра RDS
• конфигурация
  • Это произойдет во время технического обслуживания?
  • Будут ли эти изменения происходить сначала на вашем ведомом устройстве Multi-AZ, а затем при отказе?
• Текущий размер базы данных
• Размер базы данных кандидатов
• Возможности AWS для обработки этого запроса в запрошенное вами время суток, в запрошенной зоне доступности, в запрошенном вами регионе
• Тип движка (для пользователей Amazon Aurora дополнения к хранилищам управляются RDS по мере необходимости с шагом 10 ГБ, поэтому это обсуждение является спорным)

Имея это в виду, вам будет лучше обслужить себя, протестировав это самостоятельно, в своей среде и на ваших условиях. Попробуйте поэкспериментировать со следующим:

• Восстановление нового экземпляра RDS из снимка существующего экземпляра и выполнение этой операции с новым клоном.
• С этим клоном:
  • Увеличьте размер в разное время дня, когда вы ожидаете другую нагрузку на AWS.
  • Увеличение до разных размеров.
  • Попробуйте это с мульти-AZ. Посмотрите, изменится ли ваше реальное время простоя по сравнению с не включением мульти-АЗ.
  • Попробуйте это в течение периода обслуживания и сравните с немедленным применением изменений.

Это будет стоить немного больше (это не обязательно ... вы могли бы сделать большую часть этого за 1-3 часа работы экземпляра), но вы получите гораздо более четкий ответ, чем торг за наш опыт в множестве различных RDS сред.

Если вы все еще ищете «приблизительный» ответ, я бы посоветовал спланировать, по крайней мере, снижение производительности в течение нескольких минут, а не секунд - опять же очень сильно зависит от вашей среды и конфигурации.

Для справки, я недавно применил эту точную операцию, чтобы добавить 10 ГБ к экземпляру типа db.m1.small размером 40 ГБ в субботу днем ​​(в EST). Экземпляр оставался в состоянии «модификации» в течение приблизительно 17 минут. Обратите внимание, что состояние изменения не описывает реальное время простоя, а скорее продолжительность применения операции . Вы не сможете применить дополнительные изменения к фактическому экземпляру (хотя вы все равно можете получить доступ к самой БД), и это также продолжительность, с которой вы можете ожидать снижения производительности.

Если вы планируете только изменить размер хранилища, сбой является неожиданным, но обратите внимание, что это может произойти, если это изменение будет выполнено в сочетании с другими операциями, такими как изменение идентификатора / класса экземпляра или типа хранилища.

Так как вы только увеличиваете размер хранилища и не меняете тип экземпляра или что-либо еще, не должно быть никаких простоев, но может быть «снижение производительности» во время выполнения операции.

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

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

вы увидите, что в нем говорится только «Производительность может быть снижена» и ничего о сбое (что, как говорится, происходит в некоторых случаях при переключении типа хранилища).

Для справки: при изменении базы данных MySQL на 15 ГБ db.m3.medium на eu-west-1 в течение рабочего дня на 20 ГБ подключение моего приложения к базе данных было бесперебойным. Тем не менее, количество операций ввода-вывода в режиме чтения / записи увеличилось до 400-700 в секунду в течение чуть менее 20 минут, поэтому я полагаю, что это относится к снижению производительности. Об этом сообщалось как для экземпляров базы данных с одним AZ, так и с несколькими AZ. (Экземпляр был назван «изменяющим» немного дольше, чем это - около 25 минут.)

Естественно, вы можете опробовать его на экземпляре db, идентичном производственному db, прежде чем делать это на своем экземпляре db, чтобы вы могли смело видеть, как он ведет себя в вашей ситуации, прежде чем делать это по-настоящему.