docker搭建高可用数据库集群关键在于选对模式并做好容错设计：mysql主从需搭配哨兵实现自动切换；pxc/galera支持多点写入与强一致；tidb等newsql方案天然支持自动故障转移。
用 Docker 搭建高可用数据库集群，关键不在“容器化”本身，而在于选对集群模式并做好容错设计。单靠 MySQL 主从复制（Replication）不能算真正高可用——主库挂了，从库不会自动升主，业务会中断；必须搭配故障检测、自动切换与读写路由机制，或者直接选用原生支持多点写入与强一致的方案。
明确高可用目标：主从 vs 多主 vs 共享存储
不同方案解决不同问题：
- MySQL 主从 + 哨兵/Orchestrator：适合读多写少、能接受秒级延迟与短暂只读的场景。Docker 可快速拉起主从实例和监控组件，但切换需外部工具驱动，配置较重。
- PXC（Percona XtraDB Cluster）或 MariaDB Galera：三节点起，任意节点可读写，数据强一致，宕机一个节点不影响服务。Docker 镜像成熟（如 percona/percona-xtradb-cluster），网络与数据卷需按集群要求预设。
- 基于 Raft 的 NewSQL 方案（如 TiDB、CockroachDB）：Docker 官方提供一键部署脚本（如 tiup playground），自动构建多组件集群，天然支持水平扩展与自动故障转移，运维复杂度低但学习曲线略陡。
以 PXC 为例：5 步完成高可用集群搭建
PXC 是 Docker 场景下最平衡的选择——不依赖外部调度器，自身具备同步复制与自动故障恢复能力。
- 创建专用 bridge 网络，固定子网（如 172.18.0.0/24），确保节点间稳定通信。
- 为每个节点准备独立命名卷（如 v1、v2），避免容器重启丢失数据。
- 首节点启动时指定 CLUSTER_NAME 和 XTRABACKUP_PASSWORD，不加 CLUSTER_JOIN 参数。
- 后续节点通过 CLUSTER_JOIN=首节点容器名 加入，且必须在首节点就绪后再启动（通常等 60 秒）。
- 用 mysql -h 172.18.0.x -P 3306 连接各节点，执行 SHOW STATUS LIKE 'wsrep_%'; 验证 wsrep_cluster_size 是否等于节点总数、wsrep_ready 是否为 ON。
避坑要点：网络、权限与状态检查
Docker 内运行 PXC 容易失败，多数源于基础配置疏漏：
- 必须加 --privileged=true：PXC 启动时需调整系统参数（如 shmmax），普通容器权限不足。
- 不要复用默认 bridge 网络：跨主机或复杂拓扑下，自定义网络 + 固定 IP 更可靠；--ip 参数需严格匹配 cluster-announce-ip 配置。
- 节点时间必须同步：用 chrony 或 ntpd 统一校时，否则 Raft 投票可能超时失败。
- 启动后别急着连应用：先确认 wsrep_local_state_comment 为 Synced，再检查 wsrep_incoming_addresses 是否列出全部健康节点。
补充建议：让高可用真正落地
容器跑起来只是第一步，生产可用还需两层加固：
- 前置负载均衡：用 HAProxy 或 Nginx 做 TCP 层代理，配置健康检查（如检测 3306 端口 + 自定义 SQL 探针），将流量只打到 Synced 节点。
- 备份与恢复闭环：在某个 PXC 节点挂载定时备份脚本，用 mysqldump 或 xtrabackup 生成全量+增量包，并推送到对象存储。
- 监控不可少：通过 Prometheus + mysqld_exporter 采集 wsrep_* 指标，设置告警规则（如 wsrep_cluster_size 或 wsrep_local_state ）。
