MYSQL 8 GROUP REPLICATION 的新感觉

MYSQL 8 Group Replication 最近开始做实验了，MYSQL 5.7的MGR 在使用了不到一年的时间里面，发现了不少问题，也解决了不少问题。MYSQL 8 GROUP REPLICATION 在搭建环境中发现的第一个感觉就是比MYSQL 5.7 在节点进入集群的速度上要快了。

没有对比就没有伤害，下面就来对比一下MYSQL 8 的Group replication 和5.X 有什么改进。

performance_schema.replicatiton_group_members 展示的信息不同了

熟悉MYSQL 5.7X的MGR的同学在查询集群中的节点的状态通常使用上面的VIEW，但是MYSQL 5.7x 中展示的信息只有

CHANNEL_NAME

MEMBER_ID

MEMBER_HOST

MEMBER_PORT

MEMBER_STATE

这里面其实缺失一项最重要的展示，就是那个机器是主呀？当然你可以部署多主的，但在实际应用中，这么干的终究是少数，同时也都是不重要的系统，而在使用的方式上也有差。

MYSQL 8.0 直接弥补了这个问题，下图中可以看到，比MYSQL 5.7X多了两列，一列是那个是主，另一列是版本。

有人问，显示版本有什么用，当然有用，我是不是可以不同的版本进行MGR的连接，不同的版本我在查看状态的时候，是不是就带出来版本号让我一目了然。

当然这仅仅是一个开始，在MYSQL 5.7时被吐槽最多的MGR中缺少的功能就是，不能选择哪个是主，虽然后期可以通过权重的方式来搞，但还是不方便。现在MYSQL MGR 可以直接的进行自主选主的工作。通过下图，可以很清楚的看到，如何手工进行自动选主的工作以及切换。

SELECT group_replication_set_as_primary('3dca6cf9-8a66-11e9-bd97-000c29ba69f2');

并且MYSQL 8.0还添加了一些新的参数和功能来完善MGR 的应用性，例如

group_replication_exit_state_action

之前的版本一直在成员由于各种原因和集群失联后的处理工作，并且不能被选中，现在这个问题可以选中了

通过上面的参数，你可以选择是关机还是设置成read_only

当然被吐槽的还有一个关键点，就是由于网络的问题，造成的误踢出的节点，在 5.7 中没有调试这样的参数，而现在在MYSQL 8 有了

group_replication_member_expel_timeout

通过这个参数，你可以很轻松的避开某些由于网络问题，或突发的网络流量引起的不必要的，节点踢出问题。

同时分布式数据库中的信息交互成本也应该被考虑，因为要有回滚的问题，这是不能回避的问题。所以MYSQL 8.0 可以调整这样的参数

group_replication_transaction_size_limit

默认8.0设置为 143MB，的事务控制，在MYSQL5.7是没有设置的，默认是不限制。所以经常不大会用MYSQL ，那MYSQL当ORACLE 用的亲们，可能你在操作大事务的情况下，会被踢回去，这不怪MYSQL，怪你没有真正领会MYSQL使用的精髓。

说完这些，还的说说某些参数已经不再8.0支持了

如果在MYSQL 5.7X上，在进行从库的加入时，经常会用到这个命令，来讲GTID不一致的情况下的从库加入到集群中，（当然你首先的保证数据的三个节点应该是一致的情形下，采用这个方法）

group_replication_allow_local_disjoint_gtids_join

其实在监控方面可以说的地方还很多，不过今天就到这里，休息休息一下