mysql怎么配置主从

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

目录导读

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

主从复制原理简述

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: 这是进阶操作,基本步骤：

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

监控与维护建议

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

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

正文