本文介绍在双机部署的 go web 服务与 mysql 环境中，不依赖单点故障组件（如独立 haproxy）实现可靠故障转移的实用方案，重点解析浮动 ip（floating ip）机制及其在真实生产环境中的配置逻辑与注意事项。
本文介绍在双机部署的 go web 服务与 mysql 环境中，不依赖单点故障组件（如独立 haproxy）实现可靠故障转移的实用方案，重点解析浮动 ip（floating ip）机制及其在真实生产环境中的配置逻辑与注意事项。
在 Go + MySQL 双节点高可用架构中，“故障转移”的核心目标不是简单地“切换数据库连接”，而是确保客户端请求始终路由到当前活跃的服务节点——该节点同时运行健康的 Go 应用和可读写的主 MySQL 实例。你已成功配置 MySQL 主从复制，这是基础；但真正的高可用瓶颈在于服务入口层的动态决策能力。
✅ 推荐方案：浮动 IP（Floating IP）+ 健康探活 + 自动漂移
相比额外引入 HAProxy 作为反向代理（会引入新的单点故障 SPOF），更轻量、更健壮的方案是采用浮动 IP + 分布式健康检测：
- 浮动 IP 是一个可动态绑定到任一物理服务器的公网或内网 IP 地址；
- 仅由当前主节点持有该 IP，备用节点持续监听主节点心跳（如通过
keepalived或自研轻量探活服务）； - 一旦主节点宕机（进程崩溃、网络中断、MySQL 不可用），浮动 IP 秒级自动迁移到备机，所有流量无缝接管。
示例：使用 keepalived 实现浮动 IP 漂移（Linux）
在两台服务器（node-a 和 node-b）上安装并配置 keepalived：
# /etc/keepalived/keepalived.conf（node-a，优先级更高）
vrrp_script chk_go_mysql {
script "/usr/local/bin/health-check.sh" # 自定义脚本：检查 :8080 是否响应 + MySQL 是否可写
interval 3
weight -10
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
192.168.1.100/24 # 浮动 IP
}
track_script {
chk_go_mysql
}
}# /usr/local/bin/health-check.sh（需在两节点均部署）
#!/bin/bash
# 检查 Go 服务是否存活
if ! curl -sf http://127.0.0.1:8080/health | grep -q "ok"; then
exit 1
fi
# 检查本地 MySQL 是否为主库且可写
if ! mysql -uapp -p$PASS -e "SELECT @@read_only;" 2>/dev/null | grep -q "OFF"; then
exit 1
fi
exit 0✅ 优势：无额外中间件、零代理延迟、IP 层切换对应用完全透明；Go 服务无需任何代码修改，只需暴露
/health端点并确保连接本地 MySQL。
⚠️ 关键注意事项
-
MySQL 角色同步：浮动 IP 切换时，必须同步提升备机 MySQL 为新主库（可通过
CHANGE REPLICATION SOURCE TO ...+START REPLICA;脚本化，或使用mysqlrouter+InnoDB Cluster进阶方案）； -
数据一致性兜底：建议启用 MySQL 半同步复制（
rpl_semi_sync_master_enabled=ON），避免主库宕机前未同步的事务丢失； -
Go 客户端容错：虽然入口层已高可用，仍建议 Go 中使用
sql.Open(...)配合SetMaxOpenConns,SetConnMaxLifetime，并在database/sql错误处理中重试临时连接失败（如driver: bad connection）； -
避免脑裂（Split-Brain）：
keepalived必须配置nopreempt（备机不抢权）+ 合理advert_int+ 多播/单播通信校验，防止双主同时持 IP。
? 总结
你的初始思路（HAProxy）技术上可行，但违背了“消除 SPOF”的初衷。真正符合双机资源约束、运维简洁性与生产稳定性的方案，是以浮动 IP 为流量入口，结合本地健康检查与 MySQL 主角色联动，实现全自动、低干预的故障转移。整个过程 Go 代码零侵入，MySQL 复制拓扑不变，仅需在系统层增加轻量守护进程——这才是云原生时代下中小规模高可用架构的务实之选。
