服务器迁移全过程记录

引言

大家好，今天来聊聊我最近完成的一次服务器迁移项目。说实话，之前一直用的阿里云，这次因为业务需求和成本考虑，决定把整个服务迁移到腾讯云。整个过程前前后后折腾了将近两周，总算圆满完成。今天就把整个迁移过程整理一下，分享给有需要的朋友，希望能给正在考虑迁移服务器的同学一些参考。

一、迁移前的准备工作

做任何事情之前，充分的准备工作都是成功的关键。服务器迁移更是如此，一旦出了问题，影响的可就不是一个人了。

首先，我花了大概三天时间把现有服务全部梳理了一遍。我们当时跑的主要是这几个业务：

- 一个基于 Node.js 的后端 API 服务

- MySQL 数据库

- Redis 缓存

- Nginx 作为反向代理

- 几个静态网站

梳理清楚之后，我做了详细的清单，包括每个服务的端口、依赖关系、数据量大小等。这里有个小建议，大家可以用 docker ps 和 netstat -tlnp 这些命令先把现有服务情况摸清楚。

# 查看所有运行中的容器
docker ps -a

查看端口占用情况
netstat -tlnp

查看磁盘使用情况
df -h

另外特别重要的是评估新服务器的规格。我根据现有服务器的资源使用情况，选了配置相近的腾讯云服务器，还特意留了 30% 的冗余，以防万一。建议大家迁移前看看监控数据，CPU、内存、磁盘IO这些指标都很关键。

二、数据备份与验证

备份这个环节真的是怎么强调都不为过。我给自己定了个原则：所有数据至少备份三份，不同位置。虽然听起来有点夸张，但真要出问题的时候你就知道有多重要了。

数据库备份我用的是 mysqldump，这里给个简单的命令示例：

# 完整备份数据库
mysqldump -u root -p --all-databases > all_backup_$(date +%Y%m%d).sql

单库备份
mysqldump -u root -p your_database > your_database_backup.sql

Redis 的数据我直接用的 BGSAVE 命令触发后台保存，然后复制 dump.rdb 文件。对于生产环境，建议大家用 Redis 的持久化文件或者配置主从复制会更稳妥一些。

除了数据库，别忘了备份 Nginx 配置文件、SSL 证书、各种环境变量文件等等。我当时专门建了个 migration 目录，把所有配置文件都放进去，打包压缩后上传到了对象存储和本地电脑各存了一份。

备份完成后一定要验证！我第一次备份完忘了验证，后来迁移的时候才发现文件不完整，白白耽误了时间。建议用 md5sum 或 sha256sum 生成校验和，备份和恢复后都校验一下。

三、服务迁移步骤

正式迁移那天是周六凌晨，选这个时间主要是考虑业务低峰期。虽然我们服务可以接受短暂不可用，但能少影响用户就少影响嘛。

3.1 系统环境初始化

新服务器到手后先别急着装应用，把系统环境调教好再说。我主要做了这些：

# 更新系统
sudo apt update && sudo apt upgrade -y

安装常用工具
sudo apt install -y curl wget vim git htop net-tools

配置时区
sudo timedatectl set-timezone Asia/Shanghai

腾讯云默认的安全组规则比较保守，记得提前开放需要的端口。我当时因为这个吃了亏，防火墙和云安全组都开放了 3306 端口，结果安全组默认没开，排查了半天才发现。

3.2 应用服务部署

应用部署我用的是 Docker，不得不说 Docker 真的是迁移神器。只要把镜像和 docker-compose.yml 文件复制过来，大部分情况都能直接跑起来。

# docker-compose.yml 示例
version: '3.8'
services:
app:
image: your-app-image:latest
ports:
- "3000:3000"
environment:
- NODE_ENV=production
- DB_HOST=db
depends_on:
- db
- redis

db:
image: mysql:8.0
volumes:
- mysql_data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=your_password

redis:
image: redis:7-alpine
volumes:
- redis_data:/data

这里有个小技巧，迁移的时候建议先在后台跑，不要加 -d 参数，这样能看到实时的日志输出，有什么问题能第一时间发现。

3.3 数据迁移

数据库迁移我用的是最简单直接的方法：先在旧服务器导出，然后新服务器导入。因为我们的数据量不大（大概几个G），整个过程大概用了二十多分钟。

# 旧服务器导出
mysqldump -u root -p your_database | gzip > backup.sql.gz

传输到新服务器
scp backup.sql.gz user@new_server_ip:/tmp/

新服务器导入
gunzip < /tmp/backup.sql.gz | mysql -u root -p your_database

如果数据量特别大的话，可以考虑用主从复制或者第三方工具比如 pt-table-checksum 来做增量同步，这个要根据实际情况来选择。

四、DNS 切换与验证

服务都部署好了，接下来就是最关键的 DNS 切换了。这一步直接关系到用户能不能正常访问。

我用的是阿里云解析迁移到腾讯云 DNSPod，说实话流程比想象中简单：

1. 在 DNSPod 添加域名

2. 修改域名的 NS 记录，指向 DNSPod 的 nameserver

3. 等待全球 DNS 生效（这个过程可能需要几分钟到 48 小时）

为了减少切换期间的影响，我还做了这些准备：

- 提前把 SSL 证书部署到新服务器

- 在 Nginx 里配置好域名和 upstream

- 用 curl 多次测试确保服务正常

# 测试 API 响应
curl -I https://your-domain.com/api/health

测试 SSL 证书
curl -I -k https://your-domain.com

DNS 切换后我整整盯了两天监控，随时准备回滚。好在一切顺利，没有出现大的问题。这里提醒大家，DNS 切换期间可能会出现部分用户访问旧服务器、部分访问新服务器的情况，业务逻辑上要做好兼容。

五、迁移后的优化与监控

服务跑起来不代表就完事了，后面的优化和监控同样重要。

我主要做了以下几件事：

1. 配置监控告警：用腾讯云的云监控配置了 CPU、内存、磁盘、流量等基础指标的告警，阈值设的相对保守一些，宁可误报也不能漏报。

2. 日志收集：把各个服务的日志统一收集到腾讯云日志服务，方便排查问题。

3. 性能基线记录：记录下迁移后各个服务的性能指标，后面如果出现异常可以有个对比。

4. 备份策略：重新配置了自动备份，这次用的是腾讯云的云数据库自动备份功能，比之前手动备份靠谱多了。

另外我还发现腾讯云的一些小坑，比如他们默认的云服务器安全组规则比较严格，开放端口需要手动配置。还有他们的 CDN 加速和对象存储配合使用效果不错，如果有静态资源建议开启 CDN。

总结

整个迁移过程前前后后花了差不多两周时间，虽然过程中遇到了一些小问题，但最终还是有惊无险地完成了。总结下来几点经验：

1. 充分准备：迁移前把所有细节都梳理清楚，磨刀不误砍柴工

2. 重视备份：数据备份怎么强调都不为过

3. 小步快跑：可以先迁移非核心服务，积累经验后再迁移关键业务

4. 监控到位：迁移后密切监控，有问题及时发现和处理

5. 保持回滚能力：任何时候都要保留回滚的可能

服务器迁移虽然听起来很复杂，但只要准备充分、步骤清晰，其实也没那么可怕。希望我的这次经历能给大家一些帮助。如果有什么问题，欢迎在评论区交流！