Master进程不直接依赖信号量实现容灾切换，真正起作用的是健康探测、状态协商、自动选举与服务重定向构成的主备协同架构；信号仅作本地轻量通知辅助，绝不能用于跨节点切换。

Master 进程本身不直接提供信号量机制用于容灾切换——信号量（semaphore）是操作系统级的同步原语，主要用于多线程/多进程间资源互斥，而非跨节点故障检测与服务接管。企业级高可用主动容灾切换依赖的是健康探测、状态协商、自动选举与服务重定向这一整套机制，而非靠向 Master 发送 SIGUSR1/SIGTERM 等信号来触发切换。

真正起作用的是“主备协同架构”，不是信号量

在 MySQL、Redis、Tair、Kafka 等主流中间件或数据库中，所谓“Master”只是一个逻辑角色（如主库、主分片、Leader 节点），其背后由独立的高可用管理模块驱动：

• MHA Manager 或 Orchestrator 持续 ping 主节点，超时即启动提升最新从库为新主的流程
• Redis Sentinel 通过 quorum 投票机制判定主节点客观下线（odown），再执行 failover
• Tair 集群由通道管理器监控子实例健康，自动迁移主分片并更新路由表
• Kubernetes 中的 StatefulSet + 自定义 Operator 通过 readiness/liveness probe 判定 Pod 状态，触发重建或主从重调度

信号可作为辅助手段，但不能作为切换依据

某些自研系统会用信号做轻量级通知，例如：

• 向本地 HA Agent（如 keepalived 的 notify script）发送 SIGUSR2，表示“本机主进程已就绪”，用于初始化 VIP 绑定
• 主进程收到 SIGHUP 时重载配置，配合外部探针完成平滑升级（非容灾场景）
• 但绝不应依赖 kill -USR1 master_pid 来触发跨机房切换——这无法保证数据一致性，也绕过仲裁逻辑，极易引发脑裂

构建主动容灾切换的关键组件

一个可靠的企业级方案必须包含以下四个层次：

• 探测层：多维度心跳（TCP 连通性 + SQL 查询响应 + 日志位点延迟）+ 超时分级（秒级告警 / 分钟级切换）
• 决策层：基于多数派共识（如 etcd Raft、ZooKeeper ZAB）或预设策略（如 MHA 的 latest-slave 优先）选出新主
• 执行层：自动执行 binlog 补齐、VIP 漂移、DNS 权重调整、API 网关路由更新、客户端连接池刷新
• 验证层：切换后立即校验数据一致性（pt-table-checksum）、服务连通性（curl 健康端点）、业务指标（订单创建成功率）

推荐落地路径

以 MySQL 为例，建议采用“半同步 + MHA + Proxy（如 ProxySQL）”组合：

• 开启 rpl_semi_sync_master_enabled=ON，确保至少一个从库落盘才提交事务
• MHA Manager 部署在独立节点，每 3 秒探测主库，10 秒未响应即启动 failover
• ProxySQL 实时监听后端状态，主库宕机后自动将写流量切至新主，读流量按权重分发到存活从库
• 所有应用通过 ProxySQL 接入，完全屏蔽底层切换细节