深入理解半同步复制

 

先看下节点间的半同步复制时序图(注:半同步复制相关图示均源自王松磊@Ucloud)

深入理解半同步复制_第1张图片

5.7版本之后新增ack线程(单线程工作)用于接受应答,分摊dump线程的压力(老版本需要兼顾发送binlog和接受应答,这两个操作又是串行的)。

 

rpl_semi_sync_master_wait_point:AFTER_COMMIT;5.7版本开始默认为 AFTER_SYNC

两者区别在于,after_commit:binlog 传递到从库的relay log,同时主库提交事务但暂时不向客户端反馈 commit ok 的消息,直到收到ACK才反馈该消息。

after_sync:主库持续等待直到收到ACK之后,一并提交事务并向客户端反馈 commit ok 的消息。

 

下面为两者时序图,重点关注 Egine Commit 的时机

深入理解半同步复制_第2张图片

 

深入理解半同步复制_第3张图片

 

我们再次看下第一张半同步复制时序图,假设数据库并发量较大,势必会出现这样一种情况:worker线程需要往binlog写数据,而dump线程也需要读binlog并发送给从库的io线程。这就产生了一个并发的问题。解决并发的办法要么是事务要么就是锁了。5.7版本以前,利用的是互斥锁,将并发操作强行串行化。到了5.7版本,dump线程将不会产生互斥锁(worker线程是写操作,依然产生互斥锁)。示意图如下:

深入理解半同步复制_第4张图片

深入理解半同步复制_第5张图片

 

深入理解半同步复制_第6张图片

 

半同步复制退化为异步复制后,当重新收到从库的应答后可以重新恢复为半同步复制:

在事务提交时, 主库的worker线程会在半同步插件记录当前的binlog的文件名和位置点。从库IO线程在记录完relay log后, 会将relay log对应的主库的binlog的文件名和位置加到应答包中。 Dump线程在接受到应答后, 会对比slave发送的应答和半同步插件中记录的内容, 如果从库的复制已经追赶上主库,那么就恢复半同步复制。

 

 

参考文档:

MySQL 5.5 Semi-sync Replication安装配置、参数说明

5.7半同步复制新特性

 

你可能感兴趣的:(MySQL)