MySQL 8.0新特性：彻底解决困扰运维的复制延迟问题，你信吗？

虽然如此，在 5.7 中，基于逻辑时钟 Logical_Clock 的并行复制仍然有不尽人意的地方，比如必须是在主上并行提交的事务才能在从上并行回放，如果主上并发压力不大，那么就无法享受到并行复制带来的好处。5.7 中引入了binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count两个参数，通过让Binlog在执行fsync前等待一小会来提高Master上组提交的比率。但是无论如何，从上并行回放的速度还是取决于主上并行提交的情况。

MySQL 8.0中引入了一种新的机制来判断事务能否并行回放，通过检测事务在运行过程中是否存在写冲突来决定从机上的回放顺序，这使得从机上的并发程度不再依赖于主机。

事实上，该机制在MySQL 5.7.20版本中就已经悄悄的应用了。5.7.20版本引入了一个重要的特性：Group Replication，通过Paxso协议在多个MySQL节点间分发binlog，使得一个事务必须在集群内大多数节点(N/2+1)上提交成功才能提交。

为了支持多主写入，MySQL MRG在Binlog分发节点完成后，通过一个Certify阶段来决定Binlog中的事务是否写入RelayLog中。这个过程中，Certify阶段采用的就是WriteSet的方式验证事务之间是否存在冲突，同时，在写入RelayLog时会将没有冲突的事务的last_committed值设置为相同的值。

比如在5.7.20中，进行如下操作：

> -- create a group replication cluster.  
> STOP GROUP_REPLICATION; START GROUP_REPLICATION;  
Query OK, 0 rows affected (9.10 sec) 
> -- All the next commands on the primary member of the group:  
> CREATE DATABASE test_ws_mgr ;  
Query OK, 1 row affected (0.01 sec)  
> CREATE TABLE  test_ws_mgr.test ( id int primary key auto_increment, str varchar(64) not null );  
Query OK, 1 row affected (0.01 sec)  
> INSERT INTO test_ws_mgr.test(`str`) VALUES ("a");  
Query OK, 1 row affected (0.01 sec)  
> INSERT INTO test_ws_mgr.test(`str`) VALUES ("b");  
Query OK, 1 row affected (0.01 sec)  
> INSERT INTO test_ws_mgr.test(`str`) VALUES ("c");  
Query OK, 1 row affected (0.01 sec) 

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!