创建AWS EC2+EB实例测试副本，保障应用重大变更数据安全

你已经把最关键的基础步骤搞定了——克隆EB实例、用EBS快照生成新卷，这绝对是处理侵入式数据库迁移最稳妥的前置操作！接下来我帮你把剩下的配置步骤梳理清楚，确保你的测试副本完全独立、数据完整，能放心测试迁移：

1. 挂载新EBS卷到克隆的EB实例 #

• 先停止克隆的EB实例（一定要做这一步，避免挂载时损坏数据）
• 到EC2控制台找到你用快照生成的新EBS卷，将它挂载到克隆实例和原实例一致的挂载点（比如原实例用的/data/postgres，保持路径一致能减少配置改动）
• 启动克隆实例，登录后用命令验证挂载状态：df -h 检查挂载路径是否存在，ls /data/postgres 确认能看到PostgreSQL的数据文件

2. 更新EB实例的数据库连接配置 #

• 打开Elastic Beanstalk控制台，找到你的克隆环境
• 进入配置 > 软件板块，在环境属性里更新数据库相关的变量：
  • 把DB_HOST改成克隆实例的私有IP（或者直接填localhost，因为数据库现在是本地挂载的）
  • 确保DB_PORT、DB_NAME、DB_USER、DB_PASSWORD和生产环境完全一致（测试环境和生产保持一致才能准确验证迁移效果）
• 保存配置后，EB会自动重启应用服务器，让新配置生效

3. 验证副本数据库的可用性 #

• 登录克隆的EC2实例，用PostgreSQL客户端连接测试：psql -U <你的数据库用户名> -d <数据库名>
• 执行几个简单查询，比如SELECT count(*) FROM <核心业务表>;，对比生产环境的结果，确认快照恢复的数据是完整的

4. 隔离测试环境的网络（可选但强烈推荐） #

• 为了避免测试过程中意外影响生产，建议修改克隆环境的安全组：
  • 删除不必要的生产网络访问规则
  • 只开放你的办公IP或者测试工具的IP，允许访问应用和数据库端口

5. 推送迁移代码到副本环境 #

• 用EB CLI或者控制台把包含侵入式迁移的代码部署到克隆环境：eb deploy <你的克隆环境名称>
• 部署完成后，重点监控日志，确认迁移没有报错：
  • 查看EB应用日志：eb logs <你的克隆环境名称>
  • 查看PostgreSQL日志：tail -f /var/log/postgresql/postgresql-14-main.log（路径根据你的PostgreSQL版本调整）

6. 全面测试应用功能 #

• 迁移完成后，对应用的核心业务流程做完整测试，确保所有功能正常运行，数据没有出现异常
• 如果测试出问题，直接销毁克隆环境就行，调整迁移代码后再重新创建副本测试，完全不会影响生产环境

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