服务器迁移香港前要核对什么？系统兼容性、数据库备份与DNS TTL清单

服务器迁移到香港，交付风险不只是“新服务器能不能打开网站”，而是切换后是否仍能正确读写数据、执行任务、接收回调，并在异常时保留可恢复的业务状态。系统能启动、数据库文件已导出、域名已改解析，这三件事分别完成，也不代表迁移已经具备上线条件。

实施前应先核对六类对象：迁移范围与写入入口、系统运行环境、外部依赖与网络权限、数据库及业务文件、DNS记录与TTL、切换后的验收和回退条件。其中，系统兼容性要以应用实际运行结果判断，数据库备份要以可恢复且一致的数据判断，DNS切换要以完整解析链和新旧流量并存期间的业务行为判断，不能只看配置是否填写正确。

一、迁移范围：先确认哪些对象必须一起交付

服务器迁移的对象通常不止一台机器。网站代码、数据库、上传文件、缓存、定时任务和第三方回调，可能分布在不同位置。若只搬迁网站目录，遗漏的组件往往要到真实业务请求进入后才暴露问题。

核对业务组件与数据归属

实施前应形成一份简明的迁移清单，至少明确以下对应关系。

特别要区分“可重新生成的数据”和“业务唯一数据”。页面缓存通常可以重建，用户上传文件、交易记录、任务处理状态则不能简单丢弃。Redis如果同时承载缓存、会话和队列，应按用途分别处理，不能因为名称是“缓存服务”就全部清空。

范围核对的通过标准：每一项业务数据都有去向，每一个写入入口都有控制办法，每一个域名都能对应到具体服务。 只知道网站首页在哪里，不足以批准切换。

核对停写条件与维护窗口

需要停写的入口不只是网页提交按钮，还包括API、管理后台、定时任务、队列消费者，以及支付等外部系统的回调。

实施前要确认：

• 哪些操作允许短暂停止，哪些必须持续接收。
• 停写期间的请求是拒绝、排队，还是由原环境继续处理。
• 最后一批增量数据如何同步，谁确认同步完成。
• 外部回调是否支持重试，重复通知是否有幂等处理。
• 维护窗口是否覆盖备份、传输、恢复、校验和异常处理。

如果业务不能停写，应另行设计增量同步、复制追平或统一写入入口。不能一边保持旧库持续写入，一边把一次全量导出当成最终迁移数据。

二、系统环境：版本相同不等于运行兼容

系统兼容性验收应围绕应用实际依赖展开。操作系统名称一致，只能说明基础环境接近，不能证明扩展、动态库、文件权限和服务配置都可用。

核对操作系统、架构与运行时

Linux环境可先用只读命令留存基础信息：

cat /etc/os-release
uname -m

运行时版本应使用当前项目对应的命令核验，并补充扩展清单、依赖锁定文件和启动参数。例如，PHP不仅要看主版本，还要看数据库驱动与所需扩展；Java要确认JDK版本、启动参数及信任库；Python项目要确认解释器和依赖包，而不是直接复制旧机器的虚拟环境。

容器化部署也不能跳过检查。镜像架构、挂载路径、环境变量、密钥注入、宿主机内核能力和持久化目录，都可能改变运行结果。

兼容性的通过标准是：目标环境能够运行同一业务版本，并完成关键业务操作；不是“软件都安装成功”。

核对配置、路径与权限

迁移中常见的问题是配置仍指向旧环境：数据库地址没有更换，文件路径仍使用旧目录，或应用监听地址只允许本机访问。

重点核对以下内容：

• 数据库、Redis、对象存储等连接地址与端口。
• 生产环境变量、加密密钥、签名密钥及证书路径。
• 应用运行账号对上传、日志、临时目录的权限。
• 文件名大小写、符号链接、绝对路径和挂载点。
• SELinux、AppArmor或Windows ACL等访问控制。
• 系统时间同步、时区，以及程序和数据库的时间处理方式。

权限应按应用所需范围恢复，不应为了消除报错而把整个网站目录设为所有人可写。跨系统迁移时，也不能默认用户编号、权限表达方式和文件名规则保持一致。

时区变化尤其需要单独验收。服务器迁到香港不意味着业务时间必须改变；应确认数据库存储、后台显示和定时任务采用的是UTC、固定时区还是本地时间，避免任务提前或延后执行。

迁移验收窗口内，宜减少无关变化。如果同时更换操作系统大版本、运行时大版本和数据库大版本，一旦出现异常，定位范围会明显扩大。

面向网站、业务后台与数据库迁往香港的部署需求，A5数据提供涵盖Xeon Gold与AMD EPYC平台的香港物理服务器，以不同档位的计算、内存及SSD、NVMe存储资源，承载应用运行、数据库缓存与业务文件读写。香港产品另有CN2与国际带宽方案，衔接内地及海外访问场景；大容量存储系列则为迁移备份文件、业务资料与归档数据提供存储空间，构成香港业务部署的资源基础。

三、依赖与网络：分别核对入站、出站和跨环境连接

内地服务器迁移至香港服务器后，源IP、网络路径和服务所在区域可能发生变化。原环境能访问的接口，不代表新环境自动具备相同权限；公网端口可达，也不代表业务链路符合要求。

核对入站访问与权限边界

入站检查应分别对应网站、API、管理入口和数据服务：

• 网站及API：核对安全组、主机防火墙、监听地址和服务端口。
• CDN或负载均衡回源：核对回源地址、Host、TLS设置及访问控制。
• 管理入口：核对运维账号、登录方式和允许访问的来源。
• 数据库等内部服务：核对应用访问路径，不应因迁移临时开放给整个公网。

判断依据应是从真实来源能够完成对应连接，而不是只在目标服务器本机执行一次请求。对公众网站，至少要从主要用户所在地验证访问；对受限管理入口，则应从授权运维来源验证。

如果需要调整安全组或防火墙，应先保存原规则，明确新增规则的来源、端口和用途，并保留撤销办法。数据库迁移所需的临时访问权限，应在验收后及时关闭。

核对出站依赖与IP白名单

香港服务器的出站公网IP可能与入站服务IP不同，也可能经由共享出口。依赖外部平台的业务，应核对实际出口地址及其稳定性。

常见对象包括支付接口、短信接口、邮件服务、对象存储、企业API和软件授权服务。对应判断依据是：鉴权成功、实际请求成功、回调处理成功，而不是仅能连通某个端口。

若计划把应用迁到香港、数据库暂留内地，还要专项验证应用与数据库之间的网络：

• 业务是否频繁执行串行查询。
• 连接池、查询超时及事务耗时是否合理。
• 网络短暂中断后能否恢复。
• 数据传输是否采用符合业务要求的安全方式。

跨地域数据库调用会引入额外往返时间。一个页面若串行执行多次查询，影响可能逐次累积，因此不能只凭带宽足够就判定可用。

涉及个人信息、重要业务数据或受行业约束的数据时，还应在实施前确认存储位置变化、跨境传输、授权和服务商协议等要求。技术迁移完成，不等于相关业务条件已经满足。

四、数据库与业务文件：备份必须能恢复，数据必须能对齐

数据库迁移前最重要的两项判断是：导出的数据是否一致，目标环境能否正确恢复。备份任务显示成功、生成了一个大文件，都不能单独作为通过依据。

核对数据库版本和对象范围

不同数据库应采用各自支持的迁移方法，不能把MySQL的导出参数直接用于PostgreSQL或SQL Server。

逻辑导出并不自动保证跨版本兼容，尤其不能默认高版本备份可恢复到低版本。验收前应使用目标数据库版本做一次恢复演练，并检查恢复日志。

MySQL还应检查视图、存储过程等对象的DEFINER，避免对象恢复后因定义者不存在而无法执行。PostgreSQL需要关注角色、对象所有权、扩展及恢复工具版本；SQL Server需要关注备份版本兼容性、登录映射和作业依赖。

核对导出一致性与备份权限

以MySQL为例，使用mysqldump做逻辑导出时，需要根据表引擎和业务状态选择一致性方式：

• 对InnoDB表，--single-transaction可用于获取事务一致性快照，但导出期间应避免相关DDL变更。
• 对MyISAM等非事务表，该参数不能提供同样的一致性保障，需要停写、锁定或采用适合的备份方式。
• 视图、触发器、存储过程和事件的覆盖范围要分别检查，不能只确认表数据。
• 数据库用户和实例级配置通常需要另外规划，不能认为业务库导出已完整包含它们。

导出账号应具备所用工具和所选选项要求的权限。正式操作前先进行一次预检，避免切换窗口开始后才发现权限不足。

备份文件应写入新的专用位置，不覆盖唯一的历史备份；其中可能包含密码哈希、用户资料等敏感信息，应限制访问并采用受保护的传输方式。导出会消耗源库的CPU、磁盘和网络资源，即使不长时间锁表，也应安排在业务可承受的时段。

数据库备份的验收标准：导出过程无未处理错误，文件完整，目标版本能够恢复，并且恢复后的关键业务数据校验通过。

核对传输、恢复与文件一致性

备份传输前后可比较校验值。以下命令只读取文件，路径应替换为实际备份文件：

sha256sum /path/to/backup.sql

源端和目标端校验值一致，证明传输后的文件内容一致，但不证明备份数据本身完整。还需检查导出日志、恢复日志，并核对表数量、关键表行数、最新记录和必要的业务汇总。

正式导入前应明确目标库是否已有数据。恢复演练宜使用独立测试库；涉及覆盖已有库时，应先备份目标库、确认影响范围，并准备恢复方法，不能直接在承载业务的目标库上反复试导入。

上传文件也必须与数据库对应。若数据库已经包含某张图片的记录，而文件仍留在旧服务器，切换后就会出现缺图。常用做法是先完成大部分文件传输，再在停写后同步最终变化，同时处理确需同步的修改和删除项。使用会删除目标文件的同步选项前，应先预览差异并保留备份。

时间预算应覆盖完整过程。以十进制口径估算，100 GB备份通过有效速率100 Mbps的链路传输：

• 100 GB = 100 × 1000 MB。
• 数据量换算为比特后为800,000 Mb。
• 传输时间约为800,000 ÷ 100 = 8,000秒，即约133分钟。

这只是按有效速率计算的传输时间，不含导出、恢复、索引构建和校验。压缩可能减少传输量，但会增加压缩和解压工作，应以演练结果安排维护窗口。

五、DNS与TLS：TTL要提前调整，解析链要完整核对

DNS切换不是“把一个IP改掉”。域名可能经过CNAME、CDN或负载均衡，IPv4和IPv6也可能分别指向不同环境。先明确实际流量入口，再决定应修改DNS记录还是上游平台的回源配置。

核对记录类型与TTL生效时间

TTL是递归解析器缓存DNS记录的时间提示，不是切换完成的倒计时。若原TTL为3600秒，在切换前几分钟才降至300秒，已经缓存旧记录的解析器仍可能按原TTL继续使用旧地址。

因此，应先降低TTL，再至少等待原TTL对应的时间，之后进入切换窗口。300秒可以作为某些场景的准备值，但应结合DNS平台支持范围和业务要求确定，不能据此承诺所有用户在五分钟内完成切换。

操作系统、浏览器、应用和长连接还可能保留既有地址或连接。新旧流量并存期间，旧服务器应有明确行为：继续提供受控服务、进入维护状态，或把请求导向统一入口，而不是继续向另一份数据库自由写入。

可用以下只读查询核对记录：

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer

还应分别查询实际权威服务器和业务常用递归解析器。不要只看本机的一次查询；使用简略输出时也容易忽略TTL和解析链信息。

核对证书与域名绑定

DNS正式切换前，应使用真实域名验证香港服务器上的HTTPS服务，而不是仅访问IP地址。

对于目标直接承载HTTPS的场景，可以使用：

curl --resolve www.example.com:443:203.0.113.10 \
  --connect-timeout 5 \
  --max-time 15 \
  -I https://www.example.com/

这里的域名和IP是文档示例，执行时替换为实际值。该命令只对本次请求指定目标IP，保留域名对应的Host和TLS SNI，不修改公共DNS。

检查证书有效期、域名覆盖范围、证书链、跳转目标和虚拟主机绑定。不要加上跳过证书验证的参数后，便把请求成功视为TLS验收通过。只接受CDN回源的源站，则应按真实回源协议和访问控制验证。

HEAD请求适合初步检查响应，不代表登录、提交、上传等功能正常。正式切换前仍需完成应用级验证。

六、切换批准条件：把“可切换”和“可回退”分开验收

所有前置检查完成后，交付负责人应根据业务证据批准切换，而不是只依据运维操作是否完成。

核对切换顺序和验收证据

对于允许短暂停写、采用全量加最终增量迁移的业务，可按以下顺序设置验收点：

1. 环境就绪：香港服务器上的应用、权限、网络、依赖和证书通过预检。
2. 恢复演练通过：备份成功恢复，关键数据和代表性业务功能符合预期。
3. TTL准备完成：提前降低TTL并等待原缓存时间，核对全部入口。
4. 控制写入：暂停相关写入、任务和消费者，处理在途请求。
5. 最终数据对齐：完成数据库最终同步、文件补同步及一致性确认。
6. 启用新环境：按顺序开启应用和后台任务，变更DNS或回源入口。
7. 观察并验收：检查真实流量、错误、业务写入和外部回调后，再恢复常态配置。

这些验收点不要求采用固定的迁移工具，但每一步都应有负责人和通过依据。最低限度应保留环境版本、备份与校验结果、恢复日志、DNS变更时间及业务验证记录，便于解释后续差异。

业务测试应至少覆盖登录与会话、一次实际读写、上传下载、关键交易或订单流程、外部回调，以及后台任务。支付等流程宜使用测试环境或受控测试方式，避免为验收制造无法清理的真实交易。

核对回退的数据边界

回退不是简单把DNS改回旧IP。新环境一旦产生业务写入，就必须先解决两边的数据差异。

旧服务器应保留多久，也不宜只按TTL机械决定。需要同时观察DNS残留流量、客户端长连接、旧入口请求、后台任务和外部回调。旧环境保留期间，不应让两套任务持续重复执行。

如果系统兼容性未通过，应先补齐依赖或调整版本；如果备份没有完成恢复验证，应先演练；如果最终数据无法对齐，应暂停切换；如果新环境已有写入却没有回退方案，应先明确数据处理路径。待关键对象逐项具备可验证的通过依据，再进入正式迁移窗口，比上线后边接流量边补条件更可控。