日本最实用云服务器迁移攻略含镜像打包与数据同步零停机方案

1.

准备与评估（清单与网络规划）

- 列出源端（旧服务器）和目标端（日本云）的操作系统、磁盘布局、IP、应用端口与依赖。
- 检查目标云支持的镜像格式（raw/qcow2/vmdk），是否支持导入镜像或需要通过快照/模板创建实例。
- 评估网络：是否可使用专线、VPN或公网（建议日本区域内直连或低延迟VPN）。设置DNS TTL为60秒或更低以便切换。

2.

备份与快照（先行备份，保证可回滚）

- 在源端创建完整快照或使用云提供的快照功能（若为物理机，先做磁盘镜像 dd 或使用 rsync + tar）。
- 导出数据库逻辑备份（mysqldump、pg_dump）并备份配置文件（/etc、应用配置）。将备份上传到独立存储（S3兼容或对象存储）以确保安全。

3.

系统清理与镜像打包（减小体积，去敏感信息）

- 清理日志：sudo journalctl --vacuum-time=2days；清空 /var/log/*.log。
- 删除临时文件、SSH host keys（/etc/ssh/ssh_host_*）与云厂商特有的实例元数据文件（视情况）。
- 零填充以压缩镜像（sudo dd if=/dev/zero of=/zerofile bs=1M || true; sudo rm /zerofile），然后创建镜像：使用 qemu-img convert -O qcow2 /dev/sdX disk.qcow2（或 dd if=/dev/sdX of=disk.raw）。

4.

镜像上传与导入（目标云的实践步骤）

- 若目标云支持镜像导入，使用官方工具（例如云控制台导入/CLI）上传 disk.qcow2 或 raw。
- 若不支持直接导入，先将镜像转为常见格式，再通过 SCP/rsync 上传到目标云的临时实例，使用云控制台从该实例创建自定义镜像。
- 导入后创建与源同规格的实例，先使用私有子网并开启仅管理端口以便测试。

5.

数据同步（文件层面）零停机方案

- 使用 rsync 的增量复制：rsync -azh --progress --delete --exclude='/proc' /data/ user@target:/data/。首次全量后定时增量（每5分钟或更短）。
- 为避免短暂文件不一致，可使用 lsyncd 将本地变化实时推送到目标（lsyncd.conf.lua 配置 rsync 包裹）。
- 对大文件/大量小文件，优先使用并发 rsync 或通过分片并行传输以缩短同步窗口。

6.

数据库零停机迁移（主从复制方案）

- MySQL：在目标建立从库，配置 binlog、server-id，执行 CHANGE MASTER TO ... START SLAVE；等待完全同步并监控 Seconds_Behind_Master。
- PostgreSQL：使用流复制或 wal2json + logical replication，先建立订阅并等待落后为0。
- 完全同步后将写流切换到目标（短暂停止写入或使用应用层写分流），验证事务一致性，再将目标提升为主库。

7.

最终切换（零停机或最小化停机的切换步骤）

- 将应用写入短暂切换到只读模式（如果支持），或使用负载均衡器将流量逐步引导到新实例。
- 使用漂移IP/浮动IP（例如云弹性IP）或更新DNS（TTL已降）做最终切换。完成前做一次 rsync --delete 做最后一致性同步，或在数据库层做 final binary/log position 检查。
- 验证服务功能与性能，逐步移出旧节点，保留旧快照若干天作为回滚保障。

8.

回滚与验证（应急预案）

- 回滚策略：保持旧实例与旧IP在可恢复状态，DNS TTL 低值能快速回退；若使用浮动IP，直接切回即可。
- 验证点：应用端口连通性、业务关键流程、数据库一致性校验（行数、checksum）、日志无异常。
- 安全清理：切换完成后在目标重建SSH密钥、更新防火墙规则、启用监控与告警。

9.

常见问题与优化建议

- 网络带宽不足：使用离线快递方式或在本地打包后向目标云上传（先上传镜像，再在目标解包）。
- 大型数据库：优先使用逻辑/物理复制减少停机窗口；对于超大库考虑分片迁移或先迁移冷数据。
- 自动化：将步骤写成脚本（镜像打包脚本、rsync 增量任务、数据库检查脚本）以降低人为失误。

10.

Q1：如何保证镜像在日本云导入后能启动（驱动/网络问题）？

- 回答：制作镜像前安装通用网络驱动（例如 cloud-init、通用网卡驱动），移除硬件相关配置（/etc/udev/rules.d/70-persistent-net.rules），并在目标先以单机维护模式启动检查 /var/log/boot.log。若云提供元数据服务，确保 cloud-init 启用以便获取 SSH key 与网络配置。

11.

Q2：零停机数据库迁移的“最终切换”需要停多久？

- 回答：理想情况下，如果复制延迟为0，最终切换时间只需几秒到数分钟（切换 VIP、更新负载均衡或将应用写入指向新主）。若无法做到零延迟，通常需短暂停写（几十秒到几分钟）以完成最后的 binlog/transaction position 切换并验证。

12.

Q3：迁移后如何验证数据与服务完全一致？

- 回答：执行多层验证：文件层可用 rsync --dry-run 比对差异；数据库层用 row counts、checksum（pt-table-checksum 或 pg_comparator）比对；应用层跑回归测试与关键业务流量压测，确认无异常后再彻底切换。

来源：日本最实用云服务器迁移攻略含镜像打包与数据同步零停机方案