MySQL 8.0 官方不支持真正双写双活，所谓“双活”实为上层中间件（如ProxySQL）实现的读写分离与故障切换，数据库层仅能提供主从单向复制或需严防冲突的双主架构。
MySQL 8.0 主从双活不是标准架构——官方不支持真正意义上的双写双活（即两个节点同时接受写入并自动同步），强行配置双向复制极易引发主键冲突、GTID不一致、数据覆盖等灾难性问题。跨主机部署的「主从」只能是单向复制，所谓「双活」必须靠上层应用或中间件实现读写分离+故障切换，而非数据库自身能力。
以下聚焦真实可行的操作路径，避开宣传话术陷阱。
docker run 启动跨主机主从容器时，网络必须互通
两台宿主机（比如 host-a 和 host-b）上的 MySQL 容器，要完成主从复制，必须满足：
– 主库容器能被从库容器通过 IP:PORT 访问（不是 localhost 或 127.0.0.1）
– 从库容器能解析主库容器所在宿主机的 IP（建议直接用宿主机真实 IP，避免 DNS 不稳定）
– 宿主机防火墙放行主库端口（默认 3306），且 MySQL 用户授权允许远程连接
常见错误现象：ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.10' (111) 或 ERROR 1045 (28000): Access denied for user
- 不要用
--network host模式启动主库——它会让容器共享宿主机网络命名空间，但无法控制 MySQL 绑定地址，默认仍可能只监听127.0.0.1 - 主库容器启动时，必须显式设置
bind-address = 0.0.0.0（通过挂载自定义my.cnf实现），否则即使端口映射了，MySQL 进程也不接受外部连接 - 主库创建复制用户时，host 必须是具体 IP 或
%，不能是localhost：CREATE USER 'repl'@'192.168.1.20' IDENTIFIED BY 'replpass'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.20';
CHANGE REPLICATION SOURCE TO 的参数必须严格匹配主库 SHOW MASTER STATUS
从库执行 CHANGE REPLICATION SOURCE TO 前，必须先在主库执行 SHOW MASTER STATUS;，拿到当前 binlog 文件名和 position。这两个值一旦主库发生重启或 flush logs，就会变化，不能硬编码进脚本。
典型错误：从库 IO 线程报错 Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'，说明指定的 binlog 文件已在主库被 purge。
- 务必确认主库已开启
log-bin且server-id唯一（如主库设为1，从库设为2） -
SOURCE_HOST填的是主库宿主机 IP（不是容器 IP，因为跨主机），SOURCE_PORT是宿主机映射端口（如3306） -
SOURCE_USER/SOURCE_PASSWORD必须与主库创建的复制用户完全一致，注意大小写和特殊字符转义 - MySQL 8.0.23+ 强制使用
SOURCE_LOG_FILE和SOURCE_LOG_POS，不再支持旧版MASTER_LOG_FILE/MASTER_LOG_POS
跨主机场景下，数据卷挂载路径必须独立且可预测
主库和从库的数据目录（/var/lib/mysql）绝不能共用 NFS 或同一块网络盘——MySQL 数据文件不是 POSIX 兼容的，多实例并发写会导致元数据损坏。
正确做法：每台宿主机用本地磁盘挂载，路径明确区分，例如：
- host-a 上主库：
-v /data/mysql-master:/var/lib/mysql - host-b 上从库：
-v /data/mysql-slave:/var/lib/mysql
若用 docker volume，需确保 volume driver 支持跨主机（如 convoy 或企业级存储插件），普通 local volume 仅限单机。
容易被忽略的一点：mysql:8.0 镜像首次启动会初始化数据目录并生成 auto.cnf，该文件含唯一 server-uuid。如果误将主库数据目录拷贝给从库用，会导致复制拒绝启动（UUID mismatch）。从库数据目录必须为空或全新初始化。
没有真正的「双活」，只有「主备切换」或「读写分离」
所谓「双活」在 MySQL 层面不存在。你能做的只有两种现实方案：
-
主备模式：日常仅主库写，从库只读；主库宕机后，手动或通过脚本提升从库为主（
STOP REPLICA; RESET MASTER; CHANGE REPLICATION SOURCE TO ...），再修改应用连接地址——这需要业务容忍分钟级中断 -
读写分离模式：应用层识别 SQL 类型，
SELECT走从库，INSERT/UPDATE/DELETE固定走主库；可用ProxySQL或MaxScale实现自动路由，但它们本身是单点，需额外高可用
任何宣称「MySQL 原生双活」的方案，本质都是掩盖了数据冲突检测、补偿逻辑或最终一致性妥协——这些复杂度不在 Docker 配置里，而在你的业务代码或中间件中。
