MySQL rpl_semi_sync_master_timeout相关的一件BUG

部署基于MySQL原生复制的HA系统时，发现在半同步模式下，半同步复制降级为异步复制的超时时间如果设得很长，会严重影响性能高，这是个很奇怪的现象。

组合不同参数，用sysbench做压力测试。

sysbench --db-driver=mysql  --mysql-db=test2 --mysql-host=srdsdevapp69  --mysql-table-engine=innodb --oltp-table-size=5000000 --num-threads=10 --max-time=10 --max-requests=0 --oltp-test-mode=complex --oltp-read-only=off --test=/opt/sysbench-0.5/sysbench/tests/db/insert.lua  run

结果如下：

rpl_semi_sync_master_enabled

rpl_semi_sync_master_timeout

qps

备注

on

21474836480

13.99

约248天

2147483648

196.3

约24.8天

214748364

1251.67

约2.5天

86400000

2146.96

1天

43200000

3211.17

12小时

21600000

3583.02

6小时

10000

3637.16

10秒(默认值)

off

-

8926.76

从上面的表不难看出，当rpl_semi_sync_master_timeout很大时，每个查询的执行时间和rpl_semi_sync_master_timeout成正比。

为什么会出现这么奇葩的事？翻开MySQL的代码，立刻真相大白！

plugin\semisync\semisync_master.cc：

点击(此处)折叠或打开

#define TIME_THOUSAND 1000            

#define TIME_MILLION 1000000    

#define TIME_BILLION 1000000000

...

int ReplSemiSyncMaster::commitTrx(const char* trx_wait_binlog_name,

                  my_off_t trx_wait_binlog_pos)

{

      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)//这个while循环是罪魁祸首！！！

      {

        abstime.tv_sec++;

        diff_nsecs -= TIME_BILLION;

      }

      abstime.tv_nsec = diff_nsecs;

}

上面有个while循环，循环次数等于rpl_semi_sync_master_timeout对应的秒数，也就是说，如果设置成300天的话，要循环25920000次，不慢才怪！

把那段代码中的while替换等价的写法后，问题解决。测出的qps在3700左右，和rpl_semi_sync_master_timeout无关。

# diff plugin/semisync/semisync_master.cc plugin/semisync/semisync_master.cc_bak

687,688c687,688

start_ts.tv_nsec + ((unsigned long long)wait_timeout_ % TIME_THOUSAND) * TIME_MILLION;

abstime.tv_sec = start_ts.tv_sec + (unsigned long long)wait_timeout_ / TIME_THOUSAND;

---

> start_ts.tv_nsec + (unsigned long long)wait_timeout_ * TIME_MILLION;

> abstime.tv_sec = start_ts.tv_sec;

注：上面的编译选项填的比较随意，从网上随便抄了后再改的，只求编译通过。