1.1 资产清单:列出要迁移的服务器、IP、应用、数据库、存储、负载均衡、证书和第三方依赖(SMTP、支付、API)。将清单导出为CSV,包含配置、容量、IO/带宽峰值。
1.2 目标SLA与时窗:确定允许的停机时间(例如30分钟)、可接受的数据丢失(RPO)和恢复时间(RTO),并据此选择同步方式(实时复制或冷迁移)。
2.1 IP、子网与路由:确认sg2分配的公网/私网IP、BGP或静态路由,准备防火墙白名单与安全组映射表。
2.2 DNS策略:提前将重要域名TTL降到60秒或更短(至少24小时生效),以便切换时快速回滚。记录当前DNS解析链路与缓存影响。
3.1 完整备份:在迁移前对所有主机做磁盘快照(云快照或SAN卷)和逻辑备份(mysqldump、pg_dump)。示例:mysqldump -u root -p --single-transaction --flush-logs --master-data=2 --all-databases > all.sql。
3.2 验证备份:从快照或备份恢复到临时环境,运行基本验签脚本(校验表数、行数,应用健康检查)。记录验证结果。
4.1 在线热迁移:对关系型数据库优先考虑主从复制或流复制(MySQL GTID、Postgres streaming replication)。示例:设置从库指向新sg2,从同步到一致后切换读写。
4.2 文件/对象数据:使用rsync增量+校验(rsync -azP --delete --numeric-ids /data/ user@sg2:/data/),或使用对象存储跨区域复制(S3/MinIO复制)。对大而冷的数据可采用异步后台搬迁。
5.1 镜像与配置管理:使用IaC工具(Terraform/Ansible)在sg2创建与现网一致的网络、安全组、实例和存储,确保配置可重复。
5.2 应用与证书:将SSL证书、密钥、安全凭证安全传输到sg2(使用Vault或加密传输),修改配置文件(nginx、haproxy)并测试本地访问。
6.1 演练步骤:在非生产域名或子网上完整演练一次端到端迁移:部署、数据同步、DNS切换、流量回流、回滚。
6.2 验收测试:定义健康检查(HTTP 200、数据库连接、队列长度),并用监控工具(Prometheus/Grafana)记录基线,比较性能差异。
7.1 T-6小时:再次确认备份、快照完成,团队就位,通知运维、客服、产品;将DNS TTL已降。
7.2 T-1小时:停止非关键批处理任务,启动最后一次增量同步(rsync --link-dest或数据库binlog同步)。
7.3 T-10分钟:将应用设为只读或进入维护模式,确保写入被缓存在队列或转发到主库。
7.4 T0(切换):将数据库主写切到sg2(切换VIP或修改应用DB配置),立刻切换DNS至sg2 IP(或更新负载均衡后端),同时监控流量与错误。
7.5 T+30分钟:对比数据一致性、回放binlog差异,打开业务全量写入,观察指标30-60分钟确认稳定。
8.1 回滚触发条件:错误率高于预设阈值(如5xx >5%)、数据不一致、依赖服务不可用超过设定时间。
8.2 回滚步骤:将应用切回原IP/负载均衡、将数据库主写恢复到源机(如果源机仍完整),或使用备份恢复。记录每一步的执行人、时间、变更单。
9.1 持续观察:迁移后72小时内重点监控CPU、内存、延迟、交易成功率、队列深度和数据库慢查询。
9.2 复盘与优化:写迁移总结(包含异常与改进点),更新Runbook并把演练结果固化为标准操作流程。
问:在快速迁移中如何最大限度防止数据丢失?
答:采用三要点:1)完整备份与快照并验证可恢复;2)建立同步复制(主从/流复制),把切换设为“先同步再切换”;3)降低DNS TTL并在切换窗口把写入暂缓或使用队列缓冲,确保最后一批增量能被重放。
问:如果DNS或BGP切换失败导致部分用户连接不到sg2,该如何应对?
答:立即触发回滚:恢复原DNS记录(TTL快生效),同时将load balancer回指旧机;在短时间内将用户引导到旧IP或通过CDN回源,并通知上游ISP与云厂商排查路由问题。
问:迁移过程如何保证机密信息与访问安全?
答:使用加密传输(SSH、VPN、TLS),凭证通过密钥管理服务下发并审计;迁移日志、操作步骤由多方复核并采用最小权限原则;迁移后立即旋转密钥与API凭证,关闭不再使用的管理端口。