Измените тип хранилища MySQL RDS с магнитного на SSD / обеспеченный IOPS, используя Cloud Formation

Question

Измените тип хранилища MySQL RDS с магнитного на SSD / обеспеченный IOPS, используя Cloud Formation

0

У меня есть экземпляр RDS со следующими характеристиками:

InstanceClass: db.m5.12xlarge
AllocatedStorage: 500 - (GiB)
MultiAZ: No
ReadReplica: True - (with same specs)
StorageType: standard - (magnetic)

Мне нужно изменить мастер и реплику, чтобы использовать тип хранилища SSD (gp2) с большим пространством (2 ТиБ), и это должно быть сделано с помощью шаблонов CloudFormation, так как вышеупомянутые экземпляры RDS являются частью стека. НО проблема в том, что это производственные базы данных, и длительное отключение [более 2 часов] не вариант.

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

Hassan Mussana 05 фев. 2019, в 15:50

Источник

Теги:

mysql

architecture

amazon-cloudformation

devops

amazon-rds

1 ответ

Ещё вопросы

Biplob Biswas · Answer 1 · 2019-02-06T15-21-00.000Z

Исходя из вашего объяснения, я предполагаю, что у вас есть RDS-MySQL DB Cluster (если у вас нет RDS Cluster, как вы реплицируете данные в реплику чтения?), А не кластер Aurora-MySQL DB (в этом случае вы бы не Нет магнитного типа хранения и, следовательно, мое предположение)

В таком случае вручную создайте реплики чтения из пользовательского интерфейса.

RDS → Базы данных → Выберите кластер RDS → (вверху справа) Выберите Действия → Добавить Reader

После того, как вы выберите читателя, выберите нужный тип хранилища и реплику чтения для репликации.

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

Когда у вас есть 2 реплики с нужным типом хранилища, вы можете сделать 2 вещи:

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

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

Да, уже думал об этом ручном обходном пути, но изменение должно было быть вызвано через CF. Время простоя есть, но БД остается доступной во время изменения, хотя и медленно. Но все равно сделал это. Спасибо за Ваш ответ.
Кроме того, я подсчитал, что наименьшее время уходит на восстановление из снимка и создание совершенно новой БД. Расчетное время простоя в этом случае составляет ~ 4 при макс.
Если я не ошибаюсь, вы также можете создавать реплики чтения из облачной информации, просто добавьте дополнительные реплики чтения в свой шаблон формирования облака и укажите тип хранилища. Как только реплики появятся, удалите другие экземпляры из шаблона облачной информации. Я не пробовал это, но, возможно, удаление главного экземпляра напрямую из облачной информации может не сработать. Но рад, что это сработало, и да, снимки хороши, но чем больше снимки, тем больше время простоя.