如何使用 Docker 持久化机制支持高可用集群的主从数据同步指南-Docker-PHP中文网

docker高可用主从集群的关键是数据持久化：必须挂载数据、配置、日志三类卷，确保server-id、master.info、rdb快照等元数据落盘；使用自定义网络与固定别名保障通信稳定；启用gtid或哨兵并持久化其状态，实现故障后无缝恢复。

如何使用 docker 持久化机制支持高可用集群的主从数据同步指南

用 Docker 实现高可用主从集群，关键不在容器本身，而在于让数据真正“落盘”且可复用。容器重启或迁移时，若数据只存在容器内部，主从状态、binlog 位点、RDB 快照等都会丢失，同步立刻中断。持久化不是附加项，而是主从能持续工作的前提。

主从节点各自需要独立且稳定的存储路径，不能共用同一目录，也不能依赖容器内默认路径：

数据卷：映射 /var/lib/mysql（MySQL）或 /data（Redis），确保数据库文件、redo log、relay log 等完整保留；
配置卷：挂载自定义 my.cnf 或 redis.conf，启用 log-bin、server-id、requirepass 等核心参数，避免因镜像默认配置导致复制失败；
日志卷：单独挂载 binlog、slow log、Redis AOF 文件等，便于排查同步延迟、断连原因，也方便做增量备份。

MySQL 的 server-id 和 Redis 的 replicaof 地址只是连接起点，真正决定同步连续性的，是持久化下来的复制元数据：

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

MySQL 从库的 master.info 和 relay-log.info 文件必须落在挂载卷内，否则容器重启后无法记住上次读到哪个 binlog 文件和 position；
Redis 2.8+ 使用 replication backlog 实现部分重同步，但该缓冲区内容不落盘——因此首次全量同步后的 RDB 文件必须持久保存，且从节点启动时需能加载该快照；
建议在启动脚本中检查 mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running)"，确认状态稳定后再对外提供服务。

Docker 网络重建、IP 变更、主机名漂移都会导致主从连接中断。解决方案不是靠重试，而是靠设计：

使用自定义 bridge 网络（如 docker network create mynet），为主从容器分配固定别名（--network-alias mysql-master），从节点配置中直接写别名而非 IP；
MySQL 主库授权必须绑定 hostname（如 'repl'@'mysql-slave'），而非 'repl'@'%'，配合 DNS 或 /etc/hosts 注入保障解析稳定；
Redis 若启用密码，主节点 requirepass 与从节点 masterauth 必须一致，且密码应通过环境变量注入配置文件，避免硬编码泄露。

高可用不是“容器秒级重启”，而是“数据状态无缝延续”。一次 master 宕机后，slave 切换为新 master 时，必须能继续提供服务并接受新 slave 同步：

MySQL 建议搭配 GTID（gtid_mode=ON + enforce_gtid_consistency=ON），这样 failover 后新 master 可准确告诉 slave “从哪个事务开始追”；
Redis 哨兵模式下，sentinel 配置也需挂载——其监控状态、主节点切换记录都存在本地文件中，不持久则哨兵无法判断历史故障；
所有节点的时钟必须同步（NTP 或 docker run --cap-add=SYS_TIME），否则 MySQL 的 GTID 时间戳或 Redis 的复制偏移校验会出错。