主播放机断线后谁继续发节拍：怎样做主节点失效演练

主节点失效时，应分别演练链路断开、主进程退出和恢复上线，并记录从节点究竟继续本地时基、暂停、等待还是切换主节点。只有受测系统明确实现选主，才能验自动接替；未确认时不能预设“备机会自动顶上”。

判断前提与适用边界

网络可达性与主节点存活不是同一信号。断开网线可能同时阻断控制与时钟，而进程退出时操作系统仍在线；恢复后又可能出现两个节点都认为自己是主的冲突。故障协议要写清谁有权发送节拍、如何识别旧主，以及何时允许重新加入。

本文是可执行的测试协议与合成数据演算，未接实体多机、同步卡、显示墙或相机。Python 3.12.4验证计算，编号样片若提供由FFmpeg 8.0.1生成；实际GPU、驱动、播放器版本、网络拓扑和相机模式须在现场记录。

按同一条件执行

1. 在闭馆或隔离环境确认手动停止与恢复入口，保存原工程、角色和节目摘要；约定测试终止条件。

2. 第一轮只断同步链路，保留本地内容，记录失联检测、画面状态与控制回执；恢复后核对角色。

3. 第二轮只让主播放进程正常退出，再按厂商批准方式测试异常退出；不要把整机断电与进程退出混作一轮。

4. 第三轮使原主恢复，观察是否出现双主、全组重播或短暂跳变；每一步记单调时间与角色声明来源。

原始输入与判断示例

下面是合成示例，非现场实测。现场表中的空白表示未采集，不能当作零、正常或通过。

合成故障轨迹	观察状态	验收判断
链路断开	从节点继续，角色未变	符合与否取决于合同策略
进程退出	等待人工	不是自动选主
旧主恢复	两个主声明	必须停止扩大发送并排查

下载的事件夹具包含三个分离场景及空白角色时间线，没有发网包或杀进程脚本。这样能先审查故障状态机，再在现场受控执行。恢复耗时应从各自故障事件起算，不能拿检测后才开始计时的结果与全程恢复时间比较。

下载夹具并形成交付记录

下载专项输入与预期JSON和空白记录CSV。JSON保留原始输入、预期、记录字段及未测范围；CSV用于逐轮填写，原始日志、截图或仪表文件用稳定文件名关联。

本表保留 scenario, event_id, mono_seconds, node 等字段；先按上表核对合成输入，再将目标环境数据另存一份。未采集的字段留空，失败记录与原始文件一并保留，避免下一轮无法复现。

误判与失败路径

不要在开放中的生产网拔线试验；不要因画面还在动就认定同步继续有效；不要把两台设为主当冗余设计。若厂商没有角色状态接口，把未知项写入验收限制，并保留人工恢复步骤。

基础背景见多播放服务器集群管理实战，相关流程汇总在多媒体播放专题。需要在SoftPlayer上执行这项测试时，按受测版本文档填写配置与支持情况。

一级来源与核验范围

NVIDIA：To synchronize multiple systems，硬件连接与锁定状态，核对日期2026-10-23。本文协议与合成样例为独立设计；来源中的机制说明不代表附件已完成现场验收。