内地服务器迁移香港服务器：系统环境、数据库与DNS切换全流程

迁移的目标，是让香港服务器接管原有网站或应用，同时保持数据库、上传文件、登录状态和外部接口的一致性。真正需要控制的风险，不只是服务能否启动，而是切换期间是否出现双边写入、数据遗漏、部分用户仍访问旧服务器，以及新服务器接管后还能否安全回退。

这项变更应按“现状核对、备份与预迁移、冻结写入、最终同步、DNS 切换、验证观察”的顺序推进。生产迁移负责人需要把系统环境迁移、数据库迁移与流量切换分开验收，并明确一条边界：新服务器开始承接业务写入之前，可以按预案退回旧环境；开始承接写入之后，回滚必须先处理新增数据，不能只把 DNS 改回去。

面向内地业务迁移香港的部署需求，A5数据提供香港物理服务器租用资源，覆盖入门建站、Xeon Gold与AMD EPYC等配置，并配备SSD或NVMe存储及CN2、国际带宽等线路方案，可为企业网站、业务后台、数据库和接口服务提供相应的计算、存储与网络基础。针对数据规模较大或访问结构更复杂的业务，A5数据还提供存储型、多IP及不同带宽配置，便于将新环境的硬件资源与业务架构一并规划。

一、现状核对：先确认迁移范围与兼容边界

明确哪些内容必须一起迁走

迁移前应形成一份可核对的资产清单，而不是仅记录网站目录和数据库名称。

不要把 Redis 一律当成可丢弃缓存。如果它保存购物车、会话、任务队列或业务锁，就需要单独制定迁移和恢复方案。队列还要记录未消费消息及处理中任务，避免旧、新消费者重复执行。

对于容器应用，应记录镜像版本或摘要、环境变量来源和持久化卷。复制镜像并不等于复制数据库和上传文件，也不要在迁移当天顺带更新基础镜像。

先保持兼容，再考虑升级

跨地域迁移已经包含网络、地址、依赖和流量入口变化，不宜同时升级操作系统大版本、应用框架和数据库。

优先采用“目标环境先保持兼容，迁移稳定后再独立升级”的路径。重点检查：

• x86 与 ARM 架构差异，以及原生扩展是否有对应构建。
• PHP、Java、Node.js、Python 等运行时与扩展版本。
• MySQL 与 MariaDB 的差异，不能把两者视为可直接互换。
• 数据库排序规则、SQL 模式、认证插件和时区。
• 文件路径大小写、软链接、计划任务中的绝对路径。
• 数据库驱动、连接加密要求及证书信任链。

以下核验命令适用于 Linux 环境；未安装的组件可以跳过。文中的数据库示例以 MySQL 8.0 为对象，不能直接套用于其他数据库版本。

cat /etc/os-release
uname -m
timedatectl
nginx -V
mysql --version

数据库内部再检查实际服务端版本与配置，不能仅看客户端版本：

SELECT VERSION();
SELECT @@character_set_server, @@collation_server, @@sql_mode;
SELECT @@global.time_zone, @@session.time_zone;

SELECT ENGINE, COUNT(*) AS table_count
FROM information_schema.tables
WHERE table_schema = 'app_main'
GROUP BY ENGINE;

核对内地到香港后的连接变化

原来通过内网连接的数据库、对象存储或接口，迁移后不一定还能使用同一地址。香港服务器访问留在内地的依赖，也可能增加网络往返时间，因此应验证业务链路，而不是只测试首页。

同时确认新出口 IP 是否需要加入支付平台、合作接口、数据库或管理系统白名单。防火墙调整应记录原规则，仅开放必要来源和端口，保留管理连接与控制台恢复入口；不应为方便迁移而把数据库直接开放给所有公网来源。

香港部署不意味着可以忽略业务许可、数据跨境、个人信息保护或第三方服务要求。涉及敏感数据时，应先确认迁移、备份保存和访问授权是否符合适用要求；保留内地 CDN 等服务时，也需分别核对其接入条件。

二、变更准备：先建立备份、窗口与回退能力

备份必须能够恢复

变更前至少保存数据库备份、应用文件、上传目录、配置文件及任务清单，并注明生成时间、软件版本和恢复方法。备份应保留在独立于源服务器的位置，敏感配置与数据库文件应限制访问并加密存储。

备份验收的标准不是“文件已经生成”，而是“在隔离环境能够恢复，并通过必要的数据校验”。 至少完成一次试恢复，核对表数量、关键记录、存储过程、触发器和数据库事件，同时确认恢复耗时。

云盘快照可以增加一层保护，但快照是否包含一致的数据库状态，取决于其机制及创建方式，不能自动等同于可恢复的逻辑备份。

估算停机时间，不把传输时间当成固定值

停机窗口应覆盖：

写入冻结 + 最终数据同步 + 恢复与校验 + 流量切换操作 + 放行前检查 + 预留时间。

例如，按十进制口径计算，60 GB 数据以有效吞吐 120 Mbps 传输：

• 数据量换算：60 × 1000 × 8 = 480,000 Mb。
• 理论传输时间：480,000 ÷ 120 = 4,000 秒，约 66.7 分钟。
• 若仅为传输环节增加约 20%～40% 余量，可估算为约 80～93 分钟。

这里的 120 Mbps 是可持续的有效吞吐，不是带宽套餐标称值；估算也没有包含数据库导出、导入和验证时间。

如果完整导出恢复明显超出可接受窗口，应提前采用经过演练的增量同步或数据库复制方案。复制链路需要核对快照与日志位置、日志保留、复制错误及追平状态，不能临时搭建后仅凭“延迟显示为零”就切换。

提前处理 DNS 与入口

可以将待切换记录的 TTL 提前降至较短值，例如 300 秒，但应在切换前留出至少覆盖原 TTL 的时间。原记录 TTL 为 3600 秒时，临近切换才改成 300 秒，不会让已缓存的旧记录立即失效。

逐项确认：

• 网站域名、API 域名、上传域名是否分别使用 A 或 AAAA 记录。
• 香港服务器是否支持计划保留的 IPv6 入口。
• 域名是否经过 CDN，实际需要修改的是 DNS 还是 CDN 源站。
• TLS 证书是否覆盖所有域名，续期验证方式是否仍可用。
• 邮件是否仍由原系统提供，避免误改 MX 及相关邮件记录。

DNS 记录切换和权威 DNS 服务迁移是两类变更，不建议同窗口执行。若存在多个入口，应按入口分别记录旧值、新值和恢复方式。

写清楚操作顺序与决策责任

变更单至少明确操作负责人、验证负责人、停止条件、回滚负责人和可联系时间。保留旧服务器、旧 DNS 记录、配置备份和管理入口，不要在切换后立即释放旧资源。

提前决定旧入口在 DNS 缓存尚未失效时如何处理：可以显示维护提示，也可以在验证充分的条件下转发到新入口，但不能继续连接旧数据库独立写入。转发方案还需检查连接超时、上传大小、客户端地址传递和回源路径，避免形成循环。

三、分步实施：先预迁移，再冻结写入完成交接

第一步：构建兼容的香港环境

先安装已经确认的运行时和依赖，恢复应用配置，但暂不开放公网业务写入。数据库、缓存等内部服务只允许必要来源连接，管理入口采用受限访问。

复制配置时，应替换或核验监听地址、数据库地址、缓存地址、外部接口凭据引用和日志路径，不要把旧服务器 IP 或内网地址原样带过去。目标服务器的定时任务、队列消费者及数据库事件先保持禁用，防止迁移演练期间产生真实业务副作用。

Nginx 配置变更前应保存原文件。以下命令适用于已安装 Nginx、使用 systemd 的 Linux 环境：

sudo nginx -t

检查失败就停止，不执行 reload；检查通过后，才在批准窗口内执行：

sudo systemctl reload nginx

如果重载后的验证失败，应恢复原配置，重新检查后再重载。不要在同一步骤中同时修改应用配置和大量系统参数。

第二步：预复制应用与文件

先将应用程序和大部分持久化文件复制到新服务器，减少停机窗口内的传输量。下面仅示例一个文件目录，使用前需替换地址、账号和路径：

rsync -a --no-owner --no-group --dry-run \
  /srv/www/shop/uploads/ \
  deploy@NEW_SERVER:/srv/www/shop/uploads/

确认预览的源、目标和尾部斜杠含义后，再执行实际复制：

rsync -a --no-owner --no-group \
  /srv/www/shop/uploads/ \
  deploy@NEW_SERVER:/srv/www/shop/uploads/

示例避免自动照搬源端属主，但目标端仍需按应用账号核对目录权限和文件模式。不要为了消除报错而将目录权限扩大为任意用户可写。

这里没有使用 --delete。因此它不会清理目标端多余文件；如业务允许文件删除，应在最终同步前比较清单，备份目标目录，并对删除范围单独审批。旧版本程序文件也可能造成异常，应用代码更适合按确定的发布包部署，而不是持续覆盖混合目录。

第三步：演练数据库导出与恢复

对于以 InnoDB 为主的 MySQL 8.0 数据库，可使用逻辑导出完成初次演练。执行前核对剩余磁盘空间、导出账号权限与生产负载影响：

umask 077
SNAP="/srv/backup/app_main_$(date +%Y%m%d_%H%M%S).sql"

mysqldump -u backup_operator -p \
  --single-transaction \
  --routines --events --triggers \
  --hex-blob --no-tablespaces \
  --set-gtid-purged=OFF \
  app_main > "$SNAP"

dump_status=$?
if [ "$dump_status" -ne 0 ] || [ ! -s "$SNAP" ]; then
  echo "导出失败或文件为空，停止后续操作"
  exit 1
fi

sha256sum "$SNAP"

备份目录应预先建立并限制访问，密码通过交互输入，不写入命令行。文件非空和校验和只能作为文件检查，不能替代试恢复。

这组参数有明确边界：

• --single-transaction 适用于事务表的一致性读取，不能保证非事务表的一致性。
• 导出期间应避免 DDL 变更；大型导出还可能增加磁盘和数据库负担。
• 存储过程、触发器与事件需要核对 DEFINER 及目标账号权限。
• --set-gtid-purged=OFF 用于本例的独立逻辑恢复，不代表建立 GTID 复制的通用步骤。
• 数据库账号、授权与其他库中的依赖，需要另行核对。

导入前，在目标服务器创建字符集和排序规则与源端匹配的空数据库，并确认其中没有待保留数据。下面的导入会创建对象、写入数据，某些转储还包含删除已有表的语句；误选目标库可能破坏数据。应先备份目标已有状态，并由第二人核对连接地址和数据库名称。

mysql -h NEW_DB_HOST -u restore_operator -p \
  app_main < /srv/backup/app_main_YYYYMMDD_HHMMSS.sql

只通过已配置加密和来源限制的迁移连接执行，不为导入临时开放数据库公网访问。目标库在恢复及验证期间应隔离业务写入，并保持事件调度禁用。

恢复失败时不要在半导入状态直接放行应用。保留错误输出，修复权限或兼容问题，再按审批流程重建空目标库重新恢复。

第四步：不改 DNS，先验证新环境

可通过 curl --resolve 将指定域名临时解析到香港服务器，保留正确的 Host 和 TLS 域名校验：

curl --resolve www.example.com:443:203.0.113.10 \
  -I https://www.example.com/

域名和 IP 均为示例，需替换为实际值。如果证书、连接或响应异常，应先定位入口问题，不要使用关闭证书验证的方式掩盖生产配置错误。

进一步验证登录、查询、上传、下载和关键事务路径。演练环境不得触发真实扣款、短信或正式通知；确需业务验收时，使用批准的测试账号与测试通道。新环境出现未解决的关键错误，就不进入正式窗口。

第五步：冻结全部写入源，完成最终同步

维护页面只限制了部分用户入口，并不代表数据库已经停止变化。正式窗口应按以下顺序执行：

1. 对外进入维护状态，限制会改变业务数据的操作。
2. 停止旧环境定时任务、队列消费者、后台批处理和数据库事件。
3. 按预案等待在途事务结束，处理外部回调与未完成任务。
4. 确认旧数据库和上传目录不再发生业务写入。
5. 执行最终文件同步，并完成最终数据库导出恢复或复制追平。
6. 记录数据交接时间、备份文件、校验结果及尚未完成的业务。

支付等回调不能简单丢弃，应预先确认重试、补单和幂等处理机制。需要缓冲接收时，也必须明确缓冲数据由哪一端负责落库。

增量复制方案还应记录明确的交接位置，确认目标已应用截至冻结点的全部变更，并将旧端约束为不可写。最终同步后，至少检查关键表记录、近期订单或流水、上传文件与数据库引用的一致性。

第六步：切换入口，只放行一个写入端

先确认香港服务器的应用、证书、数据库连接和依赖均通过验收，再修改相应 A/AAAA 记录或 CDN 源站。只替换 IPv4、遗漏旧 IPv6，可能导致部分访问继续落到旧服务器。

切换顺序应保证：

1. 旧环境已经禁止独立业务写入。
2. 新环境完成最终一致性检查。
3. 流量入口切向新环境。
4. 按审批结果放行新端写入，启用新端任务与消费者。
5. 旧入口维持维护提示，或按已验证方案导向新环境。

任务和消费者启用时还应确认锁、任务归属及幂等性。迁移期间重复发送通知或重复处理订单，同样属于数据一致性问题。

四、验证观察：确认请求到达、业务可用与数据完整

按由外到内的顺序验收

首先检查 DNS 与入口，再检查 HTTP、应用和数据库，避免把解析未更新误判为数据库故障。

dig www.example.com A
dig www.example.com AAAA
curl -I https://www.example.com/

不同递归解析器可能返回不同结果，单次查询新 IP 不能证明所有用户已切换。应结合多地访问结果、CDN 回源状态和旧服务器访问日志判断迁移进度。

验收可分为三层：

首页返回 200 不代表迁移成功。应使用批准的测试账号覆盖关键流程，记录产生的数据和清理方式；涉及资金的流程必须使用测试渠道或受控验收方案。

数据库校验也不宜只比较记录数。可以结合冻结点前后的记录、业务金额汇总、最新编号以及抽样内容核对。计数或金额查询可能有负载，应提前演练并控制范围。

区分常见失败，避免继续扩大变更

• 直连新 IP 正常，域名访问异常：优先检查 DNS 缓存、CDN 回源、AAAA 记录和站点绑定。
• 登录持续失效：检查会话存储、应用密钥、Cookie 域与安全属性，以及时间同步。
• 导入报排序规则或权限错误：停止恢复，确认版本、排序规则和对象定义，不直接批量替换未知内容。
• 接口超时或被拒绝：检查新出口 IP 白名单、网络可达性与服务端限制。
• 后台任务重复执行：先停止重复的消费者或调度端，保留执行记录，再按幂等规则处理。
• 数据库出现两端新增记录：立即冻结相关写入，不能继续等待 DNS 缓存自然消失。

设置明确观察窗口

可采用“切换后前 30 分钟持续值守、前 2 小时密集观察、至少覆盖一个完整业务高峰和一个定时任务周期”的安排。对于日结、定时扣款或长周期任务，还应覆盖相应执行周期。

监控既要看 CPU、内存、连接数和响应时间，也要看登录成功率、订单提交、支付回调、任务积压等业务指标。新、旧服务器日志应同时观察，确认旧端剩余请求如何处理。

旧资源的保留时间，应同时覆盖预计 DNS 缓存影响、关键业务周期和批准的回滚窗口，不能因“新站首页能打开”就立即停机释放。

五、回滚条件：以写入接管为界，不把改 DNS 当成完整回滚

新端尚未承接写入

如果新端仍处于验证或维护状态，没有产生必须保留的新增数据，可按预案恢复旧入口：

1. 确认新端应用、任务和消费者仍禁止写入。
2. 恢复旧 DNS 记录或 CDN 源站配置。
3. 恢复旧端应用服务，再按顺序启用任务和消费者。
4. 验证旧端业务，保持新端维护，处理仍访问新入口的缓存请求。

DNS 回退也不会瞬间覆盖所有访问，因此两端状态必须明确，不能同时开放写入。

新端已经承接写入

此时旧数据库已经不是最新状态。直接恢复旧端写入可能造成订单、付款状态、上传记录丢失或分叉。

应先冻结相关业务，记录新端最后写入时间与范围，再判断是修复新环境，还是通过已演练的数据回迁恢复旧环境。数据回迁还需要覆盖文件、队列和任务状态，不只是恢复一个数据库文件。

没有可靠反向同步和冲突处理方案时，不宜承诺写入后的快速回滚。迁移负责人应把这一限制提前写入变更单，而不是故障发生后才临时判断。

用具体条件触发暂停或回滚

以下可作为变更单的参考门槛，实际应结合流量规模与历史基线调整：

• 关键交易或支付回调无法正确处理，立即暂停相关写入并决策。
• 在样本量足够时，5xx 比例连续 5 分钟超过约定阈值，例如 1%，且无法短时定位修复。
• 出现数据遗漏、双写、重复扣款风险或关键文件缺失，立即停止继续放量。
• 目标端无法确认数据一致性，或复制链路未完成冻结点交接，不开放写入。
• 最终同步超出窗口，在新端尚未写入时停止迁移并恢复旧环境。

观察窗口结束前，旧环境应保持可恢复、不可独立写入的状态；窗口结束后，也应在完成备份验收、任务周期验证和责任人签字后再安排退役。迁移完成的标志，是新环境持续承接了可验证的业务，而旧环境能够按明确条件退出，并非 DNS 已经显示为新 IP。