После апгрейда провайдера plan хочет заменить живую базу — диагностируйте и избегите потери данных
Вы подняли провайдер AWS с 4.x до 5.x. В конфиге ничего не менялось, но plan теперь хочет ЗАМЕНИТЬ живой инстанс RDS (Relational Database Service) — уничтожение и пересоздание, которое сотрёт все данные. Объясните вероятные причины и как вы расследуете и избегаете потери данных, НЕ просто применяя.
# aws_db_instance.main must be replaced
-/+ resource "aws_db_instance" "main" {
~ id = "prod-db" -> (known after apply)
~ engine_version = "14.7" -> "14.10" # forces replacement
# (many unchanged attributes hidden)
}
Plan: 1 to add, 0 to change, 1 to destroy.
Определите причину и дайте безопасный ответ.
Мажор провайдера меняет, какой атрибут форсит замену — здесь engine_version теперь вызывает replace. Прочтите upgrade guide. Избегите уничтожения — ignore_changes или prevent_destroy, косметику сведите через -refresh-only. Не применяйте replace на живой БД вслепую.
- ✗Применять replace
-/+на stateful-ресурсе, не разобравшись - ✗Считать, что апгрейд провайдера никогда не форсит замену
- ✗Думать, что
ignore_changesне может остановить форсированную замену
- →Как
create_before_destroyснижает простой, когда замена неизбежна? - →Почему читать upgrade guide провайдера до подъёма мажорной версии?
Мажорный апгрейд провайдера меняет схему: другие дефолты или иная логика того, какой атрибут ForceNew. Здесь новый провайдер трактует смену engine_version как форсирующую замену -/+, что уничтожило бы БД.
Расследование и безопасный ответ
resource "aws_db_instance" "main" {
# ...
engine_version = "14.10" # выровнять код по реальной версии
lifecycle {
prevent_destroy = true # страховка от случайного destroy
ignore_changes = [engine_version] # не давать этому атрибуту форсить replace
}
}
terraform apply -refresh-only сводит state без пересоздания.
- Прочитать upgrade guide провайдера 4.x → 5.x — понять, что изменилось.
- Выровнять код по реальному значению; если дифф лишь косметический —
prevent_destroy— страховка, чтобыapplyне уничтожил БД по ошибке.
Никогда не применяйте -/+ на живой БД вслепую.