MySQL 5.7增强版Semisync Replication性能优化

主要介绍了MySQL 5.7增强版Semisync Replication性能优化,本文着重讲解支持发送binlog和接受ack的异步化、支持在事务commit前等待ACK两项内容,需要的朋友可以参考下 MySQL 5.7增强版的Semisync Replication性能优化主要关注两个关键点：支持发送binlog和接受ACK的异步化以及支持在事务commit前等待ACK。这些改进旨在提高半同步复制模式下的系统事务处理能力，降低对总体吞吐量（TPS）的影响。 1. **支持发送binlog和接受ACK的异步化** 在早期版本的MySQL如5.5和5.6中，半同步复制的瓶颈在于dump线程。这个线程既要负责将binlog事件发送给从库，又要等待从库的ACK反馈，这两个任务是串行执行的。在高并发环境中，这种设计限制了数据库的整体TPS。为了解决这个问题，MySQL 5.7.4引入了一个新的ack collector thread，它专门用于接收从库的ACK反馈。这样，主库上的dump线程可以专注于发送binlog，而ack collector线程则独立地收集ACK，实现了发送和接收的并行，从而提高了效率。 实现方式是利用备库IO线程与主库之间的TCP连接，允许读写操作同时进行。在启用主库半同步时，启动ack collector线程，使用select系统调用来监听备库连接的socket。这样一来，即使在ack collector线程等待ACK时，dump线程也能继续发送下一组group commit的binlog事件，显著提升了TPS。 2. **支持在事务commit前等待ACK** MySQL 5.7引入了新的参数`rpl_semi_sync_master_wait_point`来控制主库在返回事务成功给客户端之前的行为。这个参数有两个可选值： - **AFTER_SYNC**（默认值）：主库在将事务写入binlog并传送到从库，且从库将binlog刷新到磁盘后，等待从库的ACK。主库在接收到ACK后才提交事务并返回结果给客户端。这种方式确保所有客户端看到的数据是一致的，即使主库崩溃，从库也能接替且数据丢失最小。 - **AFTER_COMMIT**：主库先将事务写入binlog，传送到从库并刷新到磁盘，然后在主库提交事务。之后，主库等待从库的ACK。在这种模式下，如果从库未应用日志，而主库崩溃，故障切换到从库时可能会发现数据不一致。 这些优化提高了MySQL 5.7在半同步复制环境下的性能，尤其是在高并发场景下，能够平衡数据一致性与系统性能。通过异步化处理ACK，主库可以更快地处理事务，而新的提交策略提供了灵活性，允许用户根据数据一致性和容错需求选择合适的等待点。这些改进使得MySQL 5.7在大型分布式系统中的表现更加强大和可靠。