一、技术架构选型与规划

在分布式系统设计中，数据库主从复制是提升可用性的核心方案。本方案采用Docker容器化部署MySQL 5.7版本，通过端口映射实现多实例隔离运行。相比传统物理机部署，容器化方案具有资源利用率高、环境一致性强的优势，特别适合开发测试环境和中小型生产环境。

主从复制架构包含三个关键组件：

主节点（Master）：负责处理所有写操作，生成二进制日志（binlog）
从节点（Slave）：异步复制主节点数据，提供读服务
复制通道：基于binlog的事件传输机制

建议采用”一主一从”基础架构起步，后续可扩展为”一主多从”或级联复制模式。容器间通过自定义网络实现高效通信，避免端口冲突问题。

二、主节点部署实施

2.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用户密码

2.2 主节点配置优化

进入容器配置目录创建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三种模式对比：
- STATEMENT：记录SQL语句，节省空间但可能产生不一致
- ROW：记录行变更，数据安全但日志量大
- MIXED：自动选择，平衡安全与效率
slave_skip_errors常见错误码：
- 1062：主键冲突
- 1032：数据不一致
- 1053：服务器宕机

2.3 复制账户创建

进入容器执行以下SQL：

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

权限说明：

REPLICATION SLAVE：核心复制权限
REPLICATION CLIENT：状态查询权限
*.*：表示所有数据库，也可指定特定库

三、从节点部署实施

3.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

3.2 从节点专项配置

从节点my.cnf配置差异点：

[mysqld]
server_id=102                  # 必须不同于主节点
log-bin=mall-mysql-slave1-bin  # 从节点也可开启binlog
relay-log=mysql-relay-bin      # 中继日志配置
read_only=1                     # 只读模式

新增参数说明：

relay-log：存储从主节点接收的变更事件
read_only：防止从节点误写入，超级用户仍可写入

3.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;

关键参数获取：

MASTER_LOG_FILE和MASTER_LOG_POS：在主节点执行SHOW MASTER STATUS获取
网络配置：建议使用容器自定义网络替代宿主机IP

四、运行监控与故障处理

4.1 复制状态检查

在从节点执行：

SHOW SLAVE STATUS\G

重点关注指标：

Slave_IO_Running：IO线程状态
Slave_SQL_Running：SQL线程状态
Seconds_Behind_Master：复制延迟（秒）

4.2 常见故障处理

场景1：复制中断
错误表现：Slave_IO_Running: No
解决方案：

检查网络连通性
验证复制账户权限
执行STOP SLAVE; START SLAVE;重启复制

场景2：数据不一致
错误表现：Last_IO_Error包含1032错误
解决方案：

临时设置slave_skip_errors=1032跳过错误
使用pt-table-checksum和pt-table-sync工具修复
重建复制关系（终极方案）

场景3：主从切换
操作步骤：

在主节点设置read_only=1
将从节点提升为主节点
重新配置其他从节点指向新主节点
验证数据一致性

五、性能优化建议

硬件配置：
- 主节点建议使用SSD存储
- 为binlog分配独立磁盘
- 容器资源限制建议：CPU 2核，内存4GB

参数调优：

# 主节点优化
sync_binlog=1                # 每次事务提交都写盘
binlog_group_commit_sync_delay=100  # 延迟提交优化
# 从节点优化
slave_parallel_workers=4     # 并行复制线程数
slave_pending_jobs_size_max=128M  # 复制线程队列大小

监控方案：
- 部署Prometheus+Grafana监控系统
- 关键指标：
  - 复制延迟时间
  - binlog文件增长速率
  - 复制线程状态

六、扩展性设计

级联复制：
```
Master → Slave1 → Slave2
```
配置要点：中间节点需同时配置主从参数

GTID复制：
启用全局事务标识简化故障恢复：

# 主从节点同时配置
gtid_mode=ON
enforce_gtid_consistency=ON

半同步复制：
安装半同步插件提升数据安全性：

# 主节点
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled=1;
# 从节点
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled=1;

通过以上完整方案实施，可构建出高可用的MySQL主从复制架构。实际生产环境中，建议结合容器编排工具实现自动化部署，并定期进行灾难恢复演练验证系统可靠性。对于超大规模部署场景，可考虑使用ProxySQL等中间件实现读写分离和负载均衡。

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