乐趣区

关于mysql:Changes-in-GreatSQL-8025162022516

jiezi
  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

[toc]

1. 新增个性

1.1 新增仲裁节点（投票节点）角色

该节点仅参加 MGR 投票仲裁，不寄存理论数据，也无需执行 DML 操作，因而能够用个别配置级别的服务器，在保障 MGR 可靠性的同时还能升高服务器老本。

新增参数 group_replication_arbitrator 用于设置仲裁节点。

若想新增一个仲裁节点，只需在 my.cnf 配置文件中增加如下配置：
group_replication_arbitrator = true

当集群中只剩下 Arbitrator 节点时，则会主动退出。

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 4b2b46e2-3b13-11ec-9800-525400fb993a | 172.16.16.16 |        3306 | ONLINE       | SECONDARY   | 8.0.27         | XCom                       |
| group_replication_applier | 4b51849b-3b13-11ec-a180-525400e802e2 | 172.16.16.10 |        3306 | ONLINE       | ARBITRATOR  | 8.0.27         | XCom                       |
| group_replication_applier | 4b7b3b88-3b13-11ec-86e9-525400e2078a | 172.16.16.53 |        3306 | ONLINE       | PRIMARY     | 8.0.27         | XCom                       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+

能够看到，MEMBER_ROLE 这列显示为 ARBITRATOR，示意该节点是一个仲裁节点。

再看压测期间各节点负载数据，先看 Primary 节点：

$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
20198 mysql     20   0   11.9g   3.4g  23440 S 207.6 21.6  21:33.48 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3      0   5637    152   6385    0    0     0 56311 53024 53892 36 17 43  3  0
 0  3      0   5633    152   6389    0    0     0 46053 51900 52435 35 17 44  4  0
 6  0      0   5628    152   6393    0    0     0 47024 52026 52388 36 17 44  3  0
 7  1      0   5623    152   6397    0    0     0 51673 52165 53113 36 17 43  3  0
 3  1      0   5621    152   6401    0    0     0 44231 52164 52875 35 17 45  3  0
 3  4      0   5616    152   6404    0    0     0 49278 52854 53139 37 17 43  3  0
 4  0      0   5613    152   6408    0    0     0 49738 52848 53361 37 17 43  3  0

在其中一个 Secondary 节点上：

$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
26824 mysql     20   0   11.6g   3.0g  22880 S 175.7 19.4  19:27.34 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0   2089    128  10757    0    0     0 53671 31463 46803 30 11 55  4  0
 3  0      0   2082    128  10765    0    0     0 52737 31475 45862 30 11 55  4  0
 2  0      0   2073    128  10772    0    0     0 52121 31035 45820 29 12 55  4  0
 3  0      0   2065    128  10781    0    0     0 51469 31081 44831 30 12 55  4  0
 1  0      0   2057    128  10788    0    0     0 53071 31442 45664 30 11 55  4  0
 3  0      0   2049    128  10795    0    0     0 51357 29848 43391 30 12 54  4  0
 0  0      0   2041    128  10803    0    0     0 52404 30545 45020 29 12 56  4  0
 3  0      0   2034    128  10811    0    0     0 51355 31483 45582 32 12 53  3  0

在 Arbitrator 节点上：

$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16997 mysql     20   0   11.2g   2.5g  22184 S  29.6 16.4   3:47.84 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0   6145    141   7095    0    0     0    44 17767 16010  4  4 93  0  0
 1  0      0   6146    141   7095    0    0     0     0 17020 16189  4  4 93  0  0
 0  0      0   6144    141   7095    0    0     0     0 16958 15365  3  4 93  0  0
 0  0      0   6145    141   7095    0    0     0     0 15942 14969  3  3 93  0  0
 1  0      0   6146    141   7095    0    0     0     0 17698 16320  4  4 92  0  0

能够看到负载显著小了很多，这就能够在一个服务器上跑多个仲裁节点角色。

留神： 在有仲裁节点的状况下，将单主切换成多主模式时，须要把投票节点先敞开再进行切换，否则可能会导致切换失败，并且仲裁节点报错退出 MGR。

1.2 新增疾速单主模式

GreatSQL 中减少一个新的工作模式：单主疾速模式，在这个模式下，不再采纳 MySQL MGR 原有的认证数据库形式。新增选项 group_replication_single_primary_fast_mode 用于设置是否启用，以及具体采纳哪种模式。

疾速单主模式特地适宜在跨机房部署，压力测试以及内存要求不低等多种场景。这种模式弱于传统的异步复制，但强于半同步复制，且没有 MGR 默认的认证数据库可能耗费较大内存的问题。

揭示，启用疾速单主模式时，不反对采纳多主模式；所有节点都的设置必须雷同，否则无奈启动。

选项 group_replication_single_primary_fast_mode 可选值有：0、1、2，不同值别离示意如下：

  • 0，示意不采取疾速单主模式，这是默认值。
  • 1，示意采纳疾速单主模式，反对并行回放。** 强烈建议设置为 1，即启用疾速单主模式。
  • 2，示意采纳疾速单主模式，但不反对并行回放，减速 realay log 落盘，且让从库耗费更少的资源。

| System Variable Name | group_replication_single_primary_fast_mode |
| — | — |
| Variable Scope | Global |
| Dynamic Variable | NO |
| Permitted Values | 0<br/>1<br/>2 |
| Default | 0 |
| Description | 设置是否启用疾速单主模式，强烈建议启用（即设置为 1）。|

1.3 新增 MGR 网络开销阈值

新增相应选项 group_replication_request_time_threshold。

在 MGR 构造中，一个事务的开销蕴含网络层以及本地资源（例如 CPU、磁盘 I / O 等）开销。当事务响应较慢想要剖析性能瓶颈时，能够先确定是网络层的开销还是本地性能瓶颈导致的。通过设置选项 group_replication_request_time_threshold 即可记录超过阈值的事件，便于进一步剖析。输入的内容记录在 error log 中，例如：

2022-03-04T09:45:34.602093+08:00 128 [Note] Plugin group_replication reported: 'MGR request time:30808us, server id:3306879, thread_id:17368'

示意过后这个事务在 MGR 层的网络开销耗时 30808 微秒（30.808 毫秒），再去查看那个时段的网络监控，剖析网络提早较大的起因。

选项 group_replication_request_time_threshold 单位是毫秒，默认值是 0，最小值 0，最大值 100000。如果 MGR 跑在局域网环境，则倡议设置为 50 ~ 100 毫秒区间，如果是运行在跨公网环境，则倡议设置为 1 ~ 10 秒左右。另外，当该值设置为 1 ~ 9 之间时，会主动调整为 10（毫秒）且不会提醒 warning，如果设置为 0 则示意禁用。

| System Variable Name | group_replication_request_time_threshold |
| — | — |
| Variable Scope | Global |
| Dynamic Variable | YES |
| Permitted Values | [0 ~ 100000] |
| Default | 0 |
| Description | 单位：毫秒。<br/> 设置阈值，当一个事务的 MGR 层网络开销超过该阈值时，会在 error log 中输入一条记录。<br/> 设置为 0 时，示意禁用。<br/> 当狐疑可能因为 MGR 通信耗时过久成为事务性能瓶颈时，再开启，平时不倡议开启。|

1.4 自定义选主模式

欠缺主动选主机制，减少基于最新 GTID 判断来选主，防止主动抉择没有最新 GTID 的节点作为新主。

默认地，MGR 依据以下规定选主：

  1. 当有 MySQL 5.7 和 MySQL 8.0 不同版本的节点混合部署时，只会抉择运行 5.7 的节点作为主节点。此外，在 <= MySQL 8.0.16 版本时，以主版本号进行排序，也就是说 5.7 排在 8.0 后面。在 > MySQL 8.0.17 版本中，则是以补丁版本号排序，也就是 8.0.17 排在 8.0.25 后面。
  2. 当所有节点版本号统一时，则依据节点权重值（选项 group_replication_member_weight 定义权重值，这个选项 5.7 版本没有，8.0 开始新增）排序，权重值高的节点排在后面。
  3. 依据节点 server_uuid 排序。

在一些状况下，在 MGR 所有节点都发生意外要从新拉起时，不会查看各节点事务利用状态，而谬误抉择新的主节点，这时可能会导致失落一些事务数据。或者当原来的主节点 crash 须要从新投票抉择新的主节点时，可能也会抉择一个权重值较高，但没有最新事务的节点，也会存在失落一部分事务数据的危险。

在 GreatSQL 中，新增选项 group_replication_primary_election_mode 用于自定义选主策略，可选值有以下几个：

  • WEIGHT_ONLY，还是依照上述传统模式主动选主，这是默认值。
  • GTID_FIRST，优先判断各节点事务利用状态，主动抉择领有最新事务的节点作为新的主节点。
  • WEIGHT_FIRST，传统模式优先，如果没有适合的后果再判断各节点事务状态。举荐设置为该模式。

揭示，所有节点都的设置必须雷同，否则无奈启动。

| System Variable Name | group_replication_primary_election_mode |
| — | — |
| Variable Scope | Global |
| Dynamic Variable | NO |
| Permitted Values | WEIGHT_ONLY<br/>GTID_FIRST<br/>WEIGHT_FIRST |
| Default | WEIGHT_ONLY |
| Description | 当 MGR 集群须要投票选主时，采纳何种投票策略。|

2. 稳定性晋升

  1. 优化了退出节点时可能导致性能激烈抖动的问题。
  2. 优化手工选主机制，解决了长事务造成无奈选主的问题。
  3. 欠缺 MGR 中的外键束缚机制，升高或防止从节点报错退出 MGR 的危险。

3. 其余调整

  1. 选项 group_replication_flow_control_replay_lag_behind 默认值由 60 秒调整为 600 秒，以适应更多业务场景。该选项用于管制 MGR 主从节点复制提早阈值，当 MGR 主从节点因为大事务等起因提早超过阈值时，就会触发流控机制。
  2. 新增选项 group_replication_communication_flp_timeout（单位：秒）。当多数派节点超过该阈值为收到某节点发送的音讯时，会将该节点断定为可疑节点。在网络条件较差的环境中，能够适当调大该阈值，以防止频繁抖动。

4.bug 修复

  1. 修复了 InnoDB 并行查问 crash 的问题（issue#I4J1IH）。
  2. 修复了在启用 dns 或 hostname 的状况下，bind 意外失败问题。
  3. 修复了协程调度不合理的问题，该问题可能会造成在大事务时零碎错误判断为网络谬误。
  4. 修复了新退出节点在追 paxos 数据时，因为 write 超时导致连贯提前敞开的问题。
  5. 修复了 recovering 节点被中途进行导致的数据异样问题。
  6. 修复了同时多个异样导致的视图问题。
  7. 修复了在某些场景下同时增加节点失败的问题。
  8. 修复了在非凡场景下组视图异样的问题。
  9. 修复了 rejoin 过程中，member_stats 相干查问导致解体的问题。
  10. 修复了在 before 模式下，可能导致 assert 失败的问题。
  11. 修复了 stop group_replication 时可能长时间期待的问题。
  12. 修复了将传统主从环境下产生的 binlog 导入 MGR 可能引起死循环的问题。
  13. 修复了因为大事务内存调配失败导致的解体问题。

5. GreatSQL VS MySQL 社区版

个性 GreatSQL 8.0.25-16 MySQL 8.0.25 社区版
投票节点 / 仲裁节点 ✅ ❎
疾速单主模式 ✅ ❎
天文标签 ✅ ❎
全新流控算法 ✅ ❎
InnoDB 并行查问优化 ✅ ❎
线程池（Thread Pool） ✅ ❎
审计 ✅ ❎
InnoDB 事务锁优化 ✅ ❎
SEQUENCE_TABLE(N)函数 ✅ ❎
InnoDB 表损坏异样解决 ✅ ❎
强制只能应用 InnoDB 引擎表 ✅ ❎
杀掉闲暇事务，防止长时间锁期待 ✅ ❎
Data Masking（数据脱敏 / 打码） ✅ ❎
InnoDB 碎片页统计加强 ✅ ❎
反对 MyRocks 引擎 ✅ ❎
InnoDB I/ O 性能晋升 ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️
网络分区异样应答 ⭐️⭐️⭐️⭐️⭐️ ⭐️
欠缺节点异样退出解决 ⭐️⭐️⭐️⭐️⭐️ ⭐️
一致性读性能 ⭐️⭐️⭐️⭐️⭐️ ⭐️
晋升 MGR 吞吐量 ⭐️⭐️⭐️⭐️⭐️ ⭐️
统计信息加强 ⭐️⭐️⭐️⭐️⭐️ ⭐️
slow log 加强 ⭐️⭐️⭐️⭐️⭐️ ⭐️
大事务处理 ⭐️⭐️⭐️⭐️ ⭐️
修复多写模式下可能丢数据危险 ⭐️⭐️⭐️⭐️⭐️ /
修复单主模式下切主丢数据危险 ⭐️⭐️⭐️⭐️⭐️ /
MGR 集群启动效率晋升 ⭐️⭐️⭐️⭐️⭐️ /
集群节点磁盘满解决 ⭐️⭐️⭐️⭐️⭐️ /
修复 TCP self-connect 问题 ⭐️⭐️⭐️⭐️⭐️ /
PROCESSLIST 加强 ⭐️⭐️⭐️⭐️⭐️ /

6. GreatSQL Release Notes

  • Changes in MySQL 8.0.25-16 (2022-5-16)
  • Changes in MySQL 8.0.25-15 (2022-8-26)
  • Changes in MySQL 5.7.36-39 (2022-4-7)

Enjoy GreatSQL :)

文章举荐：

面向金融级利用的 GreatSQL 正式开源
https://mp.weixin.qq.com/s/cI…

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc…

MGR 及 GreatSQL 资源汇总
https://mp.weixin.qq.com/s/qX…

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…

在 Linux 下源码编译装置 GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ…

# 对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr…

GitHub:

https://github.com/GreatSQL/G…

Bilibili：

https://space.bilibili.com/13…

微信 &QQ 群：

可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！

退出移动版