binlog_expire_logs_seconds 压到 3600s 后 replica 断链 2h，binlog 已 purge 无法重建，retention 到底怎么设才安全

背景：MySQL 8.0.36，单主 + 2 从（半同步 rpl_semi_sync_master_wait_for_slave=ON），主库 32C/128G/ESSD PL2，从库同规格但磁盘是 SSD。binlog 日均增长约 200GB（大量 INSERT + 少量 UPDATE），之前 binlog_expire_logs_seconds=604800（7 天），磁盘经常触发 90% 告警，运维要求压到 3600s（1 小时）。

现象：

1. 上周三凌晨 03:12，从库 A 因机房交换机故障断了 2 小时 07 分；
2. 05:19 网络恢复，从库自动重连，主库报：Got fatal error 1236: 'Could not find first log file name in binary log index file'，从库直接 stopped；
3. 主库 binlog 只保留了最近约 50 分钟（3600s 窗口内），从库 GTID 缺口约 80GB（2h 的写入量）；
4. 最后只能从主库 xtrabackup 全量备份 → 恢复到从库 → 重新挂从，业务停写约 4 小时；
5. 从库 B 因为不在同一机房，没受影响，但半同步模式下从库 B 确认也慢了约 30s（主库 P99 从 2ms 飙到 45ms）。

已尝试 / 已排查：

• 查了 MySQL 8.0 文档，binlog_expire_logs_seconds 是"后台线程按时间清理"，不是硬删除，但清理一旦执行就不可恢复；
• 试过把 retention 调到 7200s（2h），运维说磁盘还是不够（按峰值 200GB/天算，7200s 约 17GB，但 binlog 文件是整文件删，实际会多占）；
• 考虑过用 xtrabackup 做"增量备份兜底"（每 30 分钟一次增量），但还没落地；
• 半同步的 rpl_semi_sync_master_wait_timeout 当前是 10s，超时后降级为异步，没有进一步调整；
• 没有用 MySQL 8.0.23+ 的 binlog checkpoint 功能（不确定是否适用）。

想请教：

1. retention 到底该按什么原则设？ 是"从库最大可能延迟 × 安全系数"还是"磁盘能撑的最大时间"？有没有更细的经验公式？比如从库最大可接受延迟 1h，那 retention 是不是应该 ≥ 2h？还是应该 ≥ 4h？
2. 有没有比"加大 retention"更优雅的方案？ 我想到三个方向，想听听大家的实际经验：(a) GTID + 周期性 xtrabackup 增量备份做兜底，这样 retention 可以压到很短（比如 30min）；(b) 半同步改成"全同步"（rpl_semi_sync_master_wait_for_slave=ON + 超时不降级）来保证从库一定确认，但主库 P99 会涨；(c) 引入第三个"热备从库"专门用于断链恢复，而不是每次都从主库全量备份。
3. 如果 retention 必须压到 1h（运维硬性要求），那从库断链超过 1h 的预案应该是什么？ 全量重建的 RTO 怎么优化？有没有人做过"热备从库 + 冷备从库"的分层容灾方案，能分享具体架构和 RTO 数据？