MySQL 半同步复制

MySQL 半同步复制自引入以来，经历了多个版本的迭代和优化，逐步增强了其功能和性能。

• MySQL 5.5：半同步复制首次引入。这个版本的半同步复制提供了基本的功能，确保了在事务提交并写入到主库的二进制日志（binlog）后，至少有一个从库确认接收到这些变更之后，事务才算完成。这减少了主从切换时数据丢失的风险，但在某些情况下可能会增加事务的延迟。
  功能增强

• MySQL 5.6：增加了对多线程从库（Multi-Threaded Slave, MTS）的支持。这个版本使得从库能够更有效地并行应用事务，提高了复制的性能。

• MySQL 5.7：

  • 引入了增强半同步复制，提供了更多的配置选项，如 rpl_semi_sync_master_wait_point，允许用户配置事务在提交过程中的等待点，是在 AFTER_SYNC 还是 AFTER_COMMIT。
  • 改进了自动回退到异步复制的机制，如果在指定的超时时间内没有从库确认，主库会自动回退到异步复制，以避免事务延迟。
  • 改善了与多线程从库的兼容性，提高了复制的吞吐量和性能。

• MySQL 8.0：

  • 继续优化了半同步复制的性能和可用性，包括对复制性能的进一步提升和对新特性的支持。
  • 引入了对新的复制特性的支持，如事务重放和延迟复制等，使得半同步复制在更复杂的部署场景中更加可靠和灵活。

半同步的两种方式

在 MySQL 半同步复制中，有两种复制方式：AFTER_SYNC和AFTER_COMMIT。主要区别是主库在事务提交过程中何时等待从库的确认，以及如何在数据一致性和复制延迟之间平衡。

使用rpl_semi_sync_master_wait_point 参数进行设置：

1. AFTER_SYNC（默认值）：当设置为 AFTER_SYNC 时，主库在将事务的二进制日志（binlog）同步到磁盘后，且在实际提交事务之前，等待至少一个从库的确认。这意味着，如果从库的确认没有在 rpl_semi_sync_master_timeout 指定的超时时间内到达，主库将回退到异步复制模式，但该事务已经安全地写入磁盘，准备提交。这种模式提供了较高的数据一致性保证，因为它确保了事务在提交前至少被一个从库接收。
2. AFTER_COMMIT：当设置为 AFTER_COMMIT 时，主库在提交事务之后，等待至少一个从库的确认。在这种模式下，即使从库的确认没有及时到达，事务也已经被提交，主库不会回退到异步复制模式。这种模式可能会稍微降低数据一致性的保证（相对于 AFTER_SYNC），因为事务已经提交，即使从库尚未确认接收。

选择 AFTER_SYNC 还是 AFTER_COMMIT 取决于你对数据一致性和复制延迟的具体需求。AFTER_SYNC 提供了更强的一致性保证，但可能会因为等待从库确认而增加事务的提交延迟。AFTER_COMMIT 可能会减少因等待从库确认而产生的延迟，但相对降低了数据一致性的保证。
这个参数的设置可以通过修改 MySQL 的配置文件 my.cnf 来进行：

[mysqld]
rpl_semi_sync_master_wait_point = AFTER_COMMIT

也可以在运行时通过 SQL 命令动态修改：

SET GLOBAL rpl_semi_sync_master_wait_point = 'AFTER_SYNC'; -- 或 'AFTER_COMMIT'

请注意，更改这个参数可能需要重新启动 MySQL 服务或至少重新加载配置，以使更改生效。

从最初的版本到现在，MySQL 半同步复制的演进主要集中在提高数据一致性、减少数据丢失风险、提升复制性能和增强系统的可用性上。通过引入新的配置选项和优化，MySQL 半同步复制成为了高可用性 MySQL 部署方案中的一个重要组成部分。