September 29, 2013

semisync continue…

在前两天刚刚释放的MySQL5.7.2代码中,可以看到semisync终于做了进一步的改进;在之前用户线程的逻辑为: 1.在binlog写入文件后,调用semisync记录事务位点信息; 2.sync binlog(如果需要) 3.将事务提交; 4.等待备库ack; 该逻辑存在的问题是,当主库crash时,可能Binlog还没有传递到备库,这时候做一次主备切换,备库提升为新主库,老主库降级为新备库,这时候主备库是处于不一致状态的; 而在5.7.2中,可以使用如下逻辑: 1.在binlog写入文件后,记录事务位点信息; 2.sync binlog(如果需要) 3.等待备库ack; 4..将事务提交; 在新版本5.7.2中,增加了新的HOOK函数:after_sync,通过参数rpl_semi_sync_master_wait_point来控制,默认为AFTER_SYNC,如果设置为AFTER_COMMIT则在commit之前等待备库ack,这可以确保备库接受到了最新的binlog,即使主库随后crash掉,也可以在recovery阶段恢复,因为主库已经完成了prepare阶段; 尽管该特性仅存在于官方5.7.2中,使用MySQL5.6的同学也可以很容易的把这个特性port过来,因为代码的改动量非常小.但需要注意一个问题,即在rotate时,由于需要持有LOCK_log并等待所有preare的事务完成commit,而dump线程也需要持有LOCK_log来发送binlog,这里rotate, 用户线程等待ACK, dump线程三者很容易形成死锁。 解释下,rotate为什么要等待prepare的线程commit,由于我们默认使用的XA事务,在crash recovery时,会扫描最后一个binlog文件,找出其中的XID,然后再跟所有处于prepare状态的事务xid做对比,如果事务xid存在于binlog,则将该prepare的事务commit,否则rollback。 如果rotate时不等待prepare的事务commit,那么我们可能需要往前扫描多个binlog文件来 关于这个问题,有几种解决办法: 1.Mariadb版本,rotate线程无需等待prepare线程commit,而是在binlog中写入事件的方式,类似于给binlog做了个checkpoint。 2.MySQL5.7.2/FacebookMySQL5.6, 通过维护当前active的binlog尾部偏移量的方式来解除dump线程对LOCK_log锁的需求 原创文章,转载请注明: 转载自Simple Life 本文链接地址: semisync continue… Post Footer automatically generated by wp-posturl plugin for wordpress.