Fleet 数据库蓝绿恢复使用 fleet-terraform 零停机还原 RDS Aurora 集群【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet当 Fleet 的 RDS Aurora 集群需要还原——无论是从快照还是恢复到某个时间点PITR——直接停库还原会让整个 Fleet 服务不可用。本文介绍的蓝绿blue-green方案在还原期间让原集群继续对外提供服务先拉起一个还原出来的新集群、验证无误后再切换流量、最后拆掉旧集群。读完本文你可以完整掌握基于 fleet-terraform 模块的rds_configs多集群配置语法、active_rds_config_name切换机制以及一套可复制的五步操作流程在不停机的情况下完成 Fleet 数据库的灾难恢复。需要说明的前提本方案适用于通过独立仓库 fleet-terraformfleetdm/fleet-terraform部署的 Fleet 环境。Fleet 主仓库内的 terraform/README.md 已声明 Terraform 模块迁出至该独立仓库本仓库仅保留指向页与内部 dogfood 基础设施因此本文中的main.tf均指你自己环境里使用 fleet-terraform 模块的根模块。前置条件在开始之前确认满足以下条件继承自原文档Fleet 已通过 fleet-terraform 部署且根模块版本tf-mod-root-v1.31.0或更高本地已安装 Terraform且可以访问你的 state本地或远程 backend 均可具备 AWS RDS 与 Secrets Manager 的操作权限创建/删除 Aurora 集群、读写数据库密码密钥已确定还原来源一个快照 ARN或一个用于 PITR 的 UTC 时间戳例如2026-07-17T06:14:01Z注意必须是 UTC 且格式为YYYY-MM-DDTHH:MM:SSZ。Fleet Premium 客户提示在动手之前先联系 Fleet 官方支持团队会陪同你完成整个过程。核心概念rds_configs与active_rds_config_name从tf-mod-root-v1.31.0起fleet-terraform 根模块将原来单数的rds_config对象升级为复数的rds_configs映射map你可以在同一份main.tf中声明多个 Aurora 集群配置每个配置以任意字符串为键文中分别用current与next再由顶层参数active_rds_config_name指定当前对 Fleet 生效的那一个。这就是蓝绿切换的开关改一个字符串、跑一次terraform applyFleet 的连接目标就指向另一个集群而无需改动 Fleet 应用本身——模块内部会自动把对应集群的端点与 Secrets Manager 密码密钥注入到部署中。理解这一机制后整个流程就是旧集群blue→ 旁路创建还原集群green→ 验证 → 切换 → 拆除旧集群。步骤 1把现有集群迁移到rds_configs结构如果你的main.tf中已经使用rds_configs直接跳到步骤 2。需要做三件事把模块 source 升级到v1.31.0或更高把rds_config重命名为rds_configs并将现有配置块包进一个current键新增active_rds_config_name指向current。完整变更如下diff 格式原文档原样保留module main { - source github.com/fleetdm/fleet-terraform?depth1reftf-mod-root-v1.30.0 source github.com/fleetdm/fleet-terraform?depth1reftf-mod-root-v1.31.0 - rds_config { rds_configs { current { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name local.rds_cluster_name instance_class db.t4g.medium replicas 1 } } active_rds_config_name current }运行terraform apply。这一步是纯结构迁移集群参数逐字保留、active_rds_config_name仍指向原集群因此对运行中的 Fleet 没有任何行为变化只是把配置放进了可多集群的容器里。步骤 2旁路添加next集群并触发还原在current旁边新增一个next配置块。有两个关键注意事项暂时关闭监控将monitoring_interval设为0、observability.performance_insights_enabled设为false。因为 Aurora 的还原过程可能耗时数分钟期间集群尚不可用此时若开启完整监控/性能洞察会产生terraform apply报错。还原来源二选一PITR 用restore_to_point_in_time快照还原用snapshot_identifier不要同时使用。PITR按时间点恢复rds_configs { current { ... } next { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name ${local.rds_cluster_name}-next instance_class db.t4g.medium replicas 1 monitoring_interval 0 observability { performance_insights_enabled false } restore_to_point_in_time { source_cluster_identifier local.rds_cluster_name restore_to_time 2026-07-17T06:14:01Z } } } active_rds_config_name current快照还原rds_configs { current { ... } next { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name ${local.rds_cluster_name}-next instance_class db.t4g.medium replicas 1 monitoring_interval 0 observability { performance_insights_enabled false } snapshot_identifier your-snapshot-identifier } } active_rds_config_name current注意name用了${local.rds_cluster_name}-next两个集群标识符必须不同且还原出的新集群要能拿到自己的 Secrets Manager 密码密钥模块会按配置自动生成命名规则见步骤 5。运行terraform apply。此时还原在后台进行Fleet 继续从current集群读写服务完全在线。成本提示从本步开始到步骤 5 之前你同时持有两套 Aurora 集群AWS 账单会相应增加计划操作窗口时应把这笔额外成本计入。仓库内旁证Fleet 团队自己的临时还原集群实践Fleet 仓库内部 dogfood 基础设施中infrastructure/dogfood/terraform/aws-tf-module/db-temp-restores/main.tf 展示了同一思路的临时还原集群用法可帮助理解还原集群的合理形态使用terraform-aws-modules/rds-aurora/aws~ 9.0模块engine aurora-mysql以snapshot_identifier拉起还原集群local.customers中形如arn:aws:rds:...:cluster-snapshot:rds:...的集群快照 ARNmanage_master_user_password true让 Secrets Manager 托管主密码master_username fleet必须与快照中的管理员用户一致——这正对应了本文步骤 5 中密码按config.name独立成密钥的前提还原集群刻意做小以控制成本db.serverless单实例 serverlessv2_scaling_configurationmin_capacity 0、max_capacity 4并skip_final_snapshot true、deletion_protection false用完即拆。如果你的还原集群规格较大例如与生产同规格的db.t4g.medium 1 副本旁路期间的额外成本会明显高于这种 serverless 方案可按还原验证所需的最小可用规模酌情下调next的instance_class与replicas。步骤 3还原完成后恢复next的监控等待terraform apply结束、next集群状态变为available后删掉步骤 2 里的监控覆盖项让它回落到模块默认值next { ... - monitoring_interval 0 - observability { - performance_insights_enabled false - } restore_to_point_in_time { source_cluster_identifier local.rds_cluster_name restore_to_time 2026-07-17T06:14:01Z } }运行terraform apply。这一步把 Enhanced Monitoring / Performance Insights 恢复到模块默认配置让还原集群从临时验证态进入生产态。在切换之前建议先验证next上的数据是否符合预期。仓库内 dogfood 的 show_db_temp_info.py 提供了一个可借鉴的验证方式它调用terraform output -json解析出每个还原集群的cluster_endpoint、cluster_engine_version_actual、cluster_database_name等信息并打印成人类可读的摘要供运维人员确认端点与引擎版本后再人工连接核对数据。步骤 4切换到next只改一个属性- active_rds_config_name current active_rds_config_name next运行terraform apply。模块会将 Fleet 的 MySQL 连接端点与密码密钥指向next集群Fleet 从此刻起在还原后的数据库上读写。此时两套集群都在运行current已被弃用但仍在计费。步骤 5删除current并更新监控密钥引用删除current整个配置块rds_configs { - current { - ... - } next { ... } }如果你使用 fleet-terraform 的 monitoring 模块还需要把它引用的数据库密码密钥换成next的。模块按config.name-database-password的命名规则为每个集群各建一个密钥所以module monitoring { cron_monitoring { - mysql_password_secret_name ${local.rds_cluster_name}-database-password mysql_password_secret_name ${local.rds_cluster_name}-next-database-password } }运行terraform apply原集群被拆除计费停止。注意此步骤执行后恢复目标回退能力下降新集群成为唯一数据源其自身的backup_retention_period与自动快照开始积累备份。删除前再次确认next上数据无误是必要的。收尾验证terraform apply成功后登录 Fleet 界面核对数据是否符合预期主机清单、策略、软件包等是否停留在你期望的还原时间点。至此 Fleet 已运行在还原后的数据库上整个过程中 Fleet 服务没有中断。流程小结步骤关键动作集群状态1rds_config→rds_configsactive_rds_config_name current1 个集群结构迁移无行为变化2新增next关闭监控 PITR 或snapshot_identifier2 个集群后台还原Fleet 不受影响3移除next的监控覆盖还原完成恢复默认监控验证数据4active_rds_config_name next流量切换Fleet 读写还原集群5删除currentmonitoring 密钥改指name-next-database-password回到 1 个集群计费停止适用边界再强调一遍本方案要求 fleet-terraform 根模块tf-mod-root-v1.31.0及以上、AWS 上的 Aurora 部署、以及本地 Terraform 对 state 的完整访问权限restore_to_time必须是 UTC 时间戳且落在 Aurora PITR 保留窗口内快照还原则要求快照仍可用。满足这些前提后上述五步即可完成一次零停机的 Fleet 数据库恢复。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Fleet 数据库蓝绿恢复：使用 fleet-terraform 零停机还原 RDS Aurora 集群
Fleet 数据库蓝绿恢复使用 fleet-terraform 零停机还原 RDS Aurora 集群【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet当 Fleet 的 RDS Aurora 集群需要还原——无论是从快照还是恢复到某个时间点PITR——直接停库还原会让整个 Fleet 服务不可用。本文介绍的蓝绿blue-green方案在还原期间让原集群继续对外提供服务先拉起一个还原出来的新集群、验证无误后再切换流量、最后拆掉旧集群。读完本文你可以完整掌握基于 fleet-terraform 模块的rds_configs多集群配置语法、active_rds_config_name切换机制以及一套可复制的五步操作流程在不停机的情况下完成 Fleet 数据库的灾难恢复。需要说明的前提本方案适用于通过独立仓库 fleet-terraformfleetdm/fleet-terraform部署的 Fleet 环境。Fleet 主仓库内的 terraform/README.md 已声明 Terraform 模块迁出至该独立仓库本仓库仅保留指向页与内部 dogfood 基础设施因此本文中的main.tf均指你自己环境里使用 fleet-terraform 模块的根模块。前置条件在开始之前确认满足以下条件继承自原文档Fleet 已通过 fleet-terraform 部署且根模块版本tf-mod-root-v1.31.0或更高本地已安装 Terraform且可以访问你的 state本地或远程 backend 均可具备 AWS RDS 与 Secrets Manager 的操作权限创建/删除 Aurora 集群、读写数据库密码密钥已确定还原来源一个快照 ARN或一个用于 PITR 的 UTC 时间戳例如2026-07-17T06:14:01Z注意必须是 UTC 且格式为YYYY-MM-DDTHH:MM:SSZ。Fleet Premium 客户提示在动手之前先联系 Fleet 官方支持团队会陪同你完成整个过程。核心概念rds_configs与active_rds_config_name从tf-mod-root-v1.31.0起fleet-terraform 根模块将原来单数的rds_config对象升级为复数的rds_configs映射map你可以在同一份main.tf中声明多个 Aurora 集群配置每个配置以任意字符串为键文中分别用current与next再由顶层参数active_rds_config_name指定当前对 Fleet 生效的那一个。这就是蓝绿切换的开关改一个字符串、跑一次terraform applyFleet 的连接目标就指向另一个集群而无需改动 Fleet 应用本身——模块内部会自动把对应集群的端点与 Secrets Manager 密码密钥注入到部署中。理解这一机制后整个流程就是旧集群blue→ 旁路创建还原集群green→ 验证 → 切换 → 拆除旧集群。步骤 1把现有集群迁移到rds_configs结构如果你的main.tf中已经使用rds_configs直接跳到步骤 2。需要做三件事把模块 source 升级到v1.31.0或更高把rds_config重命名为rds_configs并将现有配置块包进一个current键新增active_rds_config_name指向current。完整变更如下diff 格式原文档原样保留module main { - source github.com/fleetdm/fleet-terraform?depth1reftf-mod-root-v1.30.0 source github.com/fleetdm/fleet-terraform?depth1reftf-mod-root-v1.31.0 - rds_config { rds_configs { current { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name local.rds_cluster_name instance_class db.t4g.medium replicas 1 } } active_rds_config_name current }运行terraform apply。这一步是纯结构迁移集群参数逐字保留、active_rds_config_name仍指向原集群因此对运行中的 Fleet 没有任何行为变化只是把配置放进了可多集群的容器里。步骤 2旁路添加next集群并触发还原在current旁边新增一个next配置块。有两个关键注意事项暂时关闭监控将monitoring_interval设为0、observability.performance_insights_enabled设为false。因为 Aurora 的还原过程可能耗时数分钟期间集群尚不可用此时若开启完整监控/性能洞察会产生terraform apply报错。还原来源二选一PITR 用restore_to_point_in_time快照还原用snapshot_identifier不要同时使用。PITR按时间点恢复rds_configs { current { ... } next { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name ${local.rds_cluster_name}-next instance_class db.t4g.medium replicas 1 monitoring_interval 0 observability { performance_insights_enabled false } restore_to_point_in_time { source_cluster_identifier local.rds_cluster_name restore_to_time 2026-07-17T06:14:01Z } } } active_rds_config_name current快照还原rds_configs { current { ... } next { preferred_maintenance_window fri:04:00-fri:05:00 backup_retention_period 30 skip_final_snapshot false db_parameters { sort_buffer_size 8388608 } db_cluster_parameters { require_secure_transport ON } engine_version 8.0.mysql_aurora.3.10.3 name ${local.rds_cluster_name}-next instance_class db.t4g.medium replicas 1 monitoring_interval 0 observability { performance_insights_enabled false } snapshot_identifier your-snapshot-identifier } } active_rds_config_name current注意name用了${local.rds_cluster_name}-next两个集群标识符必须不同且还原出的新集群要能拿到自己的 Secrets Manager 密码密钥模块会按配置自动生成命名规则见步骤 5。运行terraform apply。此时还原在后台进行Fleet 继续从current集群读写服务完全在线。成本提示从本步开始到步骤 5 之前你同时持有两套 Aurora 集群AWS 账单会相应增加计划操作窗口时应把这笔额外成本计入。仓库内旁证Fleet 团队自己的临时还原集群实践Fleet 仓库内部 dogfood 基础设施中infrastructure/dogfood/terraform/aws-tf-module/db-temp-restores/main.tf 展示了同一思路的临时还原集群用法可帮助理解还原集群的合理形态使用terraform-aws-modules/rds-aurora/aws~ 9.0模块engine aurora-mysql以snapshot_identifier拉起还原集群local.customers中形如arn:aws:rds:...:cluster-snapshot:rds:...的集群快照 ARNmanage_master_user_password true让 Secrets Manager 托管主密码master_username fleet必须与快照中的管理员用户一致——这正对应了本文步骤 5 中密码按config.name独立成密钥的前提还原集群刻意做小以控制成本db.serverless单实例 serverlessv2_scaling_configurationmin_capacity 0、max_capacity 4并skip_final_snapshot true、deletion_protection false用完即拆。如果你的还原集群规格较大例如与生产同规格的db.t4g.medium 1 副本旁路期间的额外成本会明显高于这种 serverless 方案可按还原验证所需的最小可用规模酌情下调next的instance_class与replicas。步骤 3还原完成后恢复next的监控等待terraform apply结束、next集群状态变为available后删掉步骤 2 里的监控覆盖项让它回落到模块默认值next { ... - monitoring_interval 0 - observability { - performance_insights_enabled false - } restore_to_point_in_time { source_cluster_identifier local.rds_cluster_name restore_to_time 2026-07-17T06:14:01Z } }运行terraform apply。这一步把 Enhanced Monitoring / Performance Insights 恢复到模块默认配置让还原集群从临时验证态进入生产态。在切换之前建议先验证next上的数据是否符合预期。仓库内 dogfood 的 show_db_temp_info.py 提供了一个可借鉴的验证方式它调用terraform output -json解析出每个还原集群的cluster_endpoint、cluster_engine_version_actual、cluster_database_name等信息并打印成人类可读的摘要供运维人员确认端点与引擎版本后再人工连接核对数据。步骤 4切换到next只改一个属性- active_rds_config_name current active_rds_config_name next运行terraform apply。模块会将 Fleet 的 MySQL 连接端点与密码密钥指向next集群Fleet 从此刻起在还原后的数据库上读写。此时两套集群都在运行current已被弃用但仍在计费。步骤 5删除current并更新监控密钥引用删除current整个配置块rds_configs { - current { - ... - } next { ... } }如果你使用 fleet-terraform 的 monitoring 模块还需要把它引用的数据库密码密钥换成next的。模块按config.name-database-password的命名规则为每个集群各建一个密钥所以module monitoring { cron_monitoring { - mysql_password_secret_name ${local.rds_cluster_name}-database-password mysql_password_secret_name ${local.rds_cluster_name}-next-database-password } }运行terraform apply原集群被拆除计费停止。注意此步骤执行后恢复目标回退能力下降新集群成为唯一数据源其自身的backup_retention_period与自动快照开始积累备份。删除前再次确认next上数据无误是必要的。收尾验证terraform apply成功后登录 Fleet 界面核对数据是否符合预期主机清单、策略、软件包等是否停留在你期望的还原时间点。至此 Fleet 已运行在还原后的数据库上整个过程中 Fleet 服务没有中断。流程小结步骤关键动作集群状态1rds_config→rds_configsactive_rds_config_name current1 个集群结构迁移无行为变化2新增next关闭监控 PITR 或snapshot_identifier2 个集群后台还原Fleet 不受影响3移除next的监控覆盖还原完成恢复默认监控验证数据4active_rds_config_name next流量切换Fleet 读写还原集群5删除currentmonitoring 密钥改指name-next-database-password回到 1 个集群计费停止适用边界再强调一遍本方案要求 fleet-terraform 根模块tf-mod-root-v1.31.0及以上、AWS 上的 Aurora 部署、以及本地 Terraform 对 state 的完整访问权限restore_to_time必须是 UTC 时间戳且落在 Aurora PITR 保留窗口内快照还原则要求快照仍可用。满足这些前提后上述五步即可完成一次零停机的 Fleet 数据库恢复。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考