从源码探究MySQL5.7高吞吐事务量的背后操手(2)

通过观察上述函数,我们可以看到有个rpl_semi_sync_master_wait_point变量与WAIT_AFTER_SYNC比较,如果不相等,则直接返回,直接返回则表示不需要在此时此刻确认binlog是否已经同步.而这个变量的取值来自于半同步参数semi_sync_master_wait_point的初始设置,我们可以设置为after_sync与after_commit.

这两个参数含义的区别是：after_sync是在将binlog sync到disk之后(具体是否真正sync由参数sync_binlog的值决定)进行日志同步确认,而after_commit是将事务完成在InnoDB里面提交之后再进行binlog的同步确认.两者确认的时间点不同,after_sync要早于after_commit.

接下来,我们来看repl_semisync.commitTrx 这个函数,这个函数有两个传入参数,一个是binlog文件,一个binlog文件的位移.我们来看这个函数的含义吧.算了,还是直接用源码的注释来解释吧.

上面的注释说得相当清楚,就是该commiTRX函数会等待binlog-dump返回已经同步到该位置的报告,如果还没有同步到该位置,则继续等待,直到超时返回.

当会话线程收到该函数的返回时,事务的提交过程继续往下走,直至在InnoDB真正提交.

总结

通过上述对MySQL的事务提交过程中的前段分析,应该可以了解Semi-sync的同步机制与异步机制的区别.

Semi-sync的主从同步机制与异步机制在同步的处理方式上无任何区别,唯一的区别就是Semi-sync在事务提交中段(假如设置为after_sync)或者提交后的阶段(after_commit),有一个验证该事务涉及的binlog是否已经同步到从库.而这个同步验证,会拉长整个事务的提交时间,因为事务提交在数据库中几乎是串行(如果按Group Commit为一个单位,就算是完全地串行),这是影响MySQL吞吐量的关键点,当这个关键点被拉长,对全局的影响就被放大.虽然仅仅多了这么一个确认的动作,但主库处于Semi-sync的同步状态与异步状态的吞吐量相比,相差了好几倍.

上述解释就是其真正的原因.

作者介绍：

徐春阳,笔名happypig.曾任职于阿里、百度、京东、即刻搜索,目前供职民生银行总行科技部,从事数据库运维工作.对开源数据库MySQL有较深入的研究,个人博客：xuchunyang.com.

（编辑：ASP站长网）