mysql主从复制的原理是基于二进制日志（binlog），主服务器将数据变更记录到binlog中，从服务器通过i/o线程请求并接收binlog事件，写入中继日志（relay log），再由sql线程读取中继日志并重放，从而实现数据同步；1. 主服务器开启binlog并设置唯一server-id；2. 创建复制专用用户并授权；3. 锁定主库获取binlog文件名和位置；4. 配置从服务器的server-id和relay log；5. 执行change master to指定主库连接信息及binlog位置；6. 启动start slave开启复制；7. 检查show slave status中slave_io_running和slave_sql_running为yes且seconds_behind_master接近0表示同步正常；主从延迟可通过优化网络、提升硬件、拆分大事务、启用多线程复制（设置slave_parallel_workers）等方式解决；数据不一致时应先stop slave，排查不一致范围后通过sql修复或使用pt-table-sync工具重新同步，再start slave恢复复制；读写分离可在应用层、中间件（如mycat、shardingsphere）或代码层（如spring的abstractroutingdatasource）实现，需注意主从延迟导致的数据一致性问题及主库故障时的切换机制；监控主从状态可通过show slave status、zabbix、prometheus等工具或自定义脚本实现，重点关注复制线程状态和延迟时间，确保系统稳定运行。
MySQL主从复制，简单来说，就是把一台MySQL服务器（主服务器）的数据变更同步到一台或多台其他的MySQL服务器（从服
务器）。这是一种常用的数据备份和读写分离策略。
MySQL主从复制的配置与常见问题解决。
MySQL主从复制的原理是什么？
MySQL主从复制基于二进制日志（binlog）。主服务器记录所有数据变更操作到binlog中，从服务器连接到主服务器后，会请求主服务器的binlog，并将这些变更应用到自身，从而保持与主服务器的数据同步。 具体流程大致如下：
- 主服务器开启binlog: 这是复制的基础。
- 从服务器建立连接: 从服务器配置连接主服务器的信息（IP地址、端口、用户名、密码等）。
- 从服务器请求binlog: 从服务器向主服务器发送请求，获取binlog事件。
- 主服务器发送binlog: 主服务器将binlog事件发送给从服务器。
- 从服务器应用binlog: 从服务器接收到binlog事件后，将其应用到自身的数据中，完成数据同步。
这个过程看似简单，但实际配置和维护中会遇到各种问题。
如何配置MySQL主从复制？
配置MySQL主从复制主要涉及以下步骤：
-
配置主服务器:
- 修改主服务器的
my.cnf
配置文件，开启binlog功能。[mysqld] log-bin=mysql-bin # 开启binlog，并指定binlog的文件名 server-id=1 # 设置服务器ID，主服务器ID必须唯一 binlog_format=ROW # 推荐使用ROW格式，保证数据一致性
- 重启MySQL服务。
- 创建一个用于复制的用户，并授予相应的权限。
CREATE USER 'replication_user'@'%' IDENTIFIED BY 'your_password'; GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%'; FLUSH PRIVILEGES;
- 锁定主服务器，获取当前binlog的文件名和位置。
FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;
记录下
File
和Position
的值，稍后从服务器配置需要用到。 - 解锁主服务器。
UNLOCK TABLES;
- 修改主服务器的
-
配置从服务器:
- 修改从服务器的
my.cnf
配置文件。[mysqld] server-id=2 # 设置服务器ID，从服务器ID必须唯一，且不能与主服务器相同 relay-log=relay-mysql-bin # 开启relay log，并指定relay log的文件名
- 重启MySQL服务。
- 在从服务器上执行
CHANGE MASTER TO
命令，配置连接主服务器的信息。CHANGE MASTER TO MASTER_HOST='主服务器IP地址', MASTER_USER='replication_user', MASTER_PASSWORD='your_password', MASTER_LOG_FILE='之前记录的File值', MASTER_LOG_POS=之前记录的Position值;
- 启动从服务器的复制线程。
START SLAVE;
- 检查复制状态。
SHOW SLAVE STATUS\G;
关注
Slave_IO_Running
和Slave_SQL_Running
是否都为Yes
，以及Seconds_Behind_Master
的值。
- 修改从服务器的
主从复制延迟问题如何解决？
主从复制延迟是一个常见的问题，原因有很多，例如：
- 网络延迟: 主从服务器之间的网络状况不佳。
- 主服务器负载过高: 主服务器处理大量写操作，导致binlog生成速度慢。
- 从服务器硬件性能不足: 从服务器无法及时应用binlog事件。
- 大事务: 主服务器执行大事务，导致从服务器需要花费较长时间才能同步。
解决延迟问题可以尝试以下方法：
- 优化网络: 确保主从服务器之间的网络连接稳定、快速。
- 优化主服务器: 减少主服务器的负载，例如优化SQL语句、调整MySQL参数等。
- 升级从服务器硬件: 提高从服务器的CPU、内存、磁盘I/O性能。
- 拆分大事务: 尽量避免在主服务器上执行大事务。
-
使用多线程复制: MySQL 5.6之后支持多线程复制，可以提高从服务器的应用binlog的速度。可以通过调整
slave_parallel_workers
参数来启用多线程复制。 -
监控复制状态: 实时监控
Seconds_Behind_Master
的值，及时发现并解决问题。
主从复制数据不一致如何处理？
数据不一致也是一个可能出现的问题，常见原因包括：
- 网络中断: 主从服务器之间的网络连接中断，导致binlog事件丢失。
- 人为错误: 在主服务器或从服务器上执行了错误的SQL语句。
- Bug: MySQL本身的Bug。
解决数据不一致问题通常需要以下步骤：
-
停止从服务器的复制线程。
STOP SLAVE;
- 确定数据不一致的范围。
-
修复数据。 修复方法取决于数据不一致的范围和原因。
- 如果数据不一致的范围较小，可以直接在从服务器上执行相应的SQL语句进行修复。
- 如果数据不一致的范围较大，可以考虑从主服务器重新同步数据。
- 可以使用
pt-table-sync
工具进行数据同步。
-
重新启动从服务器的复制线程。
START SLAVE;
- 监控复制状态，确保数据同步正常。
如何实现读写分离？
主从复制的一个重要应用就是读写分离。读写分离可以将读操作分发到从服务器，从而减轻主服务器的压力。
实现读写分离通常需要以下步骤：
- 应用程序配置: 应用程序需要能够识别读操作和写操作，并将读操作路由到从服务器，将写操作路由到主服务器。
- 使用中间件: 可以使用一些中间件来实现读写分离，例如MyCat、ShardingSphere等。这些中间件可以自动将读操作路由到从服务器，将写操作路由到主服务器。
- 代码层实现: 也可以在代码层实现读写分离，例如使用Spring的AbstractRoutingDataSource。
读写分离可以显著提高系统的性能和可用性，但需要注意以下几点：
- 数据一致性: 由于主从复制存在延迟，可能会出现数据不一致的情况。需要在应用程序中处理这种不一致性。
- 故障切换: 当主服务器发生故障时，需要将从服务器切换为主服务器。需要在应用程序中实现故障切换逻辑。
- 事务: 读写分离可能会影响事务的完整性。需要仔细考虑事务的边界。
如何监控MySQL主从复制的状态？
监控MySQL主从复制的状态非常重要，可以及时发现并解决问题。常用的监控方法包括：
-
查看
SHOW SLAVE STATUS
的输出。 关注Slave_IO_Running
、Slave_SQL_Running
、Seconds_Behind_Master
等指标。 - 使用监控工具。 可以使用一些监控工具来监控MySQL主从复制的状态，例如Zabbix、Prometheus等。这些工具可以提供更详细的监控信息，并可以设置报警规则。
- 编写自定义脚本。 可以编写自定义脚本来监控MySQL主从复制的状态，并将监控结果发送到报警系统。
通过监控MySQL主从复制的状态，可以及时发现并解决问题，保证系统的稳定运行。
