一、主从复制架构设计原理

MySQL主从复制是一种基于二进制日志（Binary Log）的数据同步机制，通过将主库的DDL/DML操作实时传输到从库执行，实现数据的多副本存储。这种架构具有三大核心优势：读写分离提升系统吞吐量、数据热备保障业务连续性、地理分布优化访问延迟。

在容器化部署场景中，每个MySQL实例运行在独立的Docker容器中，通过挂载持久化卷实现数据持久化。这种部署方式既保持了轻量级特性，又通过容器编排工具实现了资源隔离和弹性扩展。建议采用”一主一从”基础架构起步，后续可根据业务需求扩展为级联复制或环形复制拓扑。

二、主库容器实例配置

1. 容器创建与参数说明

docker run -p 3307:3306 \
--name mysql-master \
-v /mydata/mysql-master/log:/var/log/mysql \
-v /mydata/mysql-master/data:/var/lib/mysql \
-v /mydata/mysql-master/conf:/etc/mysql \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql:5.7

关键参数解析：

-p 3307:3306：将容器3306端口映射到宿主机3307端口
-v参数组：实现日志、数据、配置的持久化存储
MYSQL_ROOT_PASSWORD：设置root用户初始密码
mysql:5.7：指定使用MySQL 5.7官方镜像

2. 主库配置优化

在/mydata/mysql-master/conf/my.cnf中配置以下参数：

[mysqld]
server_id=101                  # 唯一标识符
binlog-ignore-db=mysql         # 忽略系统库同步
log-bin=mall-mysql-bin         # 二进制日志前缀
binlog_cache_size=1M           # 事务缓存大小
binlog_format=mixed             # 混合格式记录
expire_logs_days=7             # 日志保留周期
slave_skip_errors=1062         # 跳过主键冲突错误

配置要点说明：

server_id必须保证整个复制集群唯一
binlog_format建议生产环境使用ROW格式，但需权衡存储开销
slave_skip_errors应根据实际业务场景配置，1062错误最常见于自增主键冲突

3. 同步用户创建

进入容器后执行：

CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
FLUSH PRIVILEGES;

安全建议：

限制同步用户来源IP（如'slave'@'192.168.1.%'）
使用强密码策略（建议16位以上混合字符）
定期轮换复制账户密码

三、从库容器实例配置

1. 从库容器创建

docker run -p 3308:3306 \
--name mysql-slave \
-v /mydata/mysql-slave/log:/var/log/mysql \
-v /mydata/mysql-slave/data:/var/lib/mysql \
-v /mydata/mysql-slave/conf:/etc/mysql \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql:5.7

2. 从库专属配置

在/mydata/mysql-slave/conf/my.cnf中添加：

[mysqld]
server_id=102                  # 必须与主库不同
log-bin=mall-mysql-slave1-bin  # 启用从库二进制日志（可选）
read_only=ON                   # 设置为只读模式

高级配置选项：

relay_log_space_limit：限制中继日志占用空间
sync_binlog：控制二进制日志写入磁盘频率
slave_parallel_workers：多线程复制线程数（MySQL 5.7+）

3. 复制链路初始化

在从库容器内执行：

CHANGE MASTER TO 
MASTER_HOST='宿主机IP',
MASTER_PORT=3307,
MASTER_USER='slave',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mall-mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE;

关键参数获取方法：

在主库执行SHOW MASTER STATUS获取当前日志文件和位置
确保网络连通性（建议使用宿主机IP而非容器名）

四、复制状态监控与故障处理

1. 实时状态检查

SHOW SLAVE STATUS\G

重点关注字段：

Slave_IO_Running：IO线程状态
Slave_SQL_Running：SQL线程状态
Seconds_Behind_Master：复制延迟（秒）
Last_IO_Error/Last_SQL_Error：错误信息

2. 常见故障处理

场景1：复制中断

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter=1;
START SLAVE;

场景2：数据不一致修复

在主库锁定表：FLUSH TABLES WITH READ LOCK;
导出主库数据：mysqldump -uroot -p --all-databases --master-data > dump.sql
在从库导入数据：mysql -uroot -p < dump.sql
重新配置复制链路

场景3：主从切换

提升从库为新主库：STOP SLAVE; RESET SLAVE ALL;
修改应用连接配置指向新主库
重建其他从库的复制链路

五、生产环境优化建议

资源隔离：为每个MySQL容器设置CPU/内存限制（--cpus和--memory参数）
监控告警：集成Prometheus+Grafana监控复制延迟、QPS等关键指标
备份策略：结合物理备份（Percona XtraBackup）和逻辑备份（mysqldump）
高可用方案：考虑使用Keepalived或容器编排工具实现自动故障转移
版本升级：主从版本建议保持一致，跨大版本升级需测试兼容性

六、扩展架构设计

级联复制：从库再作为其他从库的主库，形成复制链
多源复制：MySQL 5.7+支持从多个主库同步数据
GTID复制：启用全局事务标识符简化故障切换（gtid_mode=ON）
组复制：MySQL 8.0+的InnoDB Cluster提供原生高可用解决方案

通过上述完整配置流程，开发者可以构建出稳定可靠的MySQL主从复制环境。建议先在测试环境验证所有操作流程，再逐步迁移至生产环境。随着业务发展，可基于当前架构扩展为更复杂的高可用集群，满足不同业务场景的数据库需求。

Docker环境下MySQL主从复制的深度实践指南