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

[toc]

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

Last Update: 2021.12.10。

0. GreatSQL简介

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

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

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

1. GreatSQL的特色有哪些

绝对于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正式开源

2. GreatSQL在哪里能够下载

二进制包、RPM包

二进制包下载地址：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

Ansible安装包

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

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

Docker镜像

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

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

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

QQ群：533341697

微信小助手：wanlidbc

4. GreatSQL版本打算是怎么的

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

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

5. GreatSQL反对读写拆散吗

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

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

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

7. 应用MGR有什么限度吗

上面是对于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

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

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

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

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

10. MGR反对读负载平衡吗

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

11. MGR反对写负载平衡吗

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

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

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

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

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

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

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

这个不是必须的。

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

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

15. 能够跨公网部署MGR吗

能够的，但十分不举荐。

此外，因为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 A172.16/12 prefix  (172.16.0.0 - 172.31.255.255) - Class B192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class CIPv6 (as defined in RFC 4193 and RFC 5156)fc00:/7 prefix    - unique-local addressesfe80::/10 prefix  - link-local unicast addresses127.0.0.1 - localhost for IPv4::1       - localhost for IPv6

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

16. 怎么查看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更稳固牢靠。

17. 怎么切换单主或多主

在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更稳固牢靠。

18. 怎么查看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

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 公布！