服务器台湾托管迁移案例展示与实施时间表

1. 迁移前准备与资产清单

1.1 清点资产：列出网站域名、应用代码路径、静态文件、数据库（类型、版本）、缓存（Redis/Memcached）、证书（Let's Encrypt 或商业证书）、计划任务与队列服务。
1.2 权限与账号：确认源托管与目标机房的控制台账号、SSH 密钥、数据库账号及权限、域名注册商登录信息。
1.3 测试环境：在迁移前在目标环境搭建一套和生产近似的测试环境用于演练。

2. 风险评估与时间窗口确定

2.1 评估停机需求：确定能否实现零停机或需短时间停机；若有事务型数据库，考虑主从复制或双写策略。
2.2 确定迁移窗口：根据访问高峰选择低峰时间，将 DNS TTL 提前降到 300 秒或更低，至少提前 48 小时设置。

3. 数据备份与验证（文件与数据库）

3.1 备份步骤：文件用 rsync 或 tar 打包（tar -czf /backup/site_$(date +%F).tar.gz /var/www/site），数据库用 mysqldump（mysqldump -u root -p --single-transaction --routines --triggers --events dbname > db.sql）。
3.2 验证备份：确认 tar 可以解压并校验，数据库用 mysql --user=root --password=... dbname < db.sql 在测试库导入验证无错。

4. 目标服务器环境建设（操作系统、依赖、服务）

4.1 系统与补丁：安装相同或兼容的操作系统版本并打上安全补丁（apt update && apt upgrade 或 yum update）。
4.2 安装依赖：安装 Nginx/Apache、PHP/Node/Python 运行时、数据库客户端、Redis、所需库（示例：apt install nginx php-fpm mysql-client git rsync）。配置时记下配置文件路径与差异。

5. 文件同步实操（使用 rsync）

5.1 初次全量同步：在目标机执行 rsync 从源机拉取全量数据，例如：rsync -avz --delete -e "ssh -i /root/.ssh/id_rsa" root@source_ip:/var/www/site/ /var/www/site/。
5.2 增量同步：在切换前做一次短时差异同步，使用相同命令以确保文件一致性。保留上传日志以便审计。

6. 数据库迁移策略（全量与增量、复制）

6.1 简单站点：使用 mysqldump 全量导出在目标导入（mysql -u root -p dbname < db.sql）。
6.2 零停机要求：配置源作为主，目标设置为从（设置 binlog、创建复制用户、在目标 change master to MASTER_HOST='source_ip', MASTER_USER='repl', MASTER_PASSWORD='pwd', MASTER_LOG_FILE='file', MASTER_LOG_POS=pos; start slave;），完成后在切换点提升为主。

7. SSL/证书、域名与配置迁移

7.1 证书迁移：将私钥与证书安全拷贝到目标（scp -i key cert.pem root@target:/etc/ssl/），设置正确权限（chmod 600）。若使用 Let's Encrypt，可在目标重新申请 certbot renew。
7.2 配置同步：复制 Nginx/Apache 配置并修改 upstream/IP，使用 nginx -t 验证语法，systemctl reload nginx 重载。

8. 测试与预演（在 hosts 文件上测试流量）

8.1 Hosts 覆盖测试：在本地机器或 QA 机上修改 /etc/hosts 指向目标 IP，访问网站并测试功能点（登录、下单、文件上传、邮件）。
8.2 性能与安全测试：运行压力测试（ab 或 wrk）与安全扫描，确认目标环境满足 SLA。

9. 切换步骤与最小化停机（具体操作时间表）

9.1 切换前 48-24 小时：降低 DNS TTL 至 300；完成大部分同步与预演。
9.2 切换当日（示例 4 小时窗口）：第0-30分钟：停止应用写入（置维护页），最后一次文件 rsync 与数据库增量 dump；30-60分钟：导入数据库并切换数据库角色，调整配置指向本地 DB；60-90分钟：在目标上开启 Web 服务并健康检查；90-120分钟：切换 DNS 到新 IP，监控流量；120-240分钟：观测系统稳定，逐步恢复正常。

10. 回滚方案与监控指标

10.1 回滚条件：若关键业务失败且无法在预期时间内修复，回滚至源机并将 DNS 指回（TTL 生效需等待）。
10.2 监控与报警：迁移期间重点监控 5 个指标：错误率、响应时长、CPU/内存、数据库延迟、队列积压。设置报警阈值并指定负责人。

11. 迁移后检查与优化清单

11.1 完整性检查：确认日志、文件上传、邮件、第三方 API 都正常并无遗漏数据。
11.2 性能优化：调整缓存策略（开启 opcode cache、调整 Redis 参数）、优化 Nginx keepalive 与 TCP 参数（net.core.somaxconn、tcp_tw_recycle 等），并记录变化。

12. 实施时间表示例（7 天计划）

12.1 第1天：资产清单与环境搭建；第2天：安装依赖并搭建测试环境；第3天：初次全量文件同步与数据库导入测试；第4天：证书与配置迁移演练；第5天：切换预演与回滚演练；第6天：降低 TTL 并准备切换；第7天：正式切换与观测。

13. 常见问题与解答 — Q1

问：迁移期间如何保证数据不丢失？

14. 常见问题与解答 — A1

答：采用先全量同步再增量同步的策略；在数据库层面如果需要零停机，启用主从复制或双写，切换时选择稳定的 binlog position；切换前做最后一次短暂停写并导出增量，导入目标后确认数据一致性再切流。

15. 常见问题与解答 — Q2

问：DNS 切换后访问仍指向旧服务器怎么办？

16. 常见问题与解答 — A2

答：首先确认 DNS TTL 是否已提前降低到较小值并已过期；使用 dig +trace 或 dig @8.8.8.8 domain A 检查各级解析是否生效；短期内可通过修改客户端 hosts 做验证；若部分用户仍访问旧机，检查缓存（ISP 缓存、浏览器缓存）并通知用户等待 TTL 生效或重启服务。

来源：服务器台湾托管迁移案例展示与实施时间表