MYSQL 8 在GR 与 MYSQL 5.7 多了哪些东西 “浅薄”的说说

最新推荐文章于 2021-12-24 13:40:07 发布

Austindatabases

最新推荐文章于 2021-12-24 13:40:07 发布

阅读量216

点赞数

本文链接：https://blog.csdn.net/liuhuayang/article/details/106233751

版权

质量和数量之间是需要平衡的，之前每个工作日更新可能是天时地利人和都支持，但任何事情都是变化的，数量与质量相比，显然是质量更重要，未来可能从相关的文字结构和角度都要有变化，来适应新的阶段的需求。

-----------------------------------------------------------------------------

正文

由于需求，整体的MYSQL 将不在部署MYSQL 5.7 都将转向MYSQL 8，所以必须要搞清楚当前的MGR 与 MYSQL 8 的MGR 之间的我们有多少可以调整的参数。根据官方文档，对比

MYSQL 8 多了

Message Fragmentation

XCom cache management

Responses to failure detection and network Partitioning

那我们就从以下三个方面来看看这三个与MYSQL 5.7 不同添加的项目

MYSQL 5.7

组复制目前使用XCom(组通信引擎)向组成员自动广播消息(事务)，并检测组成员何时失败。当需要向组广播消息时，每个组成员的组复制插件将消息转发到其本地XCom实例，XCom最终以相同的顺序将这些消息传递给每个组成员的组复制插件。XCom 是单线程的，如果一个大事务在XCom中处理，那很可能造成的结果就是，其他XCom成员将现在这个busy 的 XCom成员驱逐出去，造成这个节点和集群脱离。

那么这个问题的出现会出现两个想法， 1 增加XCom组件之间的默认认为对方没有响应的时长，2 降低XCom组件一次性处理的事务的大小。

Message Fragmentation 就是想法 2 降低XCom 一次性处理的事务的大小，降低XCom 在处理大事务时的无响应可能性。

实际上从MYSQL 8.106 里面添加了 group_replication_communication_max_message_size, 默认10MB

同时稍微注意一下 slave_max_allowed_packet 里面的参数 group_replication_communication_max_message_size 是不能超过 slave_max_allowed_packet 这个值的。

在线可以进行相关的参数的更改。

要使用这项功能需要 group_replication_get_commuication_protocol 必须是8.016 版本以上。

select * from group_replication_set_communication_protocol();

绿色节点将需要发送的数据分块

其他节点得到数据，开始判断得到数据的完整性

最终将数据块拼凑齐后，进行处理。

（顺便说一句，增加时间的想法在 8.013 有相关的参数实现）

所以分布式数据库的信息的发送和接受，以及信息的处理利用，以及相互之间的信息如何协调是一个关键。同时也要遵守 MYSQL 的分布式协议 PAXOS。

浅薄的说完Message Fragmentation，增加的下一个项目

XCom cache management,这个也是从 8.016这个版本开始的，主要的目的是为XCom组件的消息缓冲进行一个限制，默认是1GB ，采用先进先出的机制，当存储的信息达到1GB，就将已经使用过确认的条目进行清理，

说这个问题前就的先说一下Group_replication_member_expel_timeout，这个参数，在有网络延迟，或者处理大事务时，很可能会将无响应的节点踢出去，则group_replication_member_expel_timeout 就是这个判断这个节点是死是活的延迟机制，最大可以设置为 3600秒，也就是一个小时的时间。而随着之间由于各种原因无法进行沟通和响应，则之间的信息差也会慢慢显现，所以就祭出这次的参数

XCom cache management ，提高他的容量可以随着你提高 group_replication_member_expel_timeout 的值，保证节点之间的数据还是可以进行同步的。

select * from performance_schema.memory_summary_global_by_event_name where event_name like "%GCS_XCom::xcom_cache%"\G

缓存由50k个槽组成，缓存的最大大小约为1GB。这意味着在开始删除任何数据之前，缓存可以存储最多50k的消息或接近1GB的数据;当达到空间限制或插槽限制(不可避免地会出现其中之一)时，缓存将删除一些旧条目，为新条目腾出空间。

这里面有两个值，current_number_of_bytes_used 和 high_number_of_bytes_used , 1个代表当前你使用多少 XCOM 的cache ,领一个代表你的曾经的历史最高值，通过监控着两个值，就可以获得你的XCOM中使用的内存数，并判断当前的值适合你的服务器吗，并进行调整。

最后一点是 Responses to Failure Detection and Network Partitioning,由于是基于PAXOS机制的分布式数据库，所以检测当前数据库集群中的节点的状态并且将不符合要求的节点驱逐是一项必要的工作。

这一段包含四个items

1 Expel Timeout

2 Unreachable Majority Timeout

3 Auto- Rejoin

4 Exit Action

这里通过四个参数来讲这四个items 来

Expel Timeout : group_replication_member_expel_timeout 这个参数是设置组复制组成员在产生怀疑后等待的一段时间，以秒为单位，然后将怀疑失败的成员从组中驱逐出去。最大 3600秒。

Unreachable Majority Timeout：group_replication_unreachable_majority_timeout 这个参数主要是针对多数节点在网络分区中的应用，例如一个我们有两个网络分区，一边三台，一边2台机器，组成一个集群，则由于网络之间的问题， 3 台和 2台无法通信按照大多数的原理，2台机器就要和整体集群说bye bye 则上面的这个参数就是设置到底2台机器可以忍耐多长时间。

Auto- Rejoin：group_replication_autorejoin_tries 这个参数是在成员被剔除后，例如网络又回归了，或者系统变得正常了，失效节点申请重新加入原来的集群，默认是不允许，最大是可以设置2016 次

Exit Action: 最后是group_replication_exit_state_action，这是一个决定你的节点被剔除后的状态，里面可以选择是关闭机器，或者进行系统的super read only的设置

最后MYSQL 8 的GR ，如果想选择版本的话建议8.016以上，大部分参数都是在8.016这个版本进行完善的。当然如果想使用 MYSQL CLONE功能就的是8.017 版本。

当然这块的信息量太大，只能用这篇“浅薄”的文字先开始。