semi-sync replicaiton的一个“有趣”bug

上周MySQL 5.6.13发布,“貌似”Oracle又开始拥抱社区,有些bug直接使用了社区开发者提交的补丁,这着实让人感到有些困惑与惊喜。看来MariaDB的确很好的牵制了Oracle对于MySQL的负面影响。然而,不管怎么说,5.6.13版本变得更为成熟与稳定。然其中的一个关于semi-sync replication的bug吸引了我。该bug由Facebook公司的MySQL工程师YOSHINORI MATSUNOBU提出。YOSHINORI MATSUNOBU何许人也?呵呵,在MySQL数据库界他可是真正的大拿。其开发影响力深远的产品非socket handler莫属,可以说对MySQL数据库本身产生了不可磨灭的影响。另外他也是MHA的开发者,相信很多公司都已根据MHA的原型实现了MySQL数据库的高可用。与此同时,他也是MySQL领域的Oracle ACE Director,可谓真正的名至实归。若将参数rpl_semi_sync_master_timeout设置为一个很大的值就会触发该bug。为什么需要设置为很大的值呢?因为用户不希望replication“轻易地”转化为异步模式。在网易开发的virtual sync replcation中,若用户希望得到数据的一致性并且不考虑的服务可用性,同样需要将该值设置为很大的一个数值。因此,在这种情况下就会触发该bug。在YOSHINORI MATSUNOBU的mysqlslap测试下,可以发现线程数越多,数据库性能的下降会非常明显:[shell]
1 client: 1239 inserts/s
10 clients: 767 inserts/s
20 clients: 478 inserts/s
50 clients: 216 inserts/s
100 clients: 90.0 inserts/s[/shell]
该bug最后由Libing Song修复,其是中国人,目前就职于Oracle。修复的patch也不大:[shell]
+ /* Calcuate the waiting period. */
+#ifdef __WIN__
+ abstime.tv.i64 = start_ts.tv.i64 + (__int64)wait_timeout_ * TIME_THOUSAND * 10;
+ abstime.max_timeout_msec= (long)wait_timeout_;
+#else
+ abstime.tv_sec = start_ts.tv_sec + wait_timeout_ / TIME_THOUSAND;
+ abstime.tv_nsec = start_ts.tv_nsec +
+ (wait_timeout_ % TIME_THOUSAND) * TIME_MILLION;
+ if (abstime.tv_nsec >= TIME_BILLION)
+ {
+ abstime.tv_sec++;
+ abstime.tv_nsec -= TIME_BILLION;
+ }
+#endif /* __WIN__ */
+
while (is_on())
{
if (reply_file_name_inited_)
@@ -686,22 +701,6 @@
kWho, wait_file_name_, (unsigned long)wait_file_pos_);
}

– /* Calcuate the waiting period. */
-#ifdef __WIN__
– abstime.tv.i64 = start_ts.tv.i64 + (__int64)wait_timeout_ * TIME_THOUSAND * 10;
– abstime.max_timeout_msec= (long)wait_timeout_;
-#else
– unsigned long long diff_nsecs =
– start_ts.tv_nsec + (unsigned long long)wait_timeout_ * TIME_MILLION;
– abstime.tv_sec = start_ts.tv_sec;
– while (diff_nsecs >= TIME_BILLION)
– {
– abstime.tv_sec++;
– diff_nsecs -= TIME_BILLION;
– }
– abstime.tv_nsec = diff_nsecs;
-#endif /* __WIN__ */[/shell]
可以发现patch对超时时间的判断进行了优化,之前需要通过变量tv_nsec来计算,因此需要不断地while。而当超时时间设置的比较大时,并且线程数比较多时,就会产生性能影响。目前Oracle官方仅在MySQL 5.6中修复了该bug,MySQL 5.5.33版本中该问题依旧。不过相信聪明的小伙伴们已经知道如何修复了吧

Avatar photo

About Blackford

这是个最好的时代,这是个最坏的时代,这是个充满希望的春天,这是个令人绝望的冬天,我们前面什么都有,我们前面什么都没有。梦想,让我们一次次的走远,又一次次的回头,一个关于人生的梦想还在不断奔跑,带着喜悦和疼痛,不过一切才刚刚开始,并且直到今天也远远没有结束
This entry was posted in 数据库技术, 架构运维 and tagged , , . Bookmark the permalink.

发表评论

电子邮件地址不会被公开。 必填项已用*标注