OneSQL :: 基于MySQL 5.7.17版本并行恢复,测试RealSync数据保护补丁性能。

MySQL官方的SemiSync补丁不能等待备库恢复完成再响应客户端,在某些场景下正有此需求,在MySQL 5.6下由于单库只能以单线程恢复,所以复制延迟是常见现象。MySQL 5.7的并行复制功能,将会终结备库延迟现象吗?在极端情况下,主库的事务并发能力仍远超备库,只要业务压力够大,还是有复制时延现象存在的。这就需要OneSQL的RealSync功能来保证主备无复制时延了(默认配置为不自动降级模式),因为它可以让主库等待备库回放结束后再响应客户端。那么在各种不同的的数据保护级别下,到底能支持多少事务呢?下面是在PCIE-Flash上测试的结果:

onesql_57_realsync_benchmark

使用两个场景来测试主备复制的时延情况(20个表,每个表20万条数据):

  • sysbench的update_non_index场景,256个并发。
  • sysbench的oltp场景,禁用所有查询语句,只保留4个DML语句,256个并发。

OneSQL RealSync数据保护补丁有四种运行级别,所下所述:

  • OFF:全部关闭,即异步复制情况。
  • DUMP:主库事务在AFTER_COMMIT模式下等Binlog同步到备库。
  • APPLY:主库事务在AFTER_COMMIT模式下等Binlog同步到备库,并等待回放完成。
  • MAX:主库事务在AFTER_FLUSH模式下等Binlog同步到备库,并在AFTER_COMMIT模式下等待Binlog回放完成。

可以看到对于特别小的事务,RealSync的DUMP模式几本上对性能无任何影响;在较大的事务模式下,则有20%的事务影响;而等待回放完成,则事务处理能力下降40%左右;而在最强(MAX)保护模式下,则事务处理能力下降60%左右。在各种不同的数据保护级别下,OneSQL在同的客户端并发度下都能保持平滑的事务处理数,如下图所示:

mysql56_sysbench_oltp_benchmark

从事务数的绝对数值来看,结合MySQL 5.7.17的并行恢复的威力,以及OneSQL的优化效果,Update non index场景在最强保护模式下仍可以达到16000TPS(采用单线程大约是8000个事务左右);Oltp no select模式则可以达到8000个事务左右(采用单线程大约是3500个事务左右)。OneSQL在共享存贮(SAN)以及云盘等较长IO链路的情况下,也能保证备库恢复的速度,具有极高的性价比。