测试dfs跨机房容灾切换恢复时间，核心是模拟真实故障、精确测量业务中断时长并验证数据一致性与可访问性；rto起始于客户端首次失败响应，终止于连续3次成功上传下载且md5校验通过、耗时不超正常值1.5倍，需直连ip测试、注入可控故障（如drop心跳包或停tracker服务）、执行标准化流程并排除ntp不同步等干扰。
测试 dfs 跨机房容灾切换的恢复时间，核心是模拟真实故障场景、精确测量服务中断时长，并验证数据一致性与可访问性。不能只看“系统是否重启”，而要关注“用户能否继续上传/下载、读到的是不是最新数据、延迟是否在业务容忍范围内”。
明确恢复时间的定义和测量点
恢复时间（RTO）不是从断电开始计时，而是从业务视角定义：
- 起始点：主中心完全不可用（如 Tracker 失联、Storage 组整体离线、网络隔离生效），且客户端首次收到失败响应（如 upload timeout、404 或 503）
- 结束点：客户端能稳定完成一次成功上传+下载，且返回内容与原始文件完全一致（md5 校验通过），连续 3 次操作耗时 ≤ 正常均值 1.5 倍
- 注意避开 DNS 缓存、客户端重试退避等干扰——建议直连 IP 测试，或强制刷新本地 hosts
搭建可控的跨机房故障注入环境
真实断网风险高，推荐用轻量、可逆的方式模拟：
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- 在主中心防火墙规则中，DROP 所有来自备用中心 Tracker 的心跳包（端口 22122）和 Storage 同步流量（端口 23000），持续 60 秒
- 停掉主中心所有 Tracker 服务（
systemctl stop fdfs_trackerd），但保持 Storage 进程运行（用于对比同步滞后状态） - 使用
fdfs_monitor实时观察 client.conf 指向的 tracker 列表是否自动切换，Storage 状态是否由 ACTIVE 变为 OFFLINE
执行标准化测试流程并记录关键指标
每次测试需固定操作序列，避免人为误差：
- 故障前：上传 10 个典型文件（1MB 图片 + 10MB 视频 + 1KB 文本），记录每个 FileID 和 md5
- 注入故障后，立即启动计时器，每 5 秒尝试一次上传新文件，记录首次成功时间
- 恢复后，对每个原始文件执行下载+校验，统计“首字节延迟”和“完整传输耗时”，标记任何校验失败或超时（>30s）项
- 重点检查 binlog 同步进度：
cat /home/fdfs/storage/data/sync/binlog.* | tail -n 20，确认主中心重启后是否追平从中心最新 offset
排除常见干扰因素
很多“RTO 不达标”其实源于配置或环境问题：
- 确保所有节点 NTP 时间同步误差
- client.conf 中
connect_timeout和network_timeout需设为 3–5s，避免单次失败等待过长 - 禁用 Storage 的
store_slave_file_when_master_down=false（默认 true），否则主挂后从不接收新写入，导致“假恢复” - 跨机房带宽不足时，同步可能卡在大文件上——建议用
iotop -p $(pgrep fdfs_storaged)查看实时 IO 速率
