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) 

（编辑：湖南网）

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