主从服务器配置详细步骤是什么?新手必看指南!
- 云服务器
- 2025-12-17
- 7
主从服务器配置是数据库管理中一种常见的高可用性和读写分离架构,通过将主数据库(Master)的数据实时或异步复制到从数据库(Slave),实现数据冗余、负载均衡和故障恢复,以下从配置原理、环境准备、具体步骤、常见问题及优化建议等方面详细说明主从服务器配置的全过程。
主从服务器配置原理
主从复制的核心是基于数据库的binlog(二进制日志)机制,主服务器开启binlog功能,记录所有数据修改操作(增删改),从服务器通过I/O线程读取主服务器的binlog,并将其写入本地的中继日志(Relay Log),然后通过SQL线程中继日志中的事件,在从服务器上重新执行,从而实现数据同步,整个过程涉及三个关键线程:
- 主服务器:Binlog Dump线程,负责将binlog发送给从服务器。
- 从服务器:I/O线程,负责接收主服务器的binlog并写入中继日志;SQL线程,负责执行中继日志中的事件,更新数据。
根据同步方式,主从复制可分为:
- 异步复制:主服务器不等待从服务器确认,性能高但可能存在数据延迟。
- 半同步复制:主服务器至少等待一个从服务器接收binlog后才提交事务,平衡了性能与数据一致性。
环境准备
- 服务器要求:至少两台服务器,分别作为主(Master)和从(Slave),操作系统建议相同(如CentOS 7+),数据库版本一致(如MySQL 5.7+/8.0)。
- 网络配置:确保两台服务器网络互通,关闭防火墙或开放数据库端口(默认3306)。
- 数据库安装:两台服务器均安装相同版本的MySQL,并确保服务正常运行。
示例环境:
| 角色 | IP地址 | 操作系统 | MySQL版本 |
|||||
| Master | 192.168.1.10 | CentOS 7.9 | MySQL 8.0 |
| Slave | 192.168.1.20 | CentOS 7.9 | MySQL 8.0 |
主从服务器具体配置步骤
(一)主服务器(Master)配置
-
修改MySQL配置文件
编辑主服务器的MySQL配置文件(通常为/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf),添加以下内容:
保存后重启MySQL服务:systemctl restart mysqld。
-
创建用于复制的用户
登录主服务器MySQL,创建具有复制权限的用户(如repl_user),并设置密码:
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'Repl_Password123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES; -
获取主服务器当前binlog位置
执行以下命令,记录File和Position值,后续从服务器配置需要用到:
SHOW MASTER STATUS;
示例输出:
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
|||||
| mysqlbin.000003 | 156 | | mysql |
-
修改MySQL配置文件
编辑从服务器的MySQL配置文件,添加以下内容:

保存后重启MySQL服务:systemctl restart mysqld。
-
配置主从连接信息
登录从服务器MySQL,执行CHANGE REPLICATION SOURCE TO命令(MySQL 8.0+),旧版本使用CHANGE MASTER TO:
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.10', # 主服务器IP SOURCE_PORT=3306, # 主服务器端口 SOURCE_USER='repl_user', # 复制用户名 SOURCE_PASSWORD='Repl_Password123!', SOURCE_LOG_FILE='mysqlbin.000003', # 主服务器binlog文件名 SOURCE_LOG_POS=156; # 主服务器binlog位置执行后启动从服务器复制线程:
START REPLICA; -
验证复制状态
执行以下命令,检查从服务器状态:
SHOW REPLICA STATUSG;关键参数说明:
- Source_Host:主服务器IP,确认配置正确。
- Replica_IO_Running:应为Yes,表示I/O线程正常。
- Replica_SQL_Running:应为Yes,表示SQL线程正常。
- Last_IO_Error/Last_SQL_Error:若为空,表示无错误;否则需根据错误信息修复。
-
复制延迟
- 原因:从服务器处理能力不足、主服务器写入压力大、网络延迟等。
- 解决:
- 优化从服务器硬件(CPU、内存、磁盘I/O)。
- 调整replica_parallel_workers参数(MySQL 5.7+支持多线程复制),提升SQL线程处理能力。
- 对主服务器进行读写分离,降低写入压力。
-
主从数据不一致
- 原因:人为直接修改从服务器数据、binlog格式不兼容、网络中断导致复制中断等。
- 解决:
- 禁止直接操作从服务器数据,所有修改通过主服务器执行。
- 定期使用pttablechecksum(Percona工具)校验主从数据一致性,发现不一致后通过pttablesync修复。
-
主服务器故障切换
- 当主服务器宕机时,需手动或自动将从服务器提升为主服务器,并调整原主服务器为从服务器(修复后)。
- 自动切换方案:使用MHA(Master High Availability)或Orchestrator工具,实现故障自动检测和主从切换。
- 停止从服务器复制线程:STOP REPLICA;。
- 备份从服务器被误写入的数据(若需保留)。
- 清除从服务器的中继日志和relaylog.info:RESET REPLICA ALL;。
- 重新配置主从连接(CHANGE REPLICATION SOURCE TO),并启动复制:START REPLICA;。
- 使用pttablechecksum校验数据一致性,确保同步正常。
- MySQL命令:定期执行SHOW REPLICA STATUSG;,检查Replica_IO_Running和Replica_SQL_Running是否为Yes,以及Seconds_Behind_Master(延迟秒数)。
- 脚本监控:编写Shell或Python脚本,通过解析SHOW REPLICA STATUS输出,设置告警规则(如延迟超过30秒、线程异常时发送邮件或短信通知)。
- 第三方工具:使用Prometheus+Grafana配合MySQL Exporter插件,可视化展示复制延迟、线程状态等指标;或使用Zabbix、Percona Monitoring and Management(PMM)等专业监控工具。
常见问题及优化建议
相关问答FAQs
问题1:主从复制过程中,如果从服务器 accidentally 被写入数据,如何处理?
解答:
若从服务器被写入数据,会导致与主服务器数据不一致,处理步骤如下:
问题2:如何监控主从复制的健康状态?
解答:
可通过以下方式监控主从复制状态:
通过以上配置和优化,主从服务器架构可有效提升数据库的可用性和性能,适用于中小型业务场景,对于大规模高并发场景,建议结合读写分离、分库分表等技术进一步优化。


(二)从服务器(Slave)配置