关于mysql:GreatSQL-MGR-FAQ

4次阅读

共计 10730 个字符，预计需要花费 27 分钟才能阅读完成。

欢送来到 GreatSQL 社区分享的 MySQL 技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答

[toc]

对于 GreatSQL 及 MGR 的 FAQ，继续更新中。

Last Update: 2021.12.10。

GreatSQL 是由万里数据库保护的 MySQL 分支，开源、收费。GreatSQL 基于 Percona Server，在其根底上进一步晋升 MGR（MySQL Group Replication）的性能及可靠性。此外，GreatSQL 合并了华为鲲鹏计算团队奉献的 Patch，实现了 InnoDB 并行查问个性，以及对 InnoDB 事务锁的优化。

GreatSQL 能够作为 MySQL 或 Percona Server 的可选代替计划，用于线上生产环境。

GreatSQL 完全免费并兼容 MySQL 或 Percona Server。

绝对于 MySQL 官网社区版，GreatSQL 有以下几个劣势：

InnoDB 性能更好
- 反对 InnoDB 并行查问，TPC- H 测试中均匀晋升聚合剖析型 SQL 性能 15 倍，最高晋升 40 多倍。
- 优化 InnoDB 事务锁，tps 性能可晋升约 10%。
MGR 更牢靠、稳固，性能也更好。
- MGR 中引入天文标签个性，次要用于解决多机房数据同步的问题。
- MGR 中优化了流控算法，运行更加安稳。
- 解决磁盘空间爆满时导致 MGR 集群阻塞的问题。
- 解决 MGR 多主模式下或切主时可能导致丢数据的问题。
- 解决节点异样退出 MGR 集群时导致性能抖动的问题。
- MGR 节点异样状态判断更欠缺。
- 从新设计 MGR 事务认证队列清理算法，不复存在每隔 60 秒性能抖动的问题。
- 修复了 recovery 过程中长时间期待的问题。
- 修复了传输大数据可能导致逻辑判断死循环问题。
- 修复了多数派节点不同类型异样退出集群导致的视图更新的问题。

无论是更牢靠的 MGR 还是性能更好的 InnoDB，都值得将以后的 MySQL 或 Percona Server 降级到 GreatSQL。

对于 GreatSQL 的劣势可浏览上面几篇文章：

GreatSQL 更新阐明 8.0.25
GreatSQL 重磅个性，InnoDB 并行并行查问优化测试
面向金融级利用的 GreatSQL 正式开源

二进制包下载地址：https://gitee.com/GreatSQL/GreatSQL/releases。

目前提供 CentOS 7、CentOS 8 两种操作系统，以及 X86 和 ARM 两种不同架构下的二进制包、RPM 包。

带 minimal 关键字的安装包是对二进制文件进行 strip 后，所以文件尺寸较小，性能上没本质区别，仅是不反对 gdb debug 性能，能够放心使用。

能够间接用 git clone 的形式下载 GreatSQL 源码，例如：

# 可从 gitee 下载
$ git clone https://gitee.com/GreatSQL/GreatSQL.git

# 或从 github 下载
$ git clone https://github.com/GreatSQL/GreatSQL.git

GreatSQL 提供 Ansible 一键安装包，可在 gitee 或 github 下载：

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

GreatSQL 提供 Docker 镜像，可间接从 docker hub 拉取：

# 间接下载最新版本
$ docker pull docker.io/greatsql/greatsql

# 或自行指定版本
$ docker pull docker.io/greatsql/greatsql:8.0.25

# 或指定 ARM 版本
$ docker pull docker.io/greatsql/greatsql:8.0.25-aarch64

应用 GreatSQL 过程中如果遇到问题，可将问题细节整顿分明后，分割 GreatSQL 社区寻求帮忙。

QQ 群：533341697

微信小助手：wanlidbc

GreatSQL 不打算每个小版本都追随，暂定奇数版本追随形式，即 8.0.25、8.0.27、8.0.29 … 以此类推。

将来若有版本打算变更咱们再更新。

能够利用 MySQL Router 来实现读写拆散。

是能够的，最好采纳雷同版本号的 MySQL Shell 即可。

上面是对于 MGR 应用的一些限度：

所有表必须是 InnoDB 引擎。能够创立非 InnoDB 引擎表，但无奈写入数据，在利用 Clone 构建新节点时也会报错。
所有表都必须要有主键。同上，能创立没有主键的表，但无奈写入数据，在利用 Clone 构建新节点时也会报错。
不要应用大事务，默认地，事务超过 150MB 会报错，最大可反对 2GB 的事务（在 GreatSQL 将来的版本中，会减少对大事务的反对，进步大事务下限）。
如果是从旧版本进行降级，则不能抉择 MINIMAL 模式降级，倡议抉择 AUTO 模式，即 upgrade=AUTO。
因为 MGR 的事务认证线程不反对 gap lock，因而倡议把所有节点的事务隔离级别都改成 READ COMMITTED。基于雷同的起因，MGR 集群中也不要应用 table lock 及 name lock（即 GET_LOCK() 函数）。
在多主（multi-primary）模式下不反对串行（SERIALIZABLE）隔离级别。
不反对在不同的 MGR 节点上，对同一个表别离执行 DML 和 DDL，可能会造成数据失落或节点报错退出。
在多主（multi-primary）模式下不反对多层级联外键表。另外，为了防止因为应用外键造成 MGR 报错，倡议设置 group_replication_enforce_update_everywhere_checks=ON。
在多主（multi-primary）模式下，如果多个节点都执行 SELECT ... FOR UPDATE 后提交事务会造成死锁。
不反对复制过滤（Replication Filters）设置。

看起来限度有点多，但绝大多数时候并不影响失常的业务应用。

此外，想要启用 MGR 还有几个要求：

每个节点都要启用 binlog。
每个节点都要转存 binlog，即设置 log_slave_updates=1。
binlog format 务必是 row 模式，即 binlog_format=ROW。
每个节点的 server_id 及 server_uuid 不能雷同。
在 8.0.20 之前，要求 binlog_checksum=NONE，然而从 8.0.20 后，能够设置 binlog_checksum=CRC32。
要求启用 GTID，即设置 gtid_mode=ON。
要求 master_info_repository=TABLE 及 relay_log_info_repository=TABLE，不过从 MySQL 8.0.23 开始，这两个选项曾经默认设置 TABLE，因而无需再独自设置。
所有节点上的表名大小写参数 lower_case_table_names 设置要求统一。
最好在局域网内部署 MGR，而不要跨公网，网络提早太大的话，会导致 MGR 性能很差或很容易出错。
倡议启用 writeset 模式，即设置以下几个参数
- slave_parallel_type = LOGICAL_CLOCK
- slave_parallel_workers = N，N>0，能够设置为逻辑 CPU 数的 2 倍
- binlog_transaction_dependency_tracking = WRITESET
- slave_preserve_commit_order = 1
- slave_checkpoint_period = 2

MGR 最多可反对 9 个节点，无论是单主还是多主模式。

设置参数 group_replication_bootstrap_group=ON 即可。然而当 MGR 第一个节点初始化启动时，或者整个 MGR 集群都敞开再重启时，第一个节点都必须先采纳疏导模式 group_replication_bootstrap_group=ON。

反对的。能够在 MGR 集群的前端挂载 MySQL Router，即可实现读负载平衡。

不反对。因为 MGR 采纳 shared nothing 模式，每个节点都存储全量数据，因而所有写入每个节点都要再利用一次。

肯定水平上来说，是的。因为 MGR 须要在多个节点间进行事务冲突检测，不过这方面的开销无限，总体来说也还好。

当启用 MGR 服务后，MySQL 会监听 33061 端口，该端口用于 MGR 节点间的通信。因而当服务器间有防火墙策略时，记得针对该端口凋谢。

当然了，可自行定义该端口，例如 group_replication_local_address=192.168.0.1:33062。

这个不是必须的。

之所以要在每个节点上都加上各节点的 hostname 对照表，是因为在 MGR 节点间通信过程中，可能收到的主机名和本地理论配置的不统一。

这种状况下，也能够在每个节点上自行设置 report_host 及 report_port 来解决这个问题。

能够的，但十分不举荐。

此外，因为 MGR 默认的 allowlist 不蕴含公网地址，因而须要将公网地址加进去，例如：

group_replication_ip_allowlist='192.0.2.0/24, 114.114.114.0/24'

顺便揭示下，MGR 默认的 allowlist 范畴（group_replication_ip_allowlist=AUTOMATIC）是以下几个

IPv4 (as defined in RFC 1918)
10/8 prefix       (10.0.0.0 - 10.255.255.255) - Class A
172.16/12 prefix  (172.16.0.0 - 172.31.255.255) - Class B
192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class C

IPv6 (as defined in RFC 4193 and RFC 5156)
fc00:/7 prefix    - unique-local addresses
fe80::/10 prefix  - link-local unicast addresses

127.0.0.1 - localhost for IPv4
::1       - localhost for IPv6

有时候 docker 容器的 IP 地址不在上述范畴中，也会导致 MGR 服务无奈启动。

执行上面的命令：

[root@GreatSQL]> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+-----------...-+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID ... | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+-----------...-+-------------+--------------+-------------+----------------+
| group_replication_applier | 4ebd3504-1... |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | 549b92bf-1... |        3307 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | 5596116c-1... |        3308 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | ed5fe7ba-3... |        3309 | ONLINE       | PRIMARY     | 8.0.25         |
+---------------------------+-----------...-+-------------+--------------+-------------+----------------+

如果只看到一个节点的 MEMBER_ROLE 值为 PRIMARY，则示意这是单主模式。如果看到所有节点上该状态值均为 PRIMARY，则示意这是多主模式。

另外，也能够通过查问 MySQL 选项值来确认：

[root@GreatSQL]# mysqladmin var|grep -i group_replication_single_primary_mode
| group_replication_single_primary_mode        | ON

值为 ON，这示意采纳单主模式。如果该值为 OFF，则示意采纳多主模式。

在 MySQL Shell 中也能够查看状态来确认：

MySQL  GreatSQL:3306 ssl  JS > var c=dba.getCluster()
MySQL  GreatSQL:3306 ssl  JS > c.describe() /* 或者 c.status() */
...
        "topologyMode": "Single-Primary"
...

P.S，强烈建议采纳单主模式，遇到 bug 或其余问题的概率更低，运行 MGR 更稳固牢靠。

在 MySQL 客户端命令行模式下，执行上面的命令即可：

-- 从单主切换为多主
[root@GreatSQL]> SELECT group_replication_switch_to_multi_primary_mode();
+--------------------------------------------------+
| group_replication_switch_to_multi_primary_mode() |
+--------------------------------------------------+
| Mode switched to multi-primary successfully.     |
+--------------------------------------------------+

-- 从多主切换为单主
[root@GreatSQL]> SELECT group_replication_switch_to_single_primary_mode();
+---------------------------------------------------+
| group_replication_switch_to_single_primary_mode() |
+---------------------------------------------------+
| Mode switched to single-primary successfully.     |
+---------------------------------------------------+

留神： 切换时会从新选主，新的主节点有可能不是切换之前的那个，这时能够运行上面的命令来从新指定：

[root@GreatSQL]> SELECT group_replication_set_as_primary('ed5fe7ba-37c2-11ec-8e12-70b5e873a570');
+--------------------------------------------------------------------------+
| group_replication_set_as_primary('ed5fe7ba-37c2-11ec-8e12-70b5e873a570') |
+--------------------------------------------------------------------------+
| Primary server switched to: ed5fe7ba-37c2-11ec-8e12-70b5e873a570         |
+--------------------------------------------------------------------------+

也能够通过 MySQL Shell 来操作：

MySQL  GreatSQL:3306 ssl  JS > var c=dba.getCluster()
> c.switchToMultiPrimaryMode()  /* 切换为多主模式 */
Switching cluster 'MGR27' to Multi-Primary mode...

Instance 'GreatSQL:3306' was switched from SECONDARY to PRIMARY.
Instance 'GreatSQL:3307' was switched from SECONDARY to PRIMARY.
Instance 'GreatSQL:3308' was switched from SECONDARY to PRIMARY.
Instance 'GreatSQL:3309' remains PRIMARY.

The cluster successfully switched to Multi-Primary mode.

> c.switchToSinglePrimaryMode()  /* 切换为单主模式 */
Switching cluster 'MGR27' to Single-Primary mode...

Instance 'GreatSQL:3306' remains PRIMARY.
Instance 'GreatSQL:3307' was switched from PRIMARY to SECONDARY.
Instance 'GreatSQL:3308' was switched from PRIMARY to SECONDARY.
Instance 'GreatSQL:3309' was switched from PRIMARY to SECONDARY.

WARNING: The cluster internal session is not the primary member anymore. For cluster management operations please obtain a fresh cluster handle using dba.getCluster().

WARNING: Existing connections that expected a R/W connection must be disconnected, i.e. instances that became SECONDARY.

The cluster successfully switched to Single-Primary mode.

> c.setPrimaryInstance('GreatSQL:3309');  /* 从新设置主节点 */
Setting instance 'GreatSQL:3309' as the primary instance of cluster 'MGR27'...

Instance 'GreatSQL:3306' was switched from PRIMARY to SECONDARY.
Instance 'GreatSQL:3307' remains SECONDARY.
Instance 'GreatSQL:3308' remains SECONDARY.
Instance 'GreatSQL:3309' was switched from SECONDARY to PRIMARY.

The instance 'GreatSQL:3309' was successfully elected as primary.

P.S，强烈建议采纳单主模式，遇到 bug 或其余问题的概率更低，运行 MGR 更稳固牢靠。

首先，能够执行上面的命令查看以后除了 PRIMARY 节点外，其余节点的 trx_tobe_applied 或 trx_tobe_verified 值是否较大：

[root@GreatSQL]> SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_verified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS trx_tobe_applied, COUNT_TRANSACTIONS_CHECKED AS trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED AS trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED AS proposed FROM performance_schema.replication_group_member_stats;
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| id                                   | trx_tobe_verified | trx_tobe_applied | trx_chkd | trx_done | proposed |
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| 4ebd3504-11d9-11ec-8f92-70b5e873a570 |                 0 |                0 |   422248 |        6 |   422248 |
| 549b92bf-11d9-11ec-88e1-70b5e873a570 |                 0 |           238391 |   422079 |   183692 |        0 |
| 5596116c-11d9-11ec-8624-70b5e873a570 |              2936 |           238519 |   422115 |   183598 |        0 |
| ed5fe7ba-37c2-11ec-8e12-70b5e873a570 |              2976 |           238123 |   422167 |   184044 |        0 |
+--------------------------------------+-------------------+------------------+----------+----------+----------+

其中，trx_tobe_applied 的值示意期待被 apply 的事务队列大小，trx_tobe_verified 示意期待被认证的事务队列大小，这二者任何一个值大于 0，都示意以后有肯定水平的提早。

另外，也能够查看接管到的事务和已执行完的事务之间的差距来判断：

[root@GreatSQL]> SELECT RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status WHERE  channel_name = 'group_replication_applier' UNION ALL SELECT variable_value FROM performance_schema.global_variables WHERE  variable_name = 'gtid_executed'\G
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET: 6cfb873b-573f-11ec-814a-d08e7908bcb1:1-3124520
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 6cfb873b-573f-11ec-814a-d08e7908bcb1:1-3078139

能够看到，接管到的事务 GTID 曾经到了 3124520，而本地只执行到 3078139，二者的差距是 46381。能够顺便继续关注这个差值的变动状况，估算出本地节点是否能追平提早，还是会加大提早。

Enjoy GreatSQL :)

技术分享 | MGR 最佳实际 (MGR Best Practice)
https://mp.weixin.qq.com/s/66…

技术分享 | 万里数据库 MGR Bug 修复之路
https://mp.weixin.qq.com/s/Ia…

Macos 零碎编译 percona 及局部函数在 Macos 零碎上运算差别
https://mp.weixin.qq.com/s/jA…

技术分享 | 利用 systemd 治理 MySQL 单机多实例
https://mp.weixin.qq.com/s/iJ…

产品 | GreatSQL，打造更好的 MGR 生态
https://mp.weixin.qq.com/s/By…

产品 | GreatSQL MGR 优化参考
https://mp.weixin.qq.com/s/5m…

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

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

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

微信 &QQ 群：

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

QQ 群：533341697
微信小助手：wanlidbc

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

正文完

mysql

发表至： mysql

2021-12-14

0

关于.net:NET-5NET-Core使用EF-Core-5连接MySQL数据库写入读取数据示例教程

关于mysql:MySQLWHERE子句-以及-逻辑操作符

关于mysql:免安装版的mysql常用命令

关于mysql:数据库之-游标的解读和使用

关于react.js:react源码解析10commit阶段

关于mysql:GreatSQL-MGR-FAQ

0. GreatSQL 简介

1. GreatSQL 的特色有哪些

2. GreatSQL 在哪里能够下载

二进制包、RPM 包

源码

Ansible 安装包

Docker 镜像

3. 应用 GreatSQL 遇到问题时找谁

4. GreatSQL 版本打算是怎么的

5. GreatSQL 反对读写拆散吗

6. 能够应用 MySQL Shell 来治理 GreatSQL 吗

7. 应用 MGR 有什么限度吗

8. MGR 最多可反对多少个节点

9. MGR 能够设置为自启动吗

10. MGR 反对读负载平衡吗

11. MGR 反对写负载平衡吗

12. MGR 绝对传统主从复制是不是会更耗 CPU、内存和带宽等资源

13. 为什么启动 MGR 后，多了个 33061 端口

14. 部署 MGR 时，务必对所有节点都设置 hostname 吗

15. 能够跨公网部署 MGR 吗

16. 怎么查看 MGR 以后是单主还是多主模式

17. 怎么切换单主或多主

18. 怎么查看 MGR 从节点是否有提早

文章举荐：

对于 GreatSQL

站内搜索