InnoSQL/MySQL并行复制的实现与配置

并行复制之前的解决方案

InnoSQL在5.5.30-v4版本中支持了从机并行复制的功能。总所周知,MySQL数据库slave服务器延迟的现象是非常普遍的,这导致了虽然对比Oracle、Microsoft SQL Server,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机。这就导致了有了以下一些潜规则:“实时性要求不高的读取操作可以放到slave服务器,实时性要求高的读取操作放到master服务器”,“从机仅能做前一天的统计类查询”。

网易的易信项目、RDS也深受这个问题的困扰,所以我们打算彻底的解决这个问题。在v3版本之前我们的解决方案是使用batch commit,即将slave服务器回放的一个个事务,进行批量的回放。虽然还是单线程,但是由于大大减少commit的次数,也能有非常明显的效果,重要的是他对二进制日志的格式没有要求。缺点当然也有,比如还是单线程回放,不能充分利用磁盘的性能。另外,存储引擎必须要求是InnoDB或TokuDB事务引擎。batch commit方案已经在易信和RDS项目上使用,取得了比较明显的效果,但是InnoSQL的目标永远是追求卓越。

并行复制的实现

所以InnoSQL团队打算实现并行复制,虽然有各种想法,但是一直没有好的实现思路。淘宝有公布他们的并行复制实现方案,但是因为是基于row格式二进制日志的,我们线上业务并没有具体限制二进制日志格式。另外,淘宝放出的patch完成度比较低,很多复制错误也未能处理,感觉也是处于原型阶段(大概1年多前,现在可能已经成熟)。另外,对于并行的判断感觉比较复杂,而且全局的hash表感觉会是一个性能瓶颈。好在MariaDB的大牛Kristian最终解决了并行复制的问题,他的实现堪称完美。即一个组提交中的事务都是可以并行执行的。因为既然处于组提交中,这意味着事务之间没有冲突,否则不可能进行这个阶段。MariaDB的实现基于gtid实现,不过我们5.5的版本并没有实现gtid,所以需要做一些变通的实现。我们增加了一个event类型,称之为Gcid_event,表示组提交的编号。如:

mysql> show binlog events in 'mysqld-bin.000004' limit 50;
+---------------------------------+------+-------------------+-----------+-------------+---------------------------------------------+
| Log_name                        | Pos  | Event_type        | Server_id | End_log_pos | Info                                        |
+---------------------------------+------+-------------------+-----------+-------------+---------------------------------------------+
| mysqld-bin.000004 |    4 | Format_desc       |        11 |         150 | Server ver: 5.5.30vsr-ha-log, Binlog ver: 4 |
| mysqld-bin.000004 |  150 | Binlog_checkpoint |        11 |         204 | DavidmatoMacBook-Pro-bin.000004             |
| mysqld-bin.000004 |  204 | Gcid_event        |        11 |         231 | GCID id=231077                              |
| mysqld-bin.000004 |  231 | Query             |        11 |         301 | BEGIN                                       |
| mysqld-bin.000004 |  301 | Table_map         |        11 |         356 | table_id: 35 (sbtest.sbtest1)               |
| mysqld-bin.000004 |  356 | Update_rows       |        11 |         766 | table_id: 35 flags: STMT_END_F              |
......

组提交中的事务是可以并行执行的,所以可以看到一个组提交中的事务拥有相同的Gcid_event,即231077:

| mysqld-bin.000004 |  204 | Gcid_event        |        11 |         231 | GCID id=231077       |
......
| mysqld-bin.000004 |  1258 | Gcid_event        |        11 |         1285 | GCID id=231077     |
......
| mysqld-bin.000004 |  2312 | Gcid_event        |        11 |         2339 | GCID id=231077     |
......

通过查看二进制日志可以知道组提交中事务的个数,这样的查询方式比较繁琐。InnoSQL提供了状态来观察组提交的情况,这里一个组提交平均包含8个事务:

mysql> show global status like '%commit%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
......
| Commit_group_num | 92     |
| Commit_num       | 730    |
....

在InnoSQL版本中还可以通过参数binlog_commit_wait_count和binlog_commit_wait_usec来增大组提交的比例,副作用是事务的响应时间会变慢,性能会有损耗,所以这两个参数的调整需要一定的技巧。参数binlog_commit_wait_count表示一个组提交中至少有多个事务才进行提交,参数binlog_commit_wait_usec表示等待多少毫秒再进行组提交。这样的优化对于共享存储设备能有极大的帮助,根据InnoSQL的测试,根据适当的参数调整,MySQL的响应时间仅下降了3%,但是共享存储的I/O使用率缺下降了50%之多。

InnoSQL对于并行复制的实现另一个重要的特点就是支持crash safe,也就是服务器,亦或者是复制服务出现任何错误时,都要保证主从数据是完全正确的。因此,我们将原来复制的relay-info信息文件保存为了一张表,这和官方MySQL 5.6的处理方式一样,和Percona的处理方式不一样。Percona是将slave服务器的二进制位置写入InnoDB的事务段头,恢复时通过这部分的内容来替换relay-info文件。这样处理看似比较简单易懂,但是这个方案的最大问题是其仅支持InnoDB存储引擎。网易内部还有使用TokuDB引擎和自己开发的TNT引擎,要兼容这些引擎需要将relay-info存表,存储引擎选择相应的类型即可。这种方式完美的适配于我们自己开发的TNT引擎

实现并行复制最为关键的是order commit的实现,即事务在slave服务器上是并行执行执行的,但是提交顺序是和master服务器一致的。这样能保证主从产生的二进制日志顺序是一致的。另外,并行复制实现最为复杂的是对于出错的处理,InnoSQL在方面提交了很多patch给MaraiDB并被接受。

并行复制配置

要实现一个完美的crash-safe并行复制环境,需要根据如下参数进行配置,首先master服务器根据如下进行配置:


[mysqld]
server-id=xxx
log-bin=xxx
sync_binlog=1 #保证master crash safe,该参数必须设置为1
innodb_support_xa=1 #保证master crash safe,该参数必须设置为1
binlog_commit_wait_count=xxx #根据自身业务进行调整
binlog_commit_wait_usec=xxx #根据自身业务进行调整
enable_table_relay_info=1 #如果需要进行双主的配置

slave服务器进行如下的配置:

[mysqld]
server-id = xxx
log-bin = xxx
enable_table_relay_info = 1
slave_parallel_threads = 32 #并行复制的线程数
relay_log_recovery = 1 #从机crash safe要求重新同步master日志

当然,以上的配置仅能保证并行复制是crash safe的,但不能保证在进行failover后数据不丢失。如果应用需要保证数据不丢失,那么需要再开启InnoSQL的VSR(Virtual Sync Replication)功能,这样能保证怎样的切换主从数据都是一致的。该功能已经在网易内部上百台服务器中使用了近2年的时间。下一篇文件即将介绍InnoSQL的VSR已经高可用同步套件功能。

并行复制性能测试

InnoSQL的并行复制性能测试报告已经发布,小伙伴们可以从http://pan.baidu.com/s/1bn6b3mJ进行下载。当然,我们更环境小伙们自己进行测试,你会发现为什么InnoSQL是最有诚意的MySQL分支版本。InnoSQL 5.5.30-v4下载地址:http://pan.baidu.com/s/1bnpgzpH

如果需要进行任何InnoSQL咨询服务,可以访问:http://www.innosql.net/?p=48

发表评论

4 条评论
  • 板凳 eavMw 

    这个更刺c激,准备好手纸哦 A 片。。 288d.pw

  • 椅子 eavMw 

    这个更刺c激,准备好手纸哦 A 片。。 288d.pw

  • 沙发 yejr 

    赞,一定得安排时间测试一把 :)

相关文章
MySQL 8.0.3性能大杀器 —— CATS
MySQL 8.0.3性能大杀器 —— CATS
2017年MySQL数据库技术嘉年华 —— 有态度的技术大会
2017年MySQL数据库技术嘉年华 —— 有态度…
IMG社区MySQL技术沙龙南京站圆满结束
IMG社区MySQL技术沙龙南京站圆满结束
改朝换代:MySQL Group Replication
改朝换代:MySQL Group Replication
数据库行业的朋友圈内幕,不知道就没法混了
数据库行业的朋友圈内幕,不知道就没法…
Inside MySQL Group社区启用新LOGO
Inside MySQL Group社区启用新LOGO
Oracle MySQL ACE. Author of Inside MySQL and MySQL Core Series. Great at MySQL performance tuning、troubleshooting、systems availability and scalability、capacity planning, etc.

一触即发,2017年,数据库世界的诸神之战