mysql怎么配置主从

摘要： MySQL主从复制配置详解：从原理到实战一步到位目录导读主从复制原理简述配置前的环境准备主库（Master）配置详解从库（Slave）配置步骤启动与验证主从复制常见问题与故障排查（...

MySQL主从复制配置详解：从原理到实战一步到位

目录导读

1. 主从复制原理简述
2. 配置前的环境准备
3. 主库（Master）配置详解
4. 从库（Slave）配置步骤
5. 启动与验证主从复制
6. 常见问题与故障排查（Q&A）
7. 监控与维护建议

主从复制原理简述

MySQL主从复制是一种异步的数据复制技术，其核心原理是允许一个数据库服务器（主库）将其数据变更同步到一个或多个其他服务器（从库）,这个过程主要基于三个线程完成：

• 主库的 Binlog Dump 线程：当从库连接主库时，主库会创建一个Binlog Dump线程，负责读取主库的二进制日志（Binary Log）并发送给从库。
• 从库的 I/O 线程：负责连接主库，请求和接收主库的二进制日志事件，并将其写入本地的中继日志（Relay Log）。
• 从库的 SQL 线程：负责读取中继日志中的事件，并重放（执行）这些SQL语句,从而使得从库的数据与主库保持一致。

通过这种机制，实现了数据的冗余备份、读写分离和负载均衡。

配置前的环境准备

• 服务器：准备至少两台服务器（或容器/虚拟机），确保网络互通，防火墙已开放MySQL服务端口（默认3306）。
• MySQL版本：建议主从库的MySQL大版本一致，以避免兼容性问题，可通过 mysql -V 命令查看。
• 数据一致性：在配置前，如果主库已有数据，需要先将主库的数据完整导出，并导入到从库，保证起点一致，可以使用 mysqldump 工具。

主库（Master）配置详解

修改主库配置文件 编辑主库的MySQL配置文件 my.cnf（通常位于 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段落下添加或修改以下参数：

[mysqld]
# 设置服务器唯一ID，通常用IP最后一段
server-id = 1
# 启用二进制日志，日志文件名前缀
log_bin = /var/log/mysql/mysql-bin.log
# 设置需要复制的数据库（可选，多个则重复此行）
binlog-do-db = your_database_name
# 设置忽略复制的数据库（可选）
# binlog-ignore-db = mysql
# 确保事务提交先写入二进制日志，保证数据一致性
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

重启主库MySQL服务并创建复制用户

systemctl restart mysqld

登录主库MySQL，创建一个专用于复制的用户,并授予复制权限：

CREATE USER 'repl'@'从库IP地址' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP地址';
FLUSH PRIVILEGES;

查看主库状态并记录关键信息 执行以下命令，并记录下 File 和 Position 的值,从库配置时需要。

SHOW MASTER STATUS;

从库（Slave）配置步骤

修改从库配置文件 编辑从库的 my.cnf 文件：

[mysqld]
server-id = 2 # 必须唯一，且不能与主库相同
relay-log = /var/log/mysql/mysql-relay-bin.log
read_only = 1 # 设置从库为只读模式（建议，防止误写）

重启从库MySQL服务并配置主库连接

systemctl restart mysqld

登录从库MySQL，执行以下命令,填入主库信息：

CHANGE MASTER TO
MASTER_HOST = '主库IP地址',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'StrongPassword123!',
MASTER_LOG_FILE = '上一步记录的File值',
MASTER_LOG_POS = 上一步记录的Position值;

启动与验证主从复制

在从库上启动复制进程：

START SLAVE; -- 在MySQL 8.0.22+中，推荐使用 START REPLICA;

检查从库复制状态：

SHOW SLAVE STATUS\G; -- 或 SHOW REPLICA STATUS\G;

关键查看以下两个字段：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes 两者均为 Yes 表示主从复制正常运行，如果出现 No 或 Connecting，请查看后面的 Last_IO_Error 或 Last_SQL_Error 字段进行排查。

常见问题与故障排查（Q&A）

Q1: 主从复制延迟（Slave Lag）过大怎么办？ A1: 延迟是常见问题,可能原因及对策：

• 网络延迟：确保主从间网络带宽和稳定性。
• 从库硬件性能差：提升从库硬件配置（特别是磁盘I/O和CPU）。
• 大事务：避免在主库执行长时间运行的大事务,可拆分。
• 单线程复制瓶颈：在MySQL 5.6+版本，可启用并行复制（设置 slave_parallel_workers）。

Q2: 配置时出现 Last_IO_Error: error connecting to master 错误？ A2: 连接问题,请检查：

• 主库repl用户的IP授权是否正确，可用 通配符测试。
• 主从防火墙是否开放3306端口。
• 使用 telnet 主库IP 3306 测试网络连通性。

Q3: 从库的 Slave_SQL_Running 为 No，提示 Duplicate entry 主键冲突？ A3: 数据不一致导致，可临时跳过错误（谨慎操作）：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1; # 跳过1个事件
START SLAVE;

但根本解决方法是重新初始化从库数据,或根据错误位置进行数据手动修复。

Q4: 如何安全地切换主从角色进行故障转移？ A4: 这是进阶操作,基本步骤：

1. 在原有主库上执行 FLUSH TABLES WITH READ LOCK 阻止新写入。
2. 在从库上确认已追完所有日志，执行 STOP SLAVE。
3. 在从库上执行 RESET SLAVE ALL 清除复制信息，并关闭 read_only。
4. 将应用程序连接指向新的主库（原从库），更完善的方案建议使用 MHA、Orchestrator 等工具，或基于 ww.jxysys.com 上分享的脚本进行自动化演练。

监控与维护建议

• 日常监控：定期使用 SHOW SLAVE STATUS 监控复制状态和延迟 Seconds_Behind_Master，也可使用 Prometheus + Grafana 等可视化工具。
• 日志清理：定期清理主库的二进制日志和从库的中继日志，设置 expire_logs_days 参数。
• 备份：即使有从库,仍需对主库进行定期物理或逻辑备份。
• 版本升级：在升级MySQL版本前,务必在从库先行测试。

通过以上步骤，您应该已经成功搭建了一套MySQL主从复制环境，配置只是开始，持续的监控、定期的演练和及时的问题响应,才是保障数据库高可用的关键。