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

Что происходит, когда мы удаляем SnapshotIdentifier из конфигурации Cloudformation

Когда мы развернули стек Cloudformation, мы восстановили DBCluster из моментального снимка. Сейчас мы обновляем наш стек.

Что Cloudformation сделает с нашим DBCluster, если мы удалим ключ SnapshotIdentifier из нашей конфигурации? Предположим, здесь мы не используем стековые политики.

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

Спасибо!

Это изменение атрибута DBSnapshotIdentifier действительно приведет к замене AWS :: RDS :: DBInstance.

За кулисами CloudFormation (CFN) хранит текущую конфигурацию всех ресурсов. Когда вы обновляете ресурс, CFN выполняет описательный вызов этих ресурсов и сравнивает его с сохраненными значениями.

Только если значения действительно изменятся, ресурсы будут обновлены. Тем не менее, пока вы не обновляете свойство DBSnapshotIdentifier, базу данных не следует заменять.

С RDS такое поведение CFN может вызвать раздражающие проблемы, особенно если конечные точки RDS меняются.

Вот что мы сейчас считаем хорошей практикой:

  1. Установите собственный стек RDS, отделенный от остальных. Экспортируйте конечную точку RDS как «RDSEndpoint- $ Version». Установите версию в качестве параметра.
  2. Направьте свои приложения на правильную конечную точку RDS. Проще всего было бы использовать экспорт из предыдущего стека или использовать для этого запись Route53.
  3. Если вам нужно внести изменения в экземпляры RDS, которые вызывают замену, внесите их в новый стек RDS, измените $ Version на что-то другое.
  4. Как только все окей. Измените конечную точку RDS в своих приложениях (или измените запись Route53, как вам удобнее).

Общие проблемы:

  • Продолжительность миграции данных между базами данных - если ваше приложение не поддерживает это, вы можете столкнуться с проблемами.
  • Операции изменения RDS обычно немного медленны. Часто бывает быстрее просто запустить mysqldump + mysql (в случае MySQL) вместо того, чтобы полагаться на экземпляры AWS.
  • Потеря учетных данных при переключении на новый стек (вы должны были задокументировать учетные данные, но все равно учитывайте это).

Если вы ищете одноразовое решение вашей конкретной проблемы, вот одно (с возможным временем простоя):

  1. Переведите приложение в режим только для чтения или в режим обслуживания (если приложение не поддерживает это, это может вызвать простои).
  2. (Вручную или с помощью RDS Snapshot) создайте дамп вашей базы данных.
  3. Обновите свою БД с помощью нового шаблона CloudFormation
  4. Восстанавливать из своего дампа.
  5. Переведите ваше приложение в рабочую среду. Если конечная точка изменилась, переключите и ее.