Назад | Перейти на главную страницу

Время простоя для увеличения хранилища 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
  • Конфигурация
    • Произойдет ли это во время обслуживания?
    • Произойдут ли эти изменения сначала на вашем ведомом устройстве с несколькими зонами доступности, а затем произойдет переключение при отказе?
  • Текущий размер базы данных
  • Размер базы данных кандидатов
  • Возможности 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 db.m3.medium объемом 15 ГБ на 20 ГБ в eu-west-1 в течение рабочего дня подключение моего приложения к базе данных было непрерывным. Тем не менее, IOPS чтения / записи увеличились до 400-700 / с в течение чуть менее 20 минут, отсюда, как я полагаю, есть ссылки на снижение производительности. Об этом сообщалось для экземпляров баз данных как с одной, так и с несколькими зонами доступности. (Сообщалось, что экземпляр «модифицируется» немного дольше - около 25 минут.)

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