Preparing MySQL dump command数据库能连接、备份文件能导出，是迁移过程中最容易被误当成“已经准备好”的两个信号。从旧服务器迁移到西雅图服务器前，应先验证三件事：目标数据库能否正确执行现有业务，备份能否在隔离环境完整恢复，切换失败后能否恢复服务且不丢失已经确认成功的写入。

开始前，需要确定源库与目标库版本、存储引擎、数据规模、可接受停机时间，以及负责停止写入和执行回滚的人员。下面以 Linux Bash 环境中的 MySQL、业务表主要使用 InnoDB、通过逻辑备份迁移单个业务库为例。涉及 MariaDB、其他数据库、非事务表或复制拓扑时，应另行核对对应的升级与恢复规则。

先把版本升级与服务器迁移拆开判断。

如果旧库版本仍受支持，通常可以先迁移到相同兼容版本，验证业务后再安排升级；这样出现问题时，更容易区分是环境变化还是版本变化。若旧版本已经不适合继续部署，则应根据数据库官方升级文档确认允许的升级路径，并在演练环境完成必要的中间版本转换。

逻辑导入成功只能说明数据和对象被目标库接受，不能证明业务语义保持一致。跨大版本时，SQL 默认行为、认证插件、保留字和排序规则都可能影响应用；直接复制数据目录还额外受物理格式与版本兼容性约束。

下面的语句可在源库和目标库分别执行，只读取配置，不修改业务数据。使用有相应查询权限的账户，并保存两端输出：

SELECT VERSION(), @@version_comment;

SHOW VARIABLES
WHERE Variable_name IN (
  'character_set_server',
  'collation_server',
  'sql_mode',
  'time_zone',
  'system_time_zone',
  'lower_case_table_names',
  'event_scheduler'
);

SHOW CREATE DATABASE app_db;

SELECT ENGINE, COUNT(*) AS table_count
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'app_db'
  AND TABLE_TYPE = 'BASE TABLE'
GROUP BY ENGINE;

将 app_db 替换为实际业务库名。重点检查以下差异：

服务器默认字符集相同，不代表每个字段相同；全局 SQL 模式相同，也不代表连接池没有覆盖会话设置。存在疑问时，应通过应用真实连接查询会话变量，并检查关键表的 SHOW CREATE TABLE 输出。

备份是否有效，要通过一次完整恢复证明。

恢复演练应使用西雅图服务器上的隔离实例，或与正式目标版本和配置一致的测试实例。该实例不能接入生产流量，也不能运行会发送通知、扣款或回写外部系统的任务。若备份包含数据库事件，应确认隔离实例的事件调度器关闭，并记录原设置，防止恢复后自动执行。

执行备份前，先确认两端空间、备份账户权限和客户端版本。导出工具需要兼容源库，导入工具需要适配目标库。数据库用户和授权应单独整理，在目标端按需重建，不要把旧库的 mysql 系统库直接覆盖到新版本。

下面的示例只读取源库，并在本机新建私有临时目录保存备份；会产生磁盘和数据库读取负载，宜先在低峰期演练。主机名、用户名和库名均需替换：

umask 077
backup_dir=$(mktemp -d) || exit 1

if mysqldump \
  -h OLD_DB_HOST -u backup_user -p \
  --single-transaction \
  --routines --events --triggers \
  --hex-blob --no-tablespaces \
  --set-gtid-purged=OFF \
  app_db > "$backup_dir/app_db.sql"
then
  sha256sum "$backup_dir/app_db.sql" \
    > "$backup_dir/app_db.sql.sha256"
  printf '备份目录：%s\n' "$backup_dir"
else
  printf '导出失败，当前文件不可作为恢复依据。\n' >&2
  exit 1
fi

这里的 --single-transaction 适用于 InnoDB 一致性快照，备份期间仍需禁止影响导出的 DDL。存在 MyISAM 等非事务表时，它不能保证所有表处于同一时间点，应另行安排停止写入或适用的锁定方案。

--set-gtid-purged=OFF 适用于本例不通过该备份建立 GTID 复制的场景。如果计划利用复制追平数据，需要另行设计 GTID、日志位点和增量衔接方式。校验和只用于判断文件传输前后是否一致，不能证明备份内容完整。

将备份通过受控加密通道传到隔离目标，比较源端与目标端校验和。随后按源库定义创建空业务库，确认目标没有需要保留的数据，再执行恢复：

mysql -h TEST_DB_HOST -u restore_user -p app_db \
  < /path/to/app_db.sql

此命令会在指定目标库执行建表和数据写入，备份中也可能包含删除同名表的语句。必须核对主机和库名，不能对现有生产库直接执行。测试恢复失败后，应保留错误信息，在重新建立的空测试库中重试，避免反复导入留下混合状态。

遇到不支持的排序规则或语法，应返回兼容性检查；遇到 DEFINER、权限或认证错误，应核对对象定义与账户。不要使用忽略错误的方式把恢复过程强行跑完。

恢复后的验收，要同时检查数据和业务行为。

首先确认导入进程正常结束、错误输出已检查，再核对基础表、视图、触发器、存储过程和事件清单。关键表可执行精确计数，但 InnoDB 的元数据行数通常是估计值，不能作为严格验收依据。

数据核对应尽量基于同一快照或停止写入后的同一时点，否则源库新增记录会干扰比较。至少保留三类证据：

• 结构证据：关键表字段、索引、默认值、外键和数据库对象一致。
• 数据证据：分段记录数、关键主键范围，以及金额、余额、状态分布等业务聚合结果一致。
• 运行证据：应用使用目标数据库完成新增、查询、更新、事务回滚、重复提交和时间处理测试。

大表逐表计数可能耗时较长，应先测量成本，再按稳定主键分段核验。少量抽样可以辅助发现问题，但不适合作为关键账务数据的唯一校验手段。

应用测试应使用与正式环境相同的驱动、连接参数和会话初始化配置，并隔离外部副作用。迁移后若出现查询变慢，应检查执行计划、索引和统计信息；只有真实业务路径通过，才能把“恢复成功”升级为“可以切换”。

用演练耗时确定停机窗口，再选择最后一次同步方式。

停机窗口至少包括：停止写入、处理在途事务、最终数据同步、数据核对、连接切换和业务验收。如果计划在窗口内失败回退，还必须预留回滚操作时间。

演练中应分别记录导出、传输、导入和验收耗时。若全量迁移无法满足停机要求，可以评估“先恢复全量备份，再通过兼容的日志或复制追平”的方式；前提是备份与日志位置能够正确衔接，日志保留覆盖整个迁移周期。

正式切换可按以下顺序连续执行：

1. 暂停应用写入、队列消费者、定时任务及人工脚本，等待在途事务结束，并检查是否仍有新增写入。
2. 完成最终备份与恢复，或等待增量同步达到明确记录的最终日志位置。不能只凭延迟指标显示为零判断完成。
3. 在同一截止时点核对关键数据，保存源库配置、备份位置、连接设置和验收结果。
4. 切换应用连接，重建连接池；若使用域名，还要检查缓存与旧连接是否仍指向源库。
5. 先保持业务写入关闭，完成只读验收，再执行受控写入测试；确认通过后，逐步恢复写入和任务。

源库应继续保留，但必须阻止业务写入。可通过应用停写、连接隔离或经演练的只读机制实现，并验证高权限脚本也没有绕过限制。新旧数据库同时接收独立写入，会显著增加后续回滚难度。

回滚方案必须区分目标库是否已经产生新数据。

目标库尚未接收业务写入时，回滚相对直接：关闭目标入口，将连接恢复到仍保持完整状态的源库，重建连接池，验证业务后恢复旧端任务。演练时应实际走一遍连接回切，确认旧配置、凭据和服务仍可用。

目标库已经接收写入后，直接切回旧库会丢失切换后的变化。此时应先暂停新写入，保存目标库备份及相关日志，再根据演练通过的方案执行反向同步、差异补写或业务补偿。跨版本环境不能默认支持反向复制，也不能把新版数据目录直接交给旧版本启动。

如果没有可靠的数据回流方案，就应将无数据损失的快速回退边界设在正式开放写入之前。受控写入测试产生的数据也要纳入清理或补偿范围；一旦进入正式写入阶段，应优先评估在目标库修复，或重新迁移回旧环境所需的停机时间。

迁移前应写清触发条件，例如关键数据不一致、核心事务失败、权限异常无法在剩余窗口内修复，并约定停止排查、开始回滚的最晚时间。旧服务器保留多久，则应依据业务验收、备份保留策略和回滚需求确定。

最后容易遗漏的是两处：旧连接是否仍在写源库，新端定时任务是否重复运行。 西雅图服务器开始承载业务后，还应再完成一次新环境备份与隔离恢复，确认备份任务、恢复权限和所需日志已经随迁移一并接续。