--MySQL 8 group replication 有什么妖 问与答

MYSQL 8.018-9 已经上线了，下载了percona 的8.018-9 ，打开了官方的 show card。

这次采用8.017 才有的clone功能来进行从库的建立，不在使用备份的方式。（具体怎么进行clone的方法， 请参见之前的文字）

WHERE PLUGIN_NAME = 'clone';

如何搭建MGR 集群，请参见之前的文字，用MYSQL 5.7 的方式可以搭建8.018的MGR集群

下面就开始捉妖行动

问题1 系统搭建后，从节点一直处于 recovering 状态

经过

select * from performance_schema.replication_group_member_stats\G

查看，发现是 error connecting to master 'repl@mgr1:3306' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

原因：mysql 8 全部采用了 caching_sha2_password 的方式，这导致很多之前可以使用的工具以及工作的方式都需要改变。

快速低成本解决方法：

在my.cnf 中添加下面一行，将MYSQL 与MYSQL 5.7 的密码认证方式一致，则上面的问题解决

default_authentication_plugin=mysql_native_password

重新启动数据库服务，上面的问题可以解决

问题2 MYSQL MGR 是否支持一致性读，支持MYSQL 8.104版本已经开始支持，这从根本上提供了一种主从数据一致的方法

配置参数 group_replication_consistency

其中有五个值

eventual

before_on_primary_failover

before

after

before_and_after

需要强一致的，需要将group_replication_consistency 设置为 after

一个RW事务将一直等待，直到它的更改被应用到所有其他成员。此值对RO事务没有影响。此模式确保在本地成员上提交事务时，任何后续事务都将读取任何组成员上的写入值或最近的值。对主要用于RO操作的组使用此模式，以确保应用的RW事务在提交后应用到所有地方。您的应用程序可以使用它来确保后续的读操作能够获取最新的数据，其中包括最新的写操作。这减少了

但前提是你的MYSQL 集群中是写少，读多。否则会影响整体集群的性能，尤其不能进行大事务分割的，应该尽量使用小的多个事务，替换大事务。

问题3 如果集群中的某台机器要离开，那离开集群的机器对外需要使用什么方式离开

group_replication_exit_state_action插件变量是在MySQL 8.0.12中引入的，允许用户在服务器实例无意中离开组时配置组复制的行为。此功能主要是满足在某个节点离开集群后，离开系统的节点的对外展示何种状态。

其中可以选择的值：

ABORT_SERVER:服务器关闭自己; READ_ONLY:服务器将自己切换到超级只读模式

可以查看当前的服务器的离开的状态的后的反应是什么。

这样设置的好处是，可以自由的设定到当节点从集群离开了，采取什么样的措施。

问题4 MYSQL MGR 是无法忍受肆无忌惮的大事务，大事务会影响整体集群的性能甚至会导致集群之间节点无响应后解散的危险，怎么缓解这个问题（注意是缓解问题，不是解决问题）

在MYSQL处理大事务时，很有可能集群里面的机器会失去响应，组复制组成员在产生怀疑后等待的时间(以秒为单位)，然后将怀疑失败的成员从组中驱逐出去。在怀疑产生之前的最初5秒的检测周期不计入此时间。更改某个组成员上的group_replication_member_expel_timeout的值将立即对该组成员的现有和将来的无响应生效。不是强制要求组中的所有成员都具有相同的设置，但是建议这样做，以避免意外的驱逐。 默认情况下，group_replication_member_expel_timeout设置为0，这意味着没有等待期，在5秒的检测期结束后，可疑成员可能立即被驱逐。为了避免在较慢的网络上进行不必要的排除，或者在预期的瞬时网络故障或机器变慢的情况下，您可以指定一个大于零的超时值，最高可达3600秒(1小时)。如果可疑成员在怀疑超时之前再次激活，它将重新加入组。

当然正确的方法是，控制应用产生的事务大小，这才是正路。

问题5 当成员和集群分离后，是否进行继续的尝试

默认当节点与集群分离后，将不再尝试加入集群，从8.016后添加了group-replication-autorejoin-tries，可以对已经离开的节点进行重试次数的设置，最大可以设置2016次。这样的设置可以解决由于网络或其他问题造成节点脱离后的重新添加的自动化操作。使得 MGR 向自动化故障修复又迈出了一步。

从上边部分的方式看出MYSQL MGR 一致是往集群节点失败后的高容忍和自动修复上是进步的，尤其8.019，clone的功能会应用到自动节点数据修复中，但实际上MGR 从目前看还是一直在进步，并未停止的状态，并且使用的经验和这些新功能的可靠性还有待验证，所以导致目前还有很多企业在使用8.0的哪个版本，采用哪种技术，终究数据库整体升级并没有那么简单和轻松。