1.

迁移前准备与评估

- 评估现有环境：操作系统（示例：Ubuntu 20.04）、Web 服务（nginx 1.18）、数据库（MySQL 8.0）和应用版本。
- 带宽与延迟测量：使用 iperf3 测试两地带宽（示例数据：上行 200Mbps，下行 200Mbps，RTT 25ms）。
- 确认 CN2 线路需求：若目标用户在中国大陆，选择台湾 CN2 回程可降低丢包和延迟。
- 安全与合规检查：确认数据备份、敏感信息加密及防火墙策略。
- 资源核算：估算磁盘/CPU/内存（示例：4 vCPU、8 GB RAM、200 GB SSD）与峰值并发，准备负载测试计划。
- 迁移窗口确定：依据流量曲线选择低峰窗，提前告知业务方。

2.

目标服务器与网络配置示例

- 示例主机配置：CPU 4 核、内存 8 GB、磁盘 200 GB NVMe、带宽 1 Gbps（共享），操作系统：Ubuntu 20.04 LTS。
- 公网 IP 示例：旧机 203.0.113.10，新机 198.51.100.20（仅示意）。
- 防火墙策略：允许 22/80/443/3306（限内网或 VPN），拒绝未授权端口，使用 fail2ban 限制 SSH 登录。
- CDN 与 DDoS：建议接入国内 CDN（示例：加速域名绑定到 CDN 节点），并在机房或云端启用 DDoS 基础防护。
- 监控与告警：配置 Prometheus + Grafana 或云厂商监控，设定 CPU>80%、磁盘>70% 告警阈值。
- 备份方案：每日离线全量备份，每小时增量备份并异地保存 7 天。

3.

数据同步（文件与静态资源）操作流程

- 推荐工具：rsync（增量、断点续传）与 lsyncd（实时同步）结合使用。示例命令：rsync -azP /var/www/ www@198.51.100.20:/var/www/ 。
- 同步模式：先做一次全量 rsync（24 小时窗口内）再启动周期性增量（每 5 分钟或根据变更量）。
- 校验机制：用 md5sum 或 sha256sum 批量校验关键目录一致性，示例：find /var/www -type f -exec sha256sum {} \; > old.sha256 。
- 表格示例（同步性能与预估时间）：

数据量	网速	估计时间
50 GB	200 Mbps	约 35 分钟
200 GB	200 Mbps	约 2 小时 20 分

- 断点续传与带宽限制：rsync --partial --bwlimit=20000（限制为 20MB/s）的示例。
- 真实案例：某电商在双十一前将 120GB 静态文件从香港迁到台湾 CN2，使用 rsync 全量 + 每 2 分钟增量，最终 99.99% 文件一致。

4.

数据库迁移与实时复制（MySQL）

- 方案选择：主从复制（异地从库）或基于 GTID 的复制。示例使用 MySQL 8.0 GTID。
- 初始全量导出：使用 mysqldump --single-transaction --master-data=2 --databases dbname > dump.sql。
- 导入并启动复制：在新机导入 dump.sql，然后执行 CHANGE MASTER TO MASTER_HOST='203.0.113.10', MASTER_USER='repl', MASTER_PASSWORD='rep_pwd', MASTER_AUTO_POSITION=1; START SLAVE; 。
- 验证复制状态：SHOW SLAVE STATUS\G，确认 Seconds_Behind_Master 值趋近 0。
- 切换策略：业务停写窗口内将旧主切为只读，等从库追上后在新机上临时提升为主。
- 真实案例：一个 SaaS 服务用 GTID 复制将 300GB 数据迁移到台湾 CN2，初始导出耗时 4 小时，增量复制在 30 分钟内追平，切换窗口控制在 5 分钟内完成。

5.

DNS 切换与 TTL 策略

- TTL 调整：提前 48 小时将主域名 TTL 从 1 小时降到 60 秒或 300 秒，便于快速回滚。
- DNS 切换步骤：验证新机服务健康后，修改 A 记录指向新 IP，逐步切换子域名（静态 CDN、API、主站）。
- 验证方式：使用 dig +trace 和 curl --resolve 命令强制解析验证新 IP 服务。
- 回滚计划：记录原始 TTL 与原 IP，若新机异常在 TTL 到期后恢复到旧 IP。
- CDN 配合：在切换 DNS 同时请求 CDN 清理缓存（Purge），并确保 CDN 后端点已更新为新 IP。
- 真实案例：在一次零售站迁移中，提前 72 小时将 TTL 设置为 300 秒，切换后 8 分钟内全球 90% 用户解析到新 IP，回滚无中断。

6.

切换当天的操作清单与命令示例

- 最终同步前操作：停止写入或将应用切到维护模式。
- 文件增量命令示例：rsync -azP --delete /var/www/ www@198.51.100.20:/var/www/ 。
- 数据库切换命令示例：在旧库设置 READ_ONLY=1，确认复制追平；在新机执行 STOP SLAVE; RESET SLAVE ALL; （如做主切换则不要忘记更新应用 DB 配置）。
- 验证服务：curl -I https://example.com 检查 200 OK；使用 ab 或 wrk 做轻负载验证。
- 切换后监控：重点观察 5 分钟内的 5xx、响应时延、数据库错误数并即时报警。
- 回滚触发条件：若错误率 >1% 或核心接口失败率高于阈值，立即按回滚步骤切换回旧 IP。

7.

CDN 与 DDoS 防御要点

- CDN 节点与回源配置：确保 CDN 的回源设置指向新机，并配置健康检查路径（/healthz）。
- 缓存策略：静态资源设置长缓存（Cache-Control: max-age=31536000），动态接口设置 no-cache。
- DDoS 基础防护：启用速率限制、连接数限制、SYN Cookies 与 ACL。
- 高级防护：使用云盾或厂商 WAF 防护常见攻击规则，设置异常流量阈值并自动拉黑。
- 演练与阈值：定期演练清洗流程，设置告警（流量 > 平均峰值的 200%）。
- 真实案例：某游戏公司在台湾 CN2 上线首月遭遇 UDP 放大攻击，启用云端清洗后峰值流量从 3.2 Gbps 降到 150 Mbps，服务持续可用。

8.

迁移后验证、优化与总结

- 验证项清单：文件校验、数据库一致性、证书有效性、第三方接口连通性、性能基准对比。
- 性能监测：在 7 天内重点观测 P95、P99 响应时间与错误率，记录基线用于回归对比。
- 优化建议：开启 HTTP/2 或 QUIC（如支持），开启 gzip/ brotli，按需扩展连接数与缓存策略。
- 文档化与知识沉淀：记录每一步操作、命令、时间点、回滚条件与最终结果作为 SOP。
- 项目复盘：召开迁移复盘会，收集问题与改进项，为下次迁移优化流程。
- 总结话语：按以上步骤，以严谨的测试、分阶段切换与充分的回滚计划为前提，可将台湾 CN2 服务器迁移风险降到最低并保证业务连续性。

来源：台湾cn2服务器迁移攻略从数据同步到DNS切换的完整操作流程