本文主要给大家简单讲讲排查mysql半同步复制问题详细步骤,相关专业术语大家可以上网查查或者找一些相关书籍补充一下,这里就不涉猎了,我们就直奔主题吧,希望排查mysql半同步复制问题详细步骤这篇文章可以给大家带来一些实际帮助又是;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
1。问题背景
,,,默认情况下,线上的mysql复制都是异步复制,因此在极端情况下,主备切换时,会有一定的概率备库比主库数据少,因此切换后,我们会通过工具进行回滚回补,确保数据不丢失。半同步复制则要求主库执行每一个事务,都要求至少一个备库成功接收后,才真正执行完成,因此可以保持主备库的强一致性。为了确保主备库数据强一致,减少数据丢失,尝试在生产环境中开启mysql的复制的半同步(semi-sync)特性。实际操作过程中,发现大部分实例半同步都可以正常运行,但有少部分实例始终开不起来(只能以普通复制方式运行),更奇葩的是同一个主机的两个实例,一个能开启,一个不能。最终定位的问题也很简单,但排查出来还是花了一番功夫,下文将描述整个问题的排查过程。
2。半同步复制原理
,,,mysql的主备库通过binlog日志保持一致,主库本地执行完事务,binlog日志落盘后即返回给用户;备库通过拉取主库binlog日志来同步主库的操作。默认情况下,主库与备库并没有严格的同步,因此存在一定的概率备库与主库的数据是不对等的。半同步特性的出现,就是为了保证在任何时刻主备数据一致的问题。相对于异步复制,半同步复制要求执行的每一个事务,都要求至少有一个备库成功接收后,才返回给用户。实现原理也很简单,主库本地执行完毕后,等待备库的响应消息(包含最新备库接收到的binlog(文件、pos)),接收到备库响应消息后,再返回给用户,这样一个事务才算真正完成。在主库实例上,有一个专门的线程(ack_receiver)接收备库的响应消息,并以通知机制告知主库备库已经接收的日志,可以继续执行。有关半同步的具体实现,可以参考另外一篇文章,mysql半同步(semi-sync)源码实现.
3 .问题分析
,,,前面简单介绍了半同步复制的原理,现在来看看具体问题。在主备库打开半同步开关后,问题实例的状态变量“Rpl_semi_sync_master_status"始终是,表示复制一直运行在普通复制的状态。
(1)修改rpl_semi_sync_master_timeout参数。
,,,半同步复制参数中有一个rpl_semi_sync_master_timeout参数,用以控制主库等待备库响应消息的时间,如果超过该值,则认为备库一直没有收到(备库可能挂了,也可能备库执行很慢,较主库相差很远),这个时候复制会切换为普通复制,避免主库的执行事务长时间等待。线上这个值默认是50 ms,简单想是不是这个值太小了,遂将其改到10年代,但问题依然不解。
(2)。打印日志
,,,排查问题最简单最笨的方法就是打日志,看看到底是哪个环节出了问题。主库和备库分别有rpl_semi_sync_master_trace_level和rpl_semi_sync_slave_trace_level参数来控制半同步复制打印日志。将两个参数值设置为80(64 + 16),记录详细日志信息,以及进出的函数调用。
从主日志可以看到在2016-01-04 18:00:30时,主库设置了半同步标记,并开始等待备库的响应,等待10 s后,仍然没有收到响应,则认为超时,遂将半同步模式关闭,切换为普通模式。但从奴隶日志来看,在2016-01-04 18:00:30已经将(mysql-bin。000006年,500717950)发送给主库,表示已经收到该日志。这就说明,主日志已经打了semi-sync标,奴隶收到了日志,并且也回了包,主人也确实等了10年代,就是没有收到包,所以就切换为普通复制。现在问题就变成了,为什么大师没有收到?
