Apache自身不提供负载均衡器主备切换能力，需依赖Keepalived等外部工具实现VIP接管；其mod_proxy_balancer仅负责后端服务器健康检查与自动摘除，不参与自身高可用决策。
Apache 本身不提供负载均衡器（即反向代理节点）自身的高可用主备切换能力。它只能作为后端服务被前置的负载均衡器调度，或通过 Keepalived 等外部工具实现自身角色的主备接管。所谓“Apache 负载均衡器的高可用”，实际是指：让两台运行 Apache（启用了 mod_proxy_balancer）的服务器，对外表现为一个统一入口（如 VIP），当主 Apache 故障时，流量自动切到备用 Apache —— 这个切换动作不由 Apache 完成，而由 Keepalived 的 VRRP 协议驱动。
用 Keepalived 实现 Apache 反向代理节点的主备切换
这是最成熟、生产环境广泛采用的方式。两台 Apache 服务器都配置完全相同的反向代理规则（指向同一组后端真实服务器），再由 Keepalived 管理一个虚拟 IP（VIP）。主节点持有 VIP 并响应请求；备节点持续监听主节点心跳，一旦失联，立即接管 VIP。
- 安装并启用 Keepalived：在两台 Apache 服务器上均执行
yum install keepalived（CentOS）或apt install keepalived（Ubuntu） - 主节点配置
/etc/keepalived/keepalived.conf：vrrp_instance VI_1 {<br> state MASTER<br> interface eth0<br> virtual_router_id 51<br> priority 100<br> advert_int 1<br> authentication {<br> auth_type PASS<br> auth_pass 1111<br> }<br> virtual_ipaddress {<br> 192.168.1.100/24<br> }<br>} - 备节点配置类似，仅修改
state BACKUP和更低的priority（如 90） - 确保两台 Apache 的
httpd.conf或虚拟主机中，ProxyPass规则一致，且监听*:80（而非仅127.0.0.1:80） - 启动
keepalived后，用ip addr show查看 VIP 是否出现在主节点网卡上
Apache 自身不能当主备控制器，但可配合健康检查做后端摘除
如果你指的是“Apache 作为负载均衡器，对其后端服务器实现主备切换”，那核心是 mod_proxy_hcheck + status=+H 配合使用，而非 Apache 自己切换自己。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 主后端节点开启健康检查：
BalancerMember http://10.0.1.10:8080 hcmethod=GET hcuri=/health hcinterval=5 hcfails=1 hcpasses=1 - 备后端节点设为热备：
BalancerMember http://10.0.1.11:8080 status=+H - 当主节点健康检查失败（如 /health 返回非 200 或响应体不匹配），Apache 自动将其标记为 Down，新请求全部发往热备节点
- 注意：
mod_proxy_hcheck要求 Apache ≥ 2.4.47，且需手动加载：LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so，并确认mod_watchdog已启用
不要混淆层级：Apache 是后端，不是 LB 控制面
常见误区是试图让 Apache 同时承担“负载均衡器”和“自身高可用”的双重角色。实际上：
- 若 Apache 前面有 Nginx / HAProxy / 云 CLB：应由它们做健康检查与主备切换，Apache 只专注处理后端业务
- 若 Apache 直接对外（无前置 LB）：必须依赖 Keepalived 或类似工具管理 VIP，Apache 本身不参与状态决策
- Apache 的
mod_proxy_balancer管理的是“后端真实服务器”，不是“自己是否该上线”——它没有选举、心跳、故障通告等集群控制逻辑
验证与运维要点
切换是否生效，不能只看服务是否起来，要看流量路径和连接行为：
- 停掉主 Keepalived 后，立刻在客户端执行
arping -I eth0 192.168.1.100，确认 VIP MAC 地址已变更 - 访问业务 URL，用
curl -v查看响应头中的Server字段，确认来自备机 - 检查备机的
access_log，确认请求量上升，且无大量 502/503 - Apache 启用
mod_status（ExtendedStatus On），通过/server-status?auto实时观察 worker 状态，避免长连接阻塞导致切换延迟
