深入解析MySQL主从复制原理：异步复制

lzyever

于 2024-04-12 12:38:45 发布

阅读量1.2k

点赞数 21

分类专栏： MySQL 文章标签： mysql

本文链接：https://blog.csdn.net/lzyever/article/details/137652591

版权

32 篇文章 0 订阅

订阅专栏

MySQL异步复制是一种广泛使用的数据复制技术，允许数据库系统中的数据在主服务器（Master）和从服务器（Slave）之间异步地传播和同步。

1.基本流程

事务处理与binlog记录：
- 客户端向主服务器发起写操作（如INSERT、UPDATE、DELETE等）。
- 主服务器执行这些操作，并将它们封装在一个或多个事务中。
- 事务完成后，主服务器将事务的所有更改记录到其本地的二进制日志（Binary Log, binlog）。binlog按顺序记录所有数据修改事件，每个事件包含操作类型、涉及的表名、行数据变化等信息。
binlog传输：
- 主服务器上运行一个名为binlog dump线程的后台进程，负责监听从服务器的复制请求。
- 当从服务器连接到主服务器并请求复制时，binlog dump线程开始读取binlog中的事件，并通过网络将其发送到从服务器。

连接与初始化：
- 从服务器启动一个I/O线程，该线程连接到主服务器并请求从某个特定的binlog位置（如最后一次同步的位置）开始复制。
- I/O线程接收到主服务器发来的binlog事件流。
中继日志（Relay Log）：
- I/O线程接收到binlog事件后，将其写入到从服务器本地的中继日志（Relay Log）。中继日志的作用是临时存储从主服务器接收的binlog事件，以便后续重放。
事件重放：
- 另一个在从服务器上运行的SQL线程负责读取中继日志中的事件，并按照事件在binlog中的顺序在从服务器上重新执行这些操作。
- SQL线程执行事件时，实际上是在从服务器上重建主服务器上发生的相同数据更改，从而保持数据的一致性。

低延迟：异步复制的最大优点是主服务器在提交事务后不需要等待从服务器的确认，直接返回给客户端事务已成功。这种设计使得主服务器能够迅速响应写操作，保证了数据库系统的写入性能。
数据不一致窗口：由于主从之间存在异步性，从服务器可能由于网络延迟、处理速度差异等原因，相对于主服务器存在一定的数据延迟。这意味着在某一时刻，主从服务器上的数据可能存在不一致。这种不一致通常短暂存在，一旦从服务器赶上主服务器，数据将再次变得一致。
潜在的数据丢失风险：如果主服务器在事务提交后、尚未将这些事务的binlog事件发送到从服务器之前发生故障，且主服务器上的binlog未能妥善备份，那么这部分未复制到从服务器的事务将永久丢失。对于无法接受数据丢失的应用场景，可能需要结合其他数据保护措施，如定期全备+增量备份、使用半同步复制等。
故障隔离：从服务器故障不会直接影响主服务器的运行。主服务器继续处理客户端请求并更新binlog，待从服务器恢复后，可以从断开连接的位置继续复制。
可扩展性与读负载分担：通过配置多个从服务器，可以实现数据的多副本冗余，提高数据可用性。同时，从服务器可以承担读查询的负载，实现读写分离，减轻主服务器的压力。

复制过滤：可以通过配置复制规则（replication filters）来指定哪些数据库、表或特定SQL模式应参与复制，从而实现数据分区或只复制部分数据到从服务器。
监控与故障排查：需要对主从复制状态进行持续监控，包括检查复制延迟、识别复制错误、跟踪中继日志使用情况等。MySQL提供了诸如SHOW SLAVE STATUS、SHOW MASTER STATUS等命令以及各种系统变量来帮助管理员了解复制状态和进行故障排查。
故障恢复：在复制过程中出现故障时，可能需要手动干预以重新同步主从关系，如执行STOP SLAVE; CHANGE MASTER TO ...; START SLAVE;等命令，或者使用备份恢复数据后重新配置复制。

MySQL异步复制是一种高效、易于配置的数据复制机制，适用于对数据一致性要求不高但对写入性能敏感的场景。尽管存在短暂的数据不一致性和潜在的数据丢失风险，但通过合理的监控、故障恢复预案以及与其他复制策略（如半同步复制、延迟复制）的结合使用，可以构建出既满足业务需求又具备高可用特性的数据库系统。

关注