3节点伪分布式（1 PD + 2 TiKV + 2 TiDB）已足够体现高可用性逻辑，应使用官方tidb-docker-compose部署，配置PD多实例、TiKV副本数≥3、TiDB多开，并确保内存充足、网络正确及时区统一。
在 Docker 中部署高可用的 TiDB 集群，关键不是堆节点数量，而是让核心组件（PD、TiKV、TiDB）具备多副本容错能力，并确保它们能自动发现、健康检测和故障转移。对大多数开发、测试或轻量生产场景来说，**3 节点伪分布式（1 PD + 2 TiKV + 2 TiDB）已足够体现高可用性逻辑**，且资源可控、启动快、排查直观。
选对部署方式：优先用官方 tidb-docker-compose
不建议手写 docker run 命令逐个启容器——易出错、难维护、无服务依赖编排。直接使用 PingCAP 官方维护的 tidb-docker-compose 项目，它已预置多种拓扑配置：
- docker-compose.yml：默认单 PD + 3 TiKV + 2 TiDB，含监控（Grafana/Prometheus）、Dashboard 和日志收集，适合开发/测试
- docker-compose-tiflash.yml：带 TiFlash 列存节点，支持实时 HTAP 场景
- docker-compose-binlog.yml：启用 MySQL 兼容 binlog 输出，便于对接下游同步工具
执行以下命令即可拉取并启动完整集群：
git clone https://gitee.com/mirrors/tidb-docker-compose.git<br>cd tidb-docker-compose && docker-compose pull && docker-compose up -d
保障高可用的关键配置项
真正影响高可用的不是“跑起来”，而是组件间能否协同容错。重点关注以下三点：
-
PD 多节点部署：单 PD 是单点瓶颈。至少启动 3 个 PD 实例（如 pd0/pd1/pd2），通过
--initial-cluster=pd0=http://pd0:2380,pd1=http://pd1:2380,pd2=http://pd2:2380构成 Raft Group，自动选举 leader -
TiKV 副本数调高：默认副本数为 3（
max-replicas=3）。在 docker-compose.yml 的 pd 服务 environment 中添加PD_CFG="--replication.max-replicas=3"，确保数据跨 TiKV 节点分散存储 - TiDB 实例无状态 + 多开：TiDB 层本身不存数据，启动多个实例（如 tidb0/tidb1）并绑定同一 PD 地址，客户端可轮询连接；配合 HAProxy 或应用层连接池实现负载与故障自动切换
验证高可用是否生效
启动后别急着连业务，先做三步检查：
- 运行
docker-compose ps确认所有容器状态为 Up，无 restarting 或 exited - 访问
http://localhost:2379/pd/api/v1/status（PD 监控接口），返回 JSON 中"is_leader": true/false应有且仅有一个 true；杀掉 leader 容器（docker-compose kill pd0），10 秒内刷新，确认新 leader 自动选出 - 用 MySQL 客户端连
mysql -h 127.0.0.1 -P 4000 -u root，执行show stats_meta;；再停掉一个 tikv 容器，观察查询是否仍成功（Raft 多数派机制保证读写持续可用）
避坑提醒：资源与网络设置
很多“高可用失败”其实源于基础配置疏漏：
-
内存必须充足：TiKV 默认内存限制 1GB，但实际运行需 ≥2GB/实例。在 docker-compose.yml 中为 tikv 服务添加
mem_limit: 2g，否则 OOM 后频繁重启 -
禁用 host 网络模式：Docker Compose 默认 bridge 网络已满足组件通信，强行用
network_mode: host反而破坏服务发现（如 pd 无法通过pd:2379被 tikv 访问） -
时区统一很重要：在所有服务 environment 中加
TZ=Asia/Shanghai，避免 PD 时间戳异常导致调度紊乱
