Terraform恢复AWS DocumentDB集群快照回滚的正确方法

你新增snapshot_identifier执行apply后集群无变化，本质是两个认知偏差：

1. Terraform AWS Provider对aws_docdb_cluster的snapshot_identifier字段是CreateOnly属性，仅在集群首次创建时读取生效，对已经存在的运行中集群，修改/新增这个字段不会触发任何更新、重建动作，因此看不到任何变更。
2. 不管是控制台、API还是Terraform，AWS DocumentDB本身就不支持原地给现有集群回滚快照，所有快照恢复操作本质都是生成一个全新的集群。你担心的新集群脱离Terraform管理的问题，完全可以通过标准的Terraform生命周期配置解决，不需要追求不存在的原地回滚能力。

按以下流程操作，恢复出来的集群会完全保留你原有代码里的资源标识、实例配置，全程在Terraform状态管理范围内，不会出现配置漂移：

• 第一步：先临时关闭旧集群的删除保护。把aws_docdb_cluster.this配置里的deletion_protection改为false，执行terraform apply等变更生效，不做这步后续删除旧集群会直接报错。
• 第二步：调整集群资源配置：
  1. 确认snapshot_identifier填写的是目标快照的完整正确ARN，且快照状态为available
  2. 在aws_docdb_cluster.this资源块内增加如下生命周期配置，避免同名集群冲突：

  lifecycle {
    create_before_destroy = true
  }
  

  因为你的集群标识cluster_identifier是固定值，不加这个配置的话，Terraform会先尝试删除旧集群再建新集群，而旧集群删除后标识名不会立刻释放，会导致新集群创建时重名失败。加了这个配置后，Terraform会先生成带临时名称的新集群，等新集群基于快照恢复完成、挂载实例正常运行后，再删除旧集群，最后把新集群的标识改成你配置的固定名称，全程不会有重名问题。
• 第三步：先执行terraform plan核对执行计划，确认计划中的动作符合预期：
  • 先销毁现有集群下挂载的两个aws_docdb_cluster_instance资源
  • 基于指定快照创建新的DocumentDB集群
  • 在新集群下创建两个配置一致的实例
  • 最后删除旧的DocumentDB集群
    确认计划无异常后再执行terraform apply。
• 第四步：等所有资源创建完成、集群状态变为可用后，你可以选择把配置里的snapshot_identifier字段删除（留着也不会有副作用，因为集群已存在后这个字段不会被Provider读取触发变更），再把deletion_protection改回true，执行一次apply就回到正常的运维状态。

• 整个恢复过程存在业务中断窗口，时长和快照存储的数据量正相关，务必在业务低峰期操作。
• 新集群首次创建完成后，Terraform会自动对比你代码里定义的参数组、备份策略、安全组等配置，和快照继承的配置有差异的部分会自动修正，不需要手动调整。
• 不要采用控制台手动恢复再terraform import的方案，导入流程需要手动对齐十余个关联字段，非常容易出现配置漂移，后续运维隐患很大。

内容的提问来源于stack exchange，提问作者theahura