MySQL高可用与集群之：`MySQL`主从复制：异步、半同步和`GTID`的底层实现。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

MySQL高可用与集群之：MySQL主从复制：异步、半同步和GTID的底层实现

大家好，今天我们来深入探讨MySQL高可用架构中至关重要的一环：主从复制。主从复制是构建高可用、读写分离、备份恢复等多种架构的基础。我们将从异步复制、半同步复制到基于GTID的复制，逐一剖析它们的底层实现原理，并探讨各自的优缺点。

一、异步复制：默认的快速模式

异步复制是MySQL默认的复制方式。它的核心原理非常简单：

主库（Master）：主库负责处理所有的写操作（INSERT、UPDATE、DELETE等）。每当主库执行完一个事务，就会将该事务产生的二进制日志（Binary Log，简称binlog）写入磁盘。
从库（Slave）：从库启动两个线程：
- I/O线程（IO Thread）：负责连接主库，并请求主库发送binlog。
- SQL线程（SQL Thread）：负责读取I/O线程接收到的binlog，并将其应用到从库的数据中。

异步复制的流程可以概括为：

主库执行事务 -> 写入binlog -> 从库I/O线程请求binlog -> 主库发送binlog -> 从库I/O线程接收binlog -> 从库SQL线程应用binlog。

异步复制的优点：

性能高： 主库不需要等待从库确认，写操作几乎没有延迟。
简单易配置： 设置相对简单，是入门级复制的首选。

异步复制的缺点：

数据一致性风险： 这是最大的缺点。由于主库不需要等待从库确认，如果主库发生故障，而从库还没有完全同步最新的binlog，就会发生数据丢失，导致主从数据不一致。

异步复制的配置示例（my.cnf）：

主库配置：

[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW # 推荐使用ROW格式，更安全

从库配置：

[mysqld]
server-id=2
relay_log=relay-log-bin
log_slave_updates=1 # 允许从库记录binlog，用于级联复制
read_only=1 # 设置为只读模式，避免从库写入数据

# 启动复制
CHANGE MASTER TO
  MASTER_HOST='master_ip',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='repl_password',
  MASTER_LOG_FILE='mysql-bin.000001', #初始binlog文件名，需要先获取
  MASTER_LOG_POS=4; #初始binlog位置，需要先获取

START SLAVE;

要获取 MASTER_LOG_FILE 和 MASTER_LOG_POS，需要在主库执行 SHOW MASTER STATUS; 命令。

二、半同步复制：更安全的选择

半同步复制是对异步复制的改进，它引入了确认机制，一定程度上提高了数据安全性。

半同步复制的原理：

主库执行事务并写入binlog。
主库至少等待一个从库接收到binlog并将其写入relay log（中继日志）后，才会向客户端返回成功。

半同步复制的流程：

主库执行事务 -> 写入binlog -> 主库等待至少一个从库接收并写入relay log -> 主库向客户端返回成功 -> 从库SQL线程应用relay log。

半同步复制的优点：

数据安全性提高： 至少保证有一个从库拥有最新的数据，降低了数据丢失的风险。

半同步复制的缺点：

性能略有下降： 主库需要等待从库的确认，会增加写操作的延迟。
依赖网络： 如果所有从库都出现网络问题，主库会阻塞，影响写入性能。

半同步复制的配置：

首先，需要安装半同步复制插件。不同版本的安装方式可能略有不同，以MySQL 5.7为例：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'rpl_semi_sync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'rpl_semi_sync_slave.so';

SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

主库配置：

[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 10 # 超时时间，单位毫秒

从库配置：

[mysqld]
server-id=2
relay_log=relay-log-bin
log_slave_updates=1
read_only=1
rpl_semi_sync_slave_enabled = 1

CHANGE MASTER TO
  MASTER_HOST='master_ip',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='repl_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10; # 连接重试时间

START SLAVE;

半同步复制的重要参数：

rpl_semi_sync_master_enabled: 启用或禁用主库的半同步复制。
rpl_semi_sync_slave_enabled: 启用或禁用从库的半同步复制。
rpl_semi_sync_master_timeout: 主库等待从库确认的超时时间，超过这个时间，主库会切换回异步复制模式，直到有从库重新上线。这个是关键，需要根据网络环境进行调整。

三、GTID复制：更简洁、更可靠

GTID（Global Transaction Identifier）是全局事务标识符，它为每个事务分配一个全局唯一的ID。GTID复制是基于GTID的复制方式，它解决了传统复制的一些问题，例如：

自动处理故障转移： 切换主库后，从库可以自动找到正确的复制位置，无需手动指定binlog文件名和位置。
简化复制拓扑： 简化了复杂的复制拓扑，例如环状复制。
避免事务重复执行： GTID保证每个事务只会被执行一次，避免了数据不一致。

GTID的格式：

server_uuid:transaction_id

server_uuid：服务器的唯一UUID，在MySQL启动时生成。
transaction_id：事务的ID，在每个服务器上递增。

GTID复制的原理：

主库执行事务，并为该事务分配一个GTID。
主库将GTID和事务数据一起写入binlog。
从库接收到binlog后，记录已经执行的GTID。
从库在应用binlog时，会检查GTID是否已经执行过，如果已经执行过，则跳过该事务。

GTID复制的流程：

主库执行事务 -> 分配GTID -> 写入binlog（包含GTID） -> 从库接收binlog -> 从库检查GTID是否已执行 -> 从库应用binlog。

GTID复制的优点：

简化配置和管理： 无需手动指定binlog文件名和位置。
自动故障转移： 故障转移后，从库可以自动找到正确的复制位置。
数据一致性更好： 避免事务重复执行。

GTID复制的缺点：

需要升级到MySQL 5.6.10或更高版本： GTID是MySQL 5.6.10引入的特性。
binlog格式必须是ROW或MIXED： STATEMENT格式不支持GTID。
对事务的要求更高： 不支持非事务表的复制。
回滚操作需要特殊处理： 需要确保回滚操作也生成GTID，否则可能导致数据不一致。

GTID复制的配置：

主库配置：

[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=1

从库配置：

[mysqld]
server-id=2
relay_log=relay-log-bin
log_slave_updates=1
read_only=1
gtid_mode=ON
enforce_gtid_consistency=ON

启动复制：

CHANGE MASTER TO
  MASTER_HOST='master_ip',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='repl_password',
  MASTER_AUTO_POSITION=1; # 启用GTID自动定位

START SLAVE;

GTID复制的重要参数：

gtid_mode: 设置GTID模式，可选值：
- OFF: 禁用GTID。
- ON: 启用GTID。
- ON_PERMISSIVE: 允许创建没有GTID的事务 (不推荐)。
- OFF_PERMISSIVE: 允许创建有GTID的事务，但不强制 (不推荐)。
enforce_gtid_consistency: 强制GTID一致性，确保所有事务都具有GTID。可选值：
- OFF: 不强制GTID一致性。
- ON: 强制GTID一致性。
MASTER_AUTO_POSITION: 启用GTID自动定位。

GTID相关命令：

SHOW MASTER STATUS;: 查看主库的GTID执行位置。
SHOW SLAVE STATUS;: 查看从库的GTID执行位置。
SHOW VARIABLES LIKE 'gtid_executed';: 查看服务器已经执行的GTID集合。
SHOW VARIABLES LIKE 'gtid_purged';: 查看服务器已经purge的GTID集合。

四、不同复制模式的对比总结

特性	异步复制	半同步复制	GTID复制
数据一致性	最低	较高	最高
性能	最高	略低	较低
配置复杂度	最简单	较复杂	较复杂
故障转移	手动	手动	自动
版本要求	低	低	高 (5.6.10+)
Binlog格式	所有	所有	ROW/MIXED

五、深入理解Binlog格式：STATEMENT、ROW和MIXED

Binlog格式对复制的性能和数据一致性有着重要影响。MySQL支持三种Binlog格式：

STATEMENT： 记录SQL语句。
- 优点： binlog体积小，节省磁盘空间。
- 缺点： 在某些情况下可能导致数据不一致，例如使用了NOW()、RAND()等不确定性函数。
ROW： 记录每一行数据的变化。
- 优点： 确保数据一致性，即使使用了不确定性函数。
- 缺点： binlog体积大，占用磁盘空间。
MIXED： 混合使用STATEMENT和ROW格式。
- 优点： 兼顾了性能和数据一致性。
- 缺点： 需要MySQL根据SQL语句自动选择合适的格式，可能存在判断错误的情况。

建议： 在生产环境中，推荐使用ROW格式，因为它能够保证数据一致性。如果对性能要求非常高，可以考虑使用MIXED格式，但需要仔细测试，确保不会出现数据不一致的情况。使用GTID复制时，必须使用ROW或MIXED格式。

六、故障转移策略：手动与自动

在主从复制架构中，故障转移是一个至关重要的话题。

1. 手动故障转移：

当主库发生故障时，需要人工介入，将一个从库提升为新的主库。手动故障转移的步骤通常包括：

检测到主库故障。
选择一个合适的从库作为新的主库。 选择的原则通常是选择延迟最低的从库。
停止所有从库的复制。
在新的主库上执行STOP SLAVE; RESET MASTER;。
修改应用程序的连接配置，指向新的主库。
将其他从库指向新的主库，并启动复制。

手动故障转移的优点是简单易懂，但缺点是需要人工介入，恢复时间较长。

2. 自动故障转移：

自动故障转移使用一些工具（例如：MHA、Orchestrator、MySQL Group Replication）来自动检测主库故障，并自动将一个从库提升为新的主库。自动故障转移的优点是恢复时间短，减少了人工干预，但缺点是配置复杂，需要一定的维护成本。

七、复制延迟的监控与优化

复制延迟是主从复制中常见的问题，它会导致读写分离架构下，读取到的数据不是最新的。

监控复制延迟：

可以使用SHOW SLAVE STATUS;命令查看从库的复制状态，其中Seconds_Behind_Master字段表示从库落后主库的时间，单位是秒。

优化复制延迟：

优化SQL语句： 避免执行长时间运行的SQL语句。
调整硬件配置： 增加主库和从库的CPU、内存和磁盘I/O。
优化网络： 确保主库和从库之间的网络连接稳定。
并行复制： MySQL 5.6引入了并行复制，可以提高复制速度。
拆分大事务： 将大事务拆分成小事务。
使用更快的存储引擎： 例如，使用SSD代替机械硬盘。

八、主从复制的常见问题与解决方案

复制中断： 检查网络连接、磁盘空间、binlog是否损坏。
数据不一致： 检查binlog格式是否正确、是否存在未提交的事务。
复制延迟过高： 参见上面的优化建议。
GTID冲突： 通常是由于手动修改了binlog导致的，需要谨慎处理。

九、总结：选择适合你的复制方案

MySQL主从复制是构建高可用架构的重要基石。异步复制适用于对数据一致性要求不高，但对性能要求极高的场景。半同步复制在一定程度上提高了数据安全性，但会牺牲一定的性能。GTID复制简化了配置和管理，并提供了自动故障转移的能力，是构建高可用架构的推荐选择。在选择复制方案时，需要根据实际业务需求和硬件环境进行综合考虑。理解了底层原理，才能在遇到问题时快速定位并解决。掌握了不同模式的优缺点，才能选择最适合自己业务场景的方案。

MySQL高可用与集群之：MySQL主从复制：异步、半同步和GTID的底层实现

发表回复 取消回复

发表回复取消回复