发布于 由admin

MySQL高级讲座篇之：半同步与全同步复制：高可用与性能的平衡艺术。

各位朋友，晚上好！今天咱们来聊聊MySQL高可用架构里一对相爱相杀的兄弟：半同步复制和全同步复制。别看名字只差一个字，背后的原理和适用场景可是大相径庭。咱们争取用最接地气的方式，把这俩兄弟的底裤都扒了，让大家以后在架构设计时，能根据实际情况，做出最明智的选择。

一、开场白：数据一致性的执念

在分布式系统中，数据一致性永远是绕不开的话题。想象一下，你正在网上抢购限量版球鞋，眼看着就要支付成功了，突然服务器宕机了！更可怕的是，好不容易恢复了，结果发现订单信息丢失了，这搁谁身上能忍？

所以，为了保证数据的可靠性和一致性，MySQL提供了多种复制方式，其中半同步和全同步复制就是为了解决这个问题而生的。

二、半同步复制：折中之道

半同步复制（Semi-Synchronous Replication），顾名思义，它不是完全同步，而是介于异步和全同步之间的一种折中方案。

工作原理：

  1. 主库（Master）提交事务后，必须至少收到一个从库（Slave）的确认，才会认为事务提交成功。
  2. 从库接收到主库发送过来的binlog日志后，写入relay log并刷盘，然后向主库发送一个ACK确认。
  3. 主库收到至少一个从库的ACK后，才会向客户端返回提交成功的消息。

优点：

  • 数据安全性提高： 至少保证有一个从库拥有最新的数据，降低了数据丢失的风险。
  • 性能影响较小： 相比全同步复制，性能损耗较小，因为只需要等待一个从库的确认。

缺点：

  • 仍然存在数据丢失的风险： 如果主库在提交事务后，还没收到任何从库的确认就宕机了，那么这部分数据仍然可能丢失。
  • 存在延迟： 从库需要接收、写入relay log并发送ACK，这会引入一定的延迟。

配置示例：

首先，你需要安装并启用半同步复制插件。

在主库上执行：

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_master_timeout = 10; -- 等待从库ACK的超时时间，单位秒
SET GLOBAL rpl_semi_sync_master_wait_point = AFTER_COMMIT; -- 在commit之后等待

在从库上执行：

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'rpl_semi_sync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

然后，你需要配置主从复制关系，这部分和普通的异步复制配置一样，这里就不赘述了。

注意事项：

  • rpl_semi_sync_master_timeout参数非常重要，它决定了主库等待从库ACK的超时时间。如果超过这个时间，主库会降级为异步复制模式。
  • 至少需要一个从库启用半同步复制插件，才能保证半同步复制正常工作。
  • 要确保从库的relay_log和relay_log_info已经配置且有效。

代码示例：

假设我们有一个简单的订单表 orders:

CREATE TABLE orders (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_number VARCHAR(255) NOT NULL,
    customer_id INT NOT NULL,
    total_amount DECIMAL(10, 2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

现在，我们在主库上插入一条新的订单记录：

INSERT INTO orders (order_number, customer_id, total_amount) VALUES ('ORD-20231027-001', 123, 99.99);

在半同步复制模式下，主库在提交这个事务后，会等待至少一个从库的确认。只有收到确认后，才会向客户端返回提交成功的消息。如果在超时时间内没有收到确认，主库会降级为异步复制模式，继续执行后续的事务。

三、全同步复制：强一致性的追求

全同步复制（Synchronous Replication），也称为同步复制，是一种追求极致数据一致性的方案。

工作原理：

  1. 主库提交事务后，必须等待所有从库都成功写入binlog日志，才会认为事务提交成功。
  2. 从库接收到主库发送过来的binlog日志后，写入relay log并刷盘，然后向主库发送一个ACK确认。
  3. 主库收到所有从库的ACK后，才会向客户端返回提交成功的消息。

优点：

  • 数据安全性极高： 理论上，所有从库都拥有最新的数据，保证了数据的一致性。
  • 零数据丢失： 即使主库宕机，也可以从任何一个从库恢复，不会丢失任何数据。

缺点：

  • 性能影响极大： 必须等待所有从库都确认，才能提交事务，性能损耗非常严重。
  • 可用性降低： 如果任何一个从库出现故障，都会导致主库无法提交事务，影响整个系统的可用性。

配置示例：

MySQL原生并不支持真正的全同步复制，但是通过一些插件或者第三方的解决方案可以实现类似的效果。例如，MySQL Group Replication (MGR) 是一个不错的选择，虽然严格来说不是全同步，但提供了非常强的最终一致性保证。

这里我们简单介绍一下MGR的配置（简化版，具体配置请参考官方文档）：

  1. 安装并配置MGR插件：
    在所有节点上安装group_replication插件。

    INSTALL PLUGIN group_replication SONAME 'group_replication.so';

  2. 配置MySQL服务器：
    在每个节点上修改my.cnf文件，添加以下配置：

    plugin_load_add = group_replication.so
group_replication_group_name = "my_group"
group_replication_start_on_boot = ON
group_replication_local_address = "node1:33061"  -- 每个节点不同
group_replication_group_seeds = "node1:33061,node2:33061,node3:33061" -- 所有节点的地址
binlog_checksum = NONE  -- MGR要求
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
transaction_write_set_extraction = XXHASH64

  3. 启动第一个节点：

    SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

  4. 启动其他节点：

    START GROUP_REPLICATION;

注意事项：

  • MGR对网络要求较高，需要保证节点之间的网络稳定。
  • MGR的配置比较复杂，需要仔细阅读官方文档。
  • MGR虽然提供了很强的一致性保证，但仍然不能完全避免脑裂等问题。

代码示例：

MGR的使用方式和普通的MySQL一样，你可以在任何一个节点上执行SQL语句。MGR会自动将数据同步到其他节点。

例如，在MGR集群中，我们在一个节点上插入一条新的用户记录：

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL UNIQUE
);

INSERT INTO users (username, email) VALUES ('Alice', '[email protected]');

这条记录会自动同步到MGR集群中的所有其他节点。

四、半同步 vs 全同步：选择困难症的终结者

特性 半同步复制 全同步复制 (MGR)
数据安全性 较高，至少保证有一个从库拥有最新数据 极高，所有节点都拥有最新数据
性能影响 较小，只需要等待一个从库确认 极大，需要等待所有节点确认
可用性 较高，主库可以降级为异步复制 较低，任何一个节点故障都可能影响整个集群
配置复杂度 简单 复杂
适用场景 对数据安全性有一定要求，但对性能要求较高的场景 对数据安全性要求极高，可以容忍性能损耗的场景

选择指南：

  • 金融、支付等核心业务： 优先考虑全同步复制 (MGR) 或类似的强一致性方案，保证数据的零丢失。
  • 电商、社交等非核心业务： 可以选择半同步复制，在数据安全性和性能之间取得平衡。
  • 读多写少的业务： 可以考虑采用读写分离架构，主库采用半同步复制，从库提供读服务。

五、进阶话题：脑裂与仲裁

在分布式系统中，脑裂（Split-Brain）是一个常见的问题。当集群中的节点由于网络故障等原因，无法相互通信时，可能会出现多个“大脑”，各自认为自己是主节点，导致数据不一致。

脑裂的危害：

  • 数据冲突：多个主节点同时写入数据，导致数据冲突。
  • 数据丢失：客户端可能连接到错误的主节点，导致数据丢失。

如何避免脑裂：

  • 仲裁机制： 当集群出现故障时，通过某种机制（例如投票）选出一个主节点，其他节点降级为从节点。
  • fencing (隔离)： 确保旧的主节点无法继续写入数据，防止数据冲突。

MySQL Group Replication (MGR) 内部就实现了仲裁机制，当集群中的节点数量超过一半时，才能选出一个主节点。这可以有效地避免脑裂问题。

六、总结：没有银弹，只有选择

今天我们一起探讨了MySQL半同步和全同步复制的原理、优缺点和适用场景。希望通过这次讲座，大家能够对这两种复制方式有更深入的了解，并在实际工作中，根据业务需求和系统架构，做出最合适的选择。

记住，没有银弹，只有选择。选择最适合自己的方案，才是王道！

最后，给大家留个思考题：

如果你的业务对数据安全性要求非常高，但是性能又不能太差，你会如何设计MySQL高可用架构？欢迎大家在评论区留言讨论！

谢谢大家！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注