简介这份《应用和数据迁移方案》文档面向运维工程师、DBA及系统架构人员聚焦业务系统升级改造中如何在有限停机窗口内安全完成应用与数据库迁移这一核心难题。文档围绕数据库迁移处理思路、迁移方法选型、工程实施计划与应急策略展开重点讲解基于Dataguard技术实现热备份与主备归档日志同步将switchover切换时间控制在10分钟以内并对比export/import、Migrate脚本与DBUA等升级方式的优劣。资源包内含1个doc文件大小约1.11MB结构完整、条理清晰涵盖预备、测试、数据库迁移、数据库升级及迁移后监控备份等阶段并附实施计划表格与异常回退方案。目前已有587人学习下载适合需要制定迁移方案、评估停机风险或编写实施计划的技术人员参考借鉴。1. 应用和数据迁移方案从一台服务器搬到另一台到底要拆成几步上周帮一个做 SaaS 的朋友做机房搬迁他原话是「不就是把代码打包、数据库导出再导入吗一个周末搞定」。结果周六凌晨两点他打电话说新环境里定时任务全挂了原因是老服务器上有个 cron 脚本根本不在代码仓库里是当年运维手敲上去的。这就是「应用和数据迁移方案」最真实的模样——它从来不是一次文件拷贝而是一次对系统隐性依赖的全面盘点。这个标题背后要解决的核心问题是如何在不丢数据、不停服或尽量少停服的前提下把一套正在运行的应用连同它的数据、配置、依赖、定时任务、证书、环境变量完整搬到新环境并验证可用。适合谁看正在做上云、机房搬迁、容器化改造、数据库版本升级的开发和运维。下面我按自己实际做过几次迁移的顺序把这件事拆开讲清楚。2. 迁移前先做依赖盘点漏掉一个隐性依赖就够你回滚2.1 为什么「代码能跑」不等于「迁移能成」大部分人评估迁移工作量时看的是代码仓库和数据库大小但真正让迁移翻车的是那些不在仓库里的东西。我一般把依赖分成四层来看第一层是应用代码和它的语言级依赖比如 requirements.txt、package.json、pom.xml这层最容易被想到第二层是运行时环境包括 JDK/Python/Node 版本、系统库libssl、glibc、时区设置、locale第三层是外部资源数据库、Redis、消息队列、对象存储、第三方 API 的密钥第四层是运维侧的东西cron 定时任务、systemd 服务单元、Nginx 配置、SSL 证书、日志切割脚本、开机自启项。第三层和第四层是重灾区。我见过最典型的翻车是应用迁移过去了数据库也迁了但 Redis 里存的是 session新 Redis 是空的用户全部被踢下线而且因为老 Redis 没设持久化重启后数据直接没了。还有一次是 SSL 证书只迁了 crt 没迁中间证书链浏览器报证书不完整排查了半天。所以盘点阶段的目标不是「列个清单」而是「让新环境能独立跑起来且行为和旧环境一致」。判断标准很简单把旧服务器关机新服务器能不能扛住全部流量。做不到就说明还有隐性依赖没找出来。2.2 用脚本把隐性依赖挖出来手工列清单一定会漏我一般用几条命令把系统层面的依赖扫一遍。下面这段 bash 是我常用的盘点脚本跑在旧服务器上#!/bin/bash # 迁移前依赖盘点脚本在旧服务器上执行 echo 1. 监听端口与对应进程 ss -tlnp echo 2. 定时任务系统级 用户级 cat /etc/crontab ls -l /etc/cron.d/ /etc/cron.daily/ 2/dev/null for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u $u 2/dev/null | grep -v ^# | sed s/^/[$u] / done echo 3. systemd 自定义服务 systemctl list-unit-files --typeservice --stateenabled | grep -v -E systemd|dbus|network echo 4. 环境变量从运行中的进程读 for pid in $(pgrep -f java|python|node); do echo --- PID $pid --- tr \0 \n /proc/$pid/environ | grep -iE key|secret|token|url|host|pass done echo 5. 已安装的系统包 if command -v dpkg /dev/null; then dpkg -l | awk {print $2}; elif command -v rpm /dev/null; then rpm -qa; fi这段脚本的逻辑是端口告诉你应用实际依赖哪些服务cron 和 systemd 告诉你哪些任务不在代码里从/proc/$pid/environ读环境变量是最可靠的方式因为.bashrc里 export 的变量和实际进程拿到的可能不一致系统包列表用来在新机器上对齐运行库版本。参数上要注意两点ss -tlnp需要 root 才能看到进程名普通用户只能看到端口/proc/$pid/environ只有同用户或 root 能读读不到就说明权限不够别以为是变量没设。提示盘点结果建议直接存成一个文件带进迁移工单后面每一步都对着它打勾比凭记忆靠谱。3. 数据迁移怎么做全量 增量 校验三步走3.1 停机窗口怎么算全量和增量怎么配合数据迁移的核心矛盾是「数据量大」和「停机时间短」。直接 mysqldump 全量导出再导入100G 的库可能要几个小时业务停不起。我一般用「全量 增量」的方式先做一次全量快照同时记录 binlog 位置全量导入新库后再把这段时间的增量 binlog 追上去最后短暂停写做一次切换。以 MySQL 为例全量导出用 mysqldump 或 xtrabackup。数据量小于 50G 用 mysqldump 就够超过就用 xtrabackup 做物理备份速度快很多。下面是一次典型的全量导出加 binlog 位点记录# 1. 记录当前 binlog 位点作为增量起点 mysql -e SHOW MASTER STATUS\G | tee /tmp/binlog_pos.txt # 2. 全量导出单库含存储过程、触发器、事件 mysqldump -h old_host -u root -p \ --single-transaction \ --master-data2 \ --routines --triggers --events \ --default-character-setutf8mb4 \ your_db /tmp/your_db_full.sql # 3. 导入新库 mysql -h new_host -u root -p your_db /tmp/your_db_full.sql--single-transaction保证 InnoDB 表导出时的一致性快照不锁表--master-data2会把 binlog 位点以注释形式写进 SQL 文件方便后面追增量--routines --triggers --events这三个必须加否则存储过程、触发器、定时事件全丢这是血泪经验。增量追平用 mysqlbinlog 或者直接配主从。如果只是临时追一段用 mysqlbinlog 指定 start-position 导出成 SQL 再导入新库mysqlbinlog --start-position12345678 \ --databaseyour_db \ /var/lib/mysql/mysql-bin.000123 /tmp/incr.sql mysql -h new_host -u root -p your_db /tmp/incr.sql3.2 迁移后怎么校验数据没丢没串导入完成不代表数据对。我一般做三层校验行数校验、关键字段校验、业务校验。行数校验最简单但要注意 InnoDB 的COUNT(*)在大表上很慢可以用information_schema.tables里的近似值先粗筛再对核心表精确 count。-- 第一层核心表行数对比新旧库分别执行 SELECT orders AS tbl, COUNT(*) FROM orders UNION ALL SELECT users, COUNT(*) FROM users UNION ALL SELECT payments, COUNT(*) FROM payments; -- 第二层关键字段聚合校验比行数更能发现内容错位 SELECT COUNT(*) AS cnt, SUM(amount) AS total_amount, MD5(GROUP_CONCAT(id ORDER BY id)) AS id_fingerprint FROM orders WHERE created_at 2024-01-01;id_fingerprint这个做法是把主键排序后拼起来算 MD5新旧库结果一致基本能确认数据没串。注意GROUP_CONCAT有长度限制默认 1024 字节大表要先SET SESSION group_concat_max_len 100000000;否则指纹会被截断导致误判。第三层业务校验是抽样跑几条真实查询比如「查某个用户最近 10 笔订单」看结果和旧库是否一致。这一步不能省因为前两层只能证明数据在不能证明关联关系对。注意字符集和排序规则一定要对齐。旧库是 utf8mb4_general_ci新库建成 utf8mb4_0900_ai_ci某些查询的排序结果会变业务如果依赖排序就会出问题。4. 应用迁移怎么落地配置、启动、流量切换的顺序4.1 配置外置化别把环境差异写死在代码里应用迁移最容易出问题的地方是配置。老环境里数据库地址、Redis 地址、密钥可能硬编码在代码或配置文件里迁到新环境要么改代码要么改配置。我一般要求迁移前先把配置外置化所有环境相关的值走环境变量或配置中心代码里只留默认值和读取逻辑。以 Spring Boot 为例application.yml里这样写spring: datasource: url: ${DB_URL:jdbc:mysql://localhost:3306/app} username: ${DB_USER:root} password: ${DB_PASSWORD:} redis: host: ${REDIS_HOST:localhost} port: ${REDIS_PORT:6379}这样新环境只要设好环境变量就能跑不用改代码。Node.js 用 dotenvPython 用 os.environ思路一样。关键点是默认值只用于本地开发生产环境必须显式设置否则漏设一个变量应用会静默连到错误的地方这种问题最难查。4.2 启动顺序和健康检查先起依赖再起应用新环境启动应用前先确认依赖服务都就绪。我一般按这个顺序数据库 → 缓存 → 消息队列 → 应用 → 网关。每起一个都做健康检查别一股脑全起来然后看日志猜哪个没起来。# 数据库就绪检查 until mysqladmin ping -h new_host -u root -p$DB_PASSWORD --silent; do echo waiting for mysql...; sleep 2 done # Redis 就绪检查 until redis-cli -h new_host ping | grep -q PONG; do echo waiting for redis...; sleep 2 done # 应用启动后做一次本地健康检查 curl -sf http://127.0.0.1:8080/actuator/health || echo app health check failed健康检查通过后再切流量。流量切换我一般用 DNS 或负载均衡权重先切 1% 观察再逐步放大。切之前把旧环境保持可回滚状态至少保留 24 小时别急着释放资源。4.3 回滚方案迁移前就要想好怎么退回去回滚方案不是迁移失败才想而是迁移前就要准备好。核心是两点数据能不能回退流量能不能切回。数据方面如果新库已经写入了一段时间回退时要把这部分增量同步回旧库所以迁移期间旧库最好保持可写或者记录好增量。流量方面DNS 切换有 TTL 缓存切回不是瞬间生效所以更稳的做法是在负载均衡层切权重秒级生效。我一般会准备一个回滚脚本把流量权重切回旧环境、停掉新环境应用、把新库增量导回旧库。这个脚本迁移前写好迁移时不用但心里有底。5. 迁移避坑清单这 5 个坑我踩过至少 3 个5.1 时区不一致导致定时任务错乱现象应用迁到新服务器后定时任务执行时间比预期早了或晚了 8 小时。原因旧服务器是 CST东八区新服务器是 UTC应用读系统时区做调度。解决迁移前统一时区timedatectl set-timezone Asia/Shanghai同时检查应用配置里有没有硬编码时区数据库连接串加上serverTimezoneAsia/Shanghai。5.2 文件存储路径写死导致上传失败现象用户上传头像报错日志显示找不到目录。原因代码里写死了/data/upload新服务器没建这个目录或者挂载的磁盘没挂上。解决迁移前把文件存储路径也纳入盘点新环境提前建好目录并设好权限如果用了对象存储要确认密钥和 bucket 配置。5.3 数据库字符集不一致导致乱码现象迁移后部分中文显示成问号或乱码。原因旧库是 latin1新库建成 utf8或者导出时没指定字符集。解决导出时加--default-character-setutf8mb4导入前确认新库字符集一致已经乱码的数据要用CONVERT(BINARY CONVERT(col USING latin1) USING utf8mb4)修复但修复前先备份。5.4 连接数配置没调导致新库被打满现象迁移后应用频繁报「too many connections」。原因新库的max_connections默认值比旧库小或者应用连接池配置没跟着调。解决迁移前对比新旧库的max_connections、wait_timeout等参数应用侧连接池的 maxActive 要小于数据库 max_connections 减去预留连接数。5.5 证书和密钥没迁导致 HTTPS 和第三方调用失败现象网站提示证书无效或者调用第三方支付接口报签名错误。原因SSL 证书只迁了部分文件或者 API 密钥在新环境没配置。解决把证书目录整个打包迁移包括中间证书链API 密钥通过环境变量或配置中心注入迁移后逐个验证第三方接口连通性。6. 迁移后的验证技巧用影子流量和差异对比确认行为一致迁移完成、流量切过去不代表事情结束。我一般会做一轮「行为一致性验证」核心思路是让新旧环境同时处理相同请求对比结果。具体做法有两种一种是在负载均衡层把同一用户的请求同时打到新旧环境影子流量对比响应另一种是迁移后跑一批回归用例覆盖核心业务路径。影子流量用 Nginx 的 mirror 模块就能做配置如下location /api/ { mirror /mirror; proxy_pass http://new_backend; } location /mirror { internal; proxy_pass http://old_backend$request_uri; }这段配置的意思是正常请求打到新环境同时复制一份打到旧环境。然后对比两边日志里的响应状态码和关键字段。注意 mirror 请求是异步的不影响主请求响应时间但会放大旧环境的负载所以只适合短时间验证别长期开着。差异对比我一般写个小脚本把新旧环境的访问日志按请求 ID 关联找出响应不一致的请求import re from collections import defaultdict def parse_log(path): # 假设日志格式request_id status response_hash result {} with open(path) as f: for line in f: m re.match(r(\S)\s(\d)\s(\S), line) if m: result[m.group(1)] (m.group(2), m.group(3)) return result old parse_log(old_access.log) new parse_log(new_access.log) diff [rid for rid in old if rid in new and old[rid] ! new[rid]] print(f不一致请求数: {len(diff)}) for rid in diff[:20]: print(rid, old[rid], new[rid])这个脚本的关键是请求 ID 要能贯穿新旧环境一般在网关层生成并透传。跑完对比后不一致的请求逐个分析是数据问题还是配置问题定位到根因再决定是否回滚。最后说个我自己的习惯每次迁移完我会把这次踩的坑和解决办法追加到一个migration_notes.md里下次迁移前先翻一遍。迁移这件事经验比工具重要而经验就是一次次翻车攒出来的。希望帮到你。本文还有配套的精品资源点击获取