Изменить размер хранилища Amazon RDS

Question

В настоящее время мы работаем с базой данных объемом 200 ГБ, и у нас недостаточно места, поэтому мы хотели бы увеличить выделенное хранилище.

Мы используем универсальную (SSD) и базу данных MySQL 5.5.53 (без развертывания Multi-AZ).

Если я захожу в меню Amazon RDS и изменяю выделенное хранилище на немного большее (от 200 до 500), я получаю следующие « предупреждения »:

• Истощение начальных кредитов ввода-вывода общего назначения (SSD), что приводит к увеличению времени преобразования: Что это значит?
• Влияние на производительность экземпляра до завершения операции : И это самый важный вопрос для меня. Могу ли я изменить размер экземпляра с нулевым временем простоя? Я имею в виду, мне все равно, если запросы будут немного медленнее, если они будут работать во время изменения размера, но я не хочу останавливать все мои рабочие веб-сайты, изменять размер экземпляра и открывать их снова ( ака есть простои).

Заранее спасибо.

Answer 1

Сначала в соответствии с Часто задаваемыми вопросами RDS , простоев не должно быть вообще, если вы только увеличиваете объем хранилища, но не обновляете уровень экземпляра.

В: Будет ли мой экземпляр БД оставаться доступным во время масштабирования?

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

Второй, согласно Документация RDS :

Базовая производительность ввода-вывода для хранилища SSD общего назначения составляет 3 IOPS для каждый GiB, что означает, что большие объемы имеют лучшую производительность .... Объемы ниже 1 ТиБ также имеют способность к взрыву до 3000 IOPS для длительных периодов времени (всплеск не относится к объемам выше 1 ТиБ). Кредитный баланс ввода / вывода экземпляра определяет производительность пакета.

Не могу с уверенностью сказать, почему, но, думаю, когда RDS увеличивает размер диска, он может дефрагментировать данные или переставлять блоки данных, что приводит к интенсивному вводу / выводу. Если ваш сервер интенсивно используется во время изменения размера, он может полностью использовать кредиты ввода-вывода и привести к меньшему количеству операций ввода-вывода и увеличению времени преобразования. Однако, учитывая, что вы начали с 200 ГБ, я полагаю, что все должно быть в порядке.

Наконец, я бы предложил вам использовать multi-az deployemnt, если вы так обеспокоены простоями или влиянием на производительность. Во время обслуживания окон или снимков будет краткая приостановка ввода-вывода в течение нескольких секунд, чего можно избежать с помощью резервных копий или реплик чтения.

Answer 2

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

Чтобы ответить на ваши вопросы: Экземпляры RDS могут порваться с чем-то, называемым кредитами ввода / вывода. Взрыв означает, что его производительность может превысить базовую производительность, чтобы удовлетворить всплески спроса. Это не должно иметь большого значения, если вы прожигаете их, если ваш экземпляр не полагается на них (вы можете определить это по метрикам экземпляра rds). Прочитайте Кредиты ввода / вывода и Burst Performance .

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

Answer 3

Технический ответ: AWS не поддерживает время простоя при масштабировании хранилища.

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

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