直播服务器迁移到新机前要准备什么：数据同步、DNS切换和回滚窗口

一次直播服务器迁移失败，往往不是新机起不来，而是切换后才发现推流鉴权没同步、录制目录少了一部分、DNS缓存还指向旧IP，回滚时旧机上的配置又被临时改过。结果是推流端报错、观众端间歇 404，录制文件还出现断档。

迁移前要降低停机和回滚风险，核心不是追求“零停机”，而是把业务、数据、DNS切换和回滚窗口拆开管理：先确认新机能独立承载推流、拉流和录制；再做全量与增量数据同步；最后在可控时间窗口内切换入口，并保留旧机到观察期结束。以下迁移指南适用于自建直播源站、直播业务后台、录制服务器或推拉流入口迁移，具体命令需按当前系统、直播组件和目录结构调整。

目标状态：新机接管业务前应达到什么条件

直播服务器迁移不是简单复制 /data 目录。上线前，新机至少要达到以下状态：

• 推流端可以连接新机地址，并通过鉴权、回调或密钥校验。
• 拉流端可以从新机获取 RTMP、HTTP-FLV、HLS、WebRTC 或业务实际使用的播放地址。
• 录制目录、录制回调、转封装任务和文件命名规则与旧机一致。
• 证书、域名、API 回调地址、跨域配置、Referer 防盗链、IP 白名单等关键配置已同步。
• 新机端口、系统限制、磁盘挂载、日志路径、定时任务、监控告警均已检查。
• 旧机保持可回退状态，不在切换前删除数据、卸载服务或修改为不可恢复配置。

如果直播业务依赖 CDN，DNS切换通常不只是改业务域名 A 记录，还可能包含 CDN 回源地址、源站白名单、鉴权回调域名和管理后台地址。切换前应明确：用户访问的是 CDN 域名、业务域名，还是直接访问源站域名。不同入口的回滚方式不同。

环境检查：先盘点业务、数据和新机承载能力

盘点直播链路和入口域名

迁移前先画出当前链路，不要只看服务器面板里的一个 IP。建议至少列出以下内容：

如果有多个域名，例如 push.example.com、play.example.com、api.example.com、record.example.com，不要默认它们都在同一个 DNS 解析服务中。切换前用 dig 或 DNS 控制台核对权威解析记录、TTL 和当前解析值。

dig push.example.com A +short
dig play.example.com A +short
dig api.example.com A +short
dig NS example.com +short

盘点必须同步的数据

直播服务器的数据可以分为四类，处理方式不同：

1. 配置类数据 包括直播服务配置、虚拟主机配置、证书、鉴权密钥、回调地址、转码模板、录制模板、定时任务、systemd 服务文件、环境变量文件等。配置类数据变动少，但漏一项就可能导致新机业务不可用。

2. 业务状态数据 包括房间状态、流状态、用户鉴权、推流密钥、禁播列表、黑白名单、管理后台数据等。如果这些数据在数据库或 Redis 中，需要按数据库迁移方案处理，不能只复制应用目录。

3. 媒体文件数据 包括录制文件、HLS 切片、封面、回放文件、点播文件。正在写入的录制文件不适合直接粗暴复制，应区分已关闭文件和活跃文件。

4. 日志与审计数据 包括访问日志、推流日志、错误日志、回调日志、账单或统计原始日志。日志不一定全部迁移到新机，但至少要保留旧机日志，方便切换后排查。

可先在旧机生成配置备份。下面命令只是示例，路径要按实际组件确认；执行前不要把不存在或无关目录硬套进去。

mkdir -p /root/live-migration-backup

tar -czf /root/live-migration-backup/live-config-$(date +%F).tgz \
  /etc/nginx \
  /etc/systemd/system \
  /etc/letsencrypt \
  2>/tmp/live-config-backup-warn.log

如果使用 SRS、Nginx-RTMP、Janus、Coturn、Node/Java/PHP 后台等组件，应把各自配置目录和应用环境变量纳入清单。不同系统版本的路径不完全一致，迁移前以当前服务启动参数和配置文件为准。

核算新机资源，而不是只看“能启动”

直播业务对新机的要求主要来自三部分：出口带宽、磁盘写入和并发连接。CPU只有在转码、截图、水印、协议转换较多时才会成为主要瓶颈。

两个简单估算公式可以帮助判断新机是否适合承载当前业务：

出口带宽需求 Mbps ≈ 平均播放码率 Mbps × 并发拉流数 × 1.2
录制空间 GB/小时 ≈ 录制码率 Mbps × 3600 ÷ 8 ÷ 1024 × 路数

如果前面有 CDN，源站带宽主要取决于回源比例和回源并发，不等于所有观众总带宽。若没有 CDN，直播服务器直接对外分发，出口带宽会很快成为主要限制，迁移前必须用业务峰值数据核算。

在IDC产品选型上，新机应根据用途拆分判断：源站和拉流入口更关注线路、出口带宽、连接稳定性；录制节点更关注磁盘容量、持续写入和备份策略；控制后台和数据库更关注CPU、内存和SSD随机读写。LHIDC可提供的香港AMD高性能服务器配置为 AMD EPYC 4585PX、64G DDR5-5600、960G NVMe SSD、25M CN2 + 100M BGP；香港至强大内存服务器配置为 Intel Xeon Gold 6138、128G、2×960G U.2 SSD、25M CN2 + 100M BGP。它们更适合结合业务后台、数据库、多业务部署或中小规模源站场景评估；是否适合承担直播分发流量，仍需按码率、并发、CDN回源和当前线路测试结果确认，不能只看机器规格下结论。

分阶段部署：全量同步、增量同步和最终冻结

第一阶段：新机基础服务对齐

新机上线前先不要改DNS。应先用新机IP或临时测试域名完成基础验证：

• 系统时间、时区、NTP 同步正常。
• 直播服务进程可以启动，端口监听符合预期。
• 证书文件、私钥权限、域名配置加载正常。
• 防火墙、安全组、机房侧访问控制已放行实际端口。
• 磁盘挂载点、录制目录、日志目录存在且权限正确。
• 监控探针、日志采集和告警已接入。

检查端口监听时，可以用以下方式确认服务是否已绑定到预期端口。端口号请按实际业务替换。

ss -lntup | egrep ':(80|443|1935|8080|1985)\b'

查看服务状态时，不同直播组件服务名不同，先用 systemctl list-units 确认名称，再查看日志：

systemctl list-units --type=service | egrep 'nginx|srs|live|media'

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

如果服务名是 srs、media-server 或自定义名称，将命令里的服务名替换为实际值。

第二阶段：做一次全量数据同步

全量数据同步适合配置目录、历史录制文件、静态资源和不频繁变更的数据。Linux 服务器之间常用 rsync，第一次建议先执行 --dry-run 预演，确认同步范围没有误删风险。

rsync -aHAX --numeric-ids --info=progress2 --dry-run \
  /data/live-record/ root@NEW_SERVER_IP:/data/live-record/

确认列表正确后，再执行正式同步：

rsync -aHAX --numeric-ids --info=progress2 \
  /data/live-record/ root@NEW_SERVER_IP:/data/live-record/

如果需要使用 --delete 让新机目录与旧机完全一致，必须先预演并确认新机目录没有额外重要文件。迁移过程中不建议默认加 --delete，因为它可能删除新机上已生成的测试文件、日志或临时配置。

对于数据库，建议按数据库类型采用备份恢复、主从复制、逻辑导出导入或应用自身迁移工具。不要在不了解数据一致性要求的情况下直接复制数据库数据目录。直播业务中的房间状态、鉴权密钥、订单关系、录制索引等都可能存放在数据库中，这部分缺失会造成“服务能启动，但业务不可用”。

第三阶段：增量同步并处理活跃录制文件

全量同步后，旧机仍在接收推流和写入录制文件，因此需要安排增量同步。可在切换前多次执行同样的 rsync，缩短最终同步耗时。

对录制文件要特别注意：正在写入的文件可能复制到一半，导致新机上文件不完整。处理方式可以按业务允许程度选择：

• 如果可以短暂停播：在切换窗口内停止新推流或通知主播暂停，等待录制文件关闭后做最终同步。
• 如果不能统一停播：将旧机保留到活跃直播结束，再迁移历史录制；新机只承接新开播流。
• 如果录制上传到对象存储：确认上传队列、回调状态和失败重试任务是否随应用迁移，不要只同步本地临时文件。

可以对最近变更文件生成校验清单，抽样验证同步结果：

cd /data/live-record
find . -type f -mtime -2 -print0 | sort -z | xargs -0 sha256sum > /tmp/record-recent.sha256

在新机相同目录下执行校验：

cd /data/live-record
sha256sum -c /tmp/record-recent.sha256

如果文件量很大，不必对所有历史文件逐个校验，可以对最近录制、重点房间、随机样本做校验，并保留旧机数据到观察期结束。

DNS切换：先降TTL，再切入口，不要临时拍脑袋

DNS切换的关键是提前规划。切换当天才把 TTL 从 3600 改成 60，很多递归DNS仍会按旧TTL缓存一段时间，不能立即生效。比较稳妥的做法是提前 24 到 48 小时降低 TTL，常见设置为 60 到 300 秒；具体能否生效取决于解析服务商、递归DNS缓存和客户端环境。

一个可执行的切换时间表如下：

切换方式要看实际入口：

• 直接源站域名：修改 A 记录或 CNAME 指向新机。
• CDN加速域名：修改 CDN 源站地址或回源Host，必要时同步源站白名单。
• 推流域名和播放域名分离：可先切推流入口，再切播放入口，也可以先让新机承接新流，旧机维持老流。
• 多线路或多地区解析：需要分别检查不同线路解析结果，避免只切了默认线路。

切换后可用以下命令确认解析是否变化：

dig push.example.com A +short
dig play.example.com A +short

dig @8.8.8.8 push.example.com A +short
dig @1.1.1.1 push.example.com A +short

需要注意，命令看到的结果不等于所有用户立即生效。移动网络、企业DNS、本地缓存、播放器DNS缓存都可能延迟更新，所以旧机应继续保留服务能力，而不是切换后马上关机。

上线检查：验证推流、拉流和录制是否闭环

DNS或CDN回源切换后，检查顺序应从入口到业务闭环，而不是只看进程是否存活。

验证推流

准备一个测试流名，例如 test_migrate，使用测试账号或临时鉴权参数向新入口推流。以下命令假设测试机器已安装 ffmpeg，且当前目录存在 sample.mp4：

ffmpeg -re -stream_loop -1 -i sample.mp4 \
  -c copy -f flv \
  "rtmp://push.example.com/live/test_migrate"

如果推流失败，优先检查：

• 推流域名是否解析到新机或新CDN回源。
• 新机 1935、443 或实际推流端口是否放行。
• 鉴权密钥、时间戳、回调接口是否与旧机一致。
• 直播服务错误日志是否出现 auth failed、connection refused、vhost not found、stream forbidden 等信息。
• 业务后台是否把流状态写入了正确数据库。

验证拉流

推流成功后，不要只用浏览器看一眼。应分别验证业务实际使用的播放协议。示例：

ffprobe -v error -show_streams -show_format \
  "https://play.example.com/live/test_migrate.m3u8"

如果是 HTTP-FLV 或 RTMP，替换为对应播放地址。验证重点包括：

• 首屏是否能拉到流。
• 音视频编码是否符合播放器要求。
• HLS 是否持续生成新切片，m3u8 是否更新。
• 播放URL中的鉴权参数是否仍然有效。
• CDN命中和回源是否符合预期。

同时观察新机连接数、出口带宽和错误日志：

ss -ant | awk '{print $1}' | sort | uniq -c
journalctl -u nginx -n 200 --no-pager

如果使用的不是 Nginx，请替换为实际直播服务日志。日志路径应以当前配置为准，常见位置包括 /var/log/nginx/、应用自定义日志目录或 systemd journal。

验证录制

录制验证要确认三个层面：

1. 文件是否生成 查看录制目录是否出现新文件，文件大小是否持续增长。

find /data/live-record -type f -mmin -10 -ls | tail -20

1. 文件是否可播放 对最新录制文件执行媒体信息检查：

ffprobe -v error -show_format -show_streams /data/live-record/path/to/latest_file.mp4

1. 业务是否收到录制结果 如果录制完成后需要回调业务系统、写数据库、上传对象存储或生成回放列表，要检查回调日志和业务后台状态。很多迁移事故不是录制文件没生成，而是录制索引没有写回，导致用户看不到回放。

常见错误：这些问题最容易在切换后暴露

只同步媒体文件，漏掉鉴权和回调配置

直播服务能启动不代表业务可用。推流鉴权、播放鉴权、回调URL、API密钥和防盗链配置往往分散在应用配置、环境变量、数据库和服务配置中。迁移前应从旧机启动参数、配置文件和后台管理项反向核对，而不是只复制一个目录。

DNS TTL 没提前降低

临近切换才修改 TTL，实际效果有限。旧解析可能继续被递归DNS或客户端缓存，导致一部分流量到新机，一部分流量到旧机。这个状态并不一定是故障，但必须提前预期，并保证两边在观察期内都能承接合理请求。

旧机过早停止服务

DNS切换后马上关旧机，会让仍解析到旧IP的推流端和观众端失败。更稳妥的做法是旧机进入只保留、不变更、不删除的状态，至少覆盖一个完整业务高峰或约定观察期。

录制活跃文件被复制成半截

正在写入的 MP4、FLV 或 TS 文件被复制时，可能在新机上不可播放。最终同步时应尽量等待文件关闭，或明确新旧机录制边界：旧机负责切换前已开始的直播录制，新机负责切换后新开播录制。

新机带宽按平均值估算，没有考虑峰值

直播流量具有突发性。平均码率和平均并发只能作为初步估算，切换窗口应避开大促、赛事、发布会等高峰。如果必须在高峰前迁移，应先做灰度流量或单房间试切，确认新机带宽、连接数和磁盘写入没有明显瓶颈。

回滚窗口：什么时候切回旧机，什么时候继续观察

回滚不是失败后的临时动作，而是迁移方案的一部分。建议在迁移单中提前写清楚以下条件：

• 推流失败率明显上升，且 10 到 15 分钟内无法定位为单一配置问题。
• 播放端大量出现 404、403、5xx、卡顿或切片不更新。
• 录制文件不生成、文件不可播放，或录制回调持续失败。
• 新机出口带宽、磁盘IO、CPU或连接数达到风险阈值，并影响业务。
• CDN回源异常，且无法在迁移窗口内快速修复。
• 数据库、缓存或业务后台状态出现不一致，影响开播、禁播或回放。

回滚操作通常包括把 DNS 或 CDN 回源改回旧机、停止新机接收新增推流、保留新机日志和数据供排查。由于DNS仍有缓存，回滚也不会让所有用户瞬间回到旧机，所以旧机和新机都要继续观察一段时间。

旧机至少保留到满足以下条件后再下线：主要域名解析稳定指向新机；新机已覆盖一个业务高峰；推流、拉流、录制和回调均通过验证；最近录制文件可播放且业务后台可见；监控没有持续异常。若任一条件不满足，应延长回滚窗口，而不是急于释放旧服务器。