关于 WriteSet 对复制延迟的改进

一、复制延迟的现象问题

　　　说到复制延迟。我曾经(现在也是)眼睁睁的看着每天好几封告警邮件，有一半是来自复制延迟，却又奈何不了。估计很多 MySQL DBA也是对他恨到牙痒痒。

二、MySQL官方给出的解决方案

　2.1  5.6 --> 基于库级别的并行复制　　　　

　　　MySQL中可能会有多个库，不同的库之间可能没有什么关系，所以在slave那边为每一个库分配了一个线程。以此提高复制的效率。也有可能会出现跨库的情况，当出现这种情况，也就这能等待这个事务完成

　2.2  5.7 --> 基于组提交的并行复制

　　　组提交的思想是：所有处于 prepare 阶段的事务同属于一个组，一个组内的事务可以并行提交。

　　　基于此思想，同组事务到了 slave 端就可以并行处理。

　　　那么在 slave 端是怎么区分是同组事务呢？

　　　MySQL在binlog中加入了 last_committed，sequence_number

　　#180915  2:59:19 server id 883306  end_log_pos 259 CRC32 0xad68c74f     GTID    last_committed=0        sequence_number=1       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 582 CRC32 0x347b8079     GTID    last_committed=1        sequence_number=2       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 905 CRC32 0x9728debf     GTID    last_committed=1        sequence_number=3       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 1228 CRC32 0x5a8c2d37    GTID    last_committed=1        sequence_number=4       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 1551 CRC32 0x79d0f774    GTID    last_committed=1        sequence_number=5       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 1874 CRC32 0xc75b96fa    GTID    last_committed=1        sequence_number=6       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 2197 CRC32 0x03bbc228    GTID    last_committed=1        sequence_number=7       rbr_only=yes
　　#180915  2:59:19 server id 883306  end_log_pos 2520 CRC32 0x876377ab    GTID    last_committed=1        sequence_number=8       rbr_only=yes

　　　last_committed 相同的属于同一个组，例如：

　　　last_committed = 0 中只有 1 个事务

　　　last_committed = 1 中有 2-8 7个事务

　　　假设 slave 端的 parallel 是 10，那么就可以同时执行7个事务。虽然看着挺美好，但还是有个问题。介绍这个问题的时候，首先介绍两个参数：

　　　binlog_group_commit_sync_delay：等待多少时间后才进行组提交，单位 (ms)，最大 1000000ms == 1s

　　　binlog_group_commit_sync_no_delay_count：等待一组里面有多少事物我才提交

　　　以上两个参数，默认都是0，意思是 MySQL 不等待就进行提交。所以当系统不繁忙是，last_committed 通常只有 1 个 sequence_number。也就是一组只有一个事务。而当系统比较繁忙时，last_commttied 中有可能有多个 sequence_number。这个由 MySQL 自己决定。但是MySQL本身决定是有问题的，假如 1 秒 中有 500 个事务(这个在我们的生产系统中最高达到1000,业务高峰300-500都是常见的)。但是一组中的事物并非都是 10 个以上的，基本上都是 1、2、3 …… 参差不齐的。所以我的从库本来是有 10 个并行线程的。但是最能同时处理 1、2、3个事务，你说这让人气不气。那么不是有 binlog_group_commit_sync_no_delay_count 这个参数吗？可以控制一组有多少事务才提交，我设置为 10，那么到从库就可以 10 个事务并行处理了啊。是这样没错，但是设置这个 binlog_group_commit_sync_no_delay_count 参数之前，需要打开 binlog_group_commit_sync_delay，否则不生效。

 　　　

　　　那么既然需要打开，那就打开呗！设置多少好呢？假设设置到最大 1s，1s 最大 500个事务，开50个并行，每个并行每秒处理 10 个事务，每个事物 0.1 秒，0.1 秒从库处理的过来。从库没有延迟很开心有没有，但是这种设置有没有问题，有。看一下 binlog_group_commit_sync_delay 的解释，等待多少时间后才进行组提交。这个时间，不管你 1s 内有多少个事务，统统等待 1s。也就是我一个 insert 本来 0.01 可以完成的，我非要等待 1 秒后才提交。并发高的时候没有影响，并发低的时候问题就来了。非要阻塞 1s 才提交。还会有什么其他影响吗？有，没有提交是不是就持有锁，那么锁没释放，其他会话是不是就需要等待。所以，我曾经没有好好理解 等待多少时间后才进行组提交 这句话，导致了生产事故。具体看我写的另一篇博客：https://www.cnblogs.com/ziroro/p/9600359.html　　

　2.3  5.7.22以上 --> 基于写集合的并行复制

　　　一不小心说了大多血泪史，回归正题。writeset的思想是：不同事物修改了不同行的数据，那么可以视为同一组。MySQL 会对这个提交的事务中的一行记录做一个 HASH值，这些 HASH 值称为 writeset。writeset会存入一张 HASH 表。其他事务提交时会检查这张 HASH 表中是否有相同的记录，如果不相同，则视为同组，如果有相同，则视为不同组。怎么判断是否同组，依然采用了last_committed，sequence_number。具体看实验：

　　2.3.1 binlog_transaction_dependency_tracking 设置为 writeset　　　

　　set global binlog_transaction_dependency_tracking = WRITESET

　　2.3.2 插入不相同的数据

　　insert into t1 select 1,'a';
　　insert into t1 select 2,'b';

　　2.3.3 解析binlog

　　mysqlbinlog --base64-output=decode-rows -vv /data/mysql/mysql_3306/logs/bin.000004 > 4.sql

　　内容如下

　　### INSERT INTO `vcyber`.`t1`
　　### SET
　　###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
　　###   @2='a' /* VARSTRING(40) meta=40 nullable=1 is_null=0 */　　…………
　　#180915  6:19:32 server id 883306  end_log_pos 572 CRC32 0x88c31fe8     GTID    last_committed=1        sequence_number=2       rbr_only=yes
　　…………
　　### INSERT INTO `vcyber`.`t1`
　　### SET
　　###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
　　###   @2='b' /* VARSTRING(40) meta=40 nullable=1 is_null=0 */　　…………
　　#180915  6:19:35 server id 883306  end_log_pos 885 CRC32 0x6901dc68     GTID    last_committed=1        sequence_number=3       rbr_only=yes

　　　可以看到修改了不相同的数据，last_committed 都是相同的。为了比较不同，把 binlog_transaction_dependency_tracking 修改回 COMMIT_ORDER　　　

　　2.3.4 binlog_transaction_dependency_tracking 设置为 COMMIT_ORDER

　　set global binlog_transaction_dependency_tracking = COMMIT_ORDER

　　2.3.5 插入不相同的数据

　　insert into t1 select 11,'aa';
　　insert into t1 select 12,'bb';

　　2.3.6 解析binlog

　　### INSERT INTO `vcyber`.`t1`
　　### SET
　　###   @1=11 /* INT meta=0 nullable=0 is_null=0 */
　　###   @2='aa' /* VARSTRING(40) meta=40 nullable=1 is_null=0 */
　　…………
　　#180915  6:30:30 server id 883306  end_log_pos 575 CRC32 0x24a2ace1     GTID    last_committed=1        sequence_number=2       rbr_only=yes
　　…………
　　### INSERT INTO `vcyber`.`t1`
　　### SET
　　###   @1=15 /* INT meta=0 nullable=0 is_null=0 */
　　###   @2='ee' /* VARSTRING(40) meta=40 nullable=1 is_null=0 */
　　…………
　　#180915  6:30:34 server id 883306  end_log_pos 891 CRC32 0xe3bb6418     GTID    last_committed=2        sequence_number=3       rbr_only=yes

　　　两个事物的 last_committed 不相同，到从库是没有办法并行复制的。

 

　　　那么 writeset 最多可以并行执行多少个事务呢？假设插入 30000 条不同记录，统计下 last_committed 有多少个，就可以证明可以并行执行多少个事务，为了少啰嗦一点，我就直接贴出我的结果

  　12500 last_committed=1
  　12501 last_committed=12501
  　 4997 last_committed=25002

　　　看来好像最多可以并发执行 12500 事务。12500 这个数字接近 binlog_transaction_dependency_history_size 这个参数的一半

　　　binlog_transaction_dependency_history_size：哈希表可以存储的最大大小

　　　为了证明猜想，将 binlog_transaction_dependency_history_size 设置为 50000 又会怎么样

 　 25000 last_committed=1
 　 25001 last_committed=25001
 　  9997 last_committed=50002

　　看起来好像确实接近于 binlog_transaction_dependency_history_size 的一半。

 

转载于:https://www.cnblogs.com/ziroro/p/9651792.html