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

[toc]

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

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社区寻求帮忙。

微信搜寻增加 wanlidbc 增加GreatSQL社区助手<br/>

或申请加入GreatSQL社区QQ群（533341697）<br/>

此外，咱们曾经在B站公布MGR相干系列视频，能够返回学习，视频链接：https://space.bilibili.com/1363850082 。

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_certified 或 relaylog_tobe_applied 值是否较大：

[root@GreatSQL]> SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_certified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS relaylog_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_certified |relaylog_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 |+--------------------------------------+-------------------+---------------------+----------+----------+----------+

其中，relaylog_tobe_applied 的值示意近程事务写到relay log后，期待回放的事务队列，trx_tobe_certified 示意期待被认证的事务队列大小，这二者任何一个值大于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。能够顺便继续关注这个差值的变动状况，估算出本地节点是否能追平提早，还是会加大提早。

19. MySQL Router反对单机多实例部署吗

是的，反对。
在MySQL Router初始化部署时，增加 --name、--directory 及端口号等参数即可，例如：

-- 部署第一个实例root@GreatSQL# mysqlrouter --bootstrap mymgr@192.168.1.1:3306 --name=MGR1 --directory=/etc/mysqlrouter/MGR1  --user=mysqlrouter --conf-base-port=6446 --https-port=8443-- 部署第二个实例root@GreatSQL# mysqlrouter --bootstrap mymgr@192.168.1.1:4306 --name=MGR2 --directory=/etc/mysqlrouter/MGR2  --user=mysqlrouter --conf-base-port=7446 --https-port=9443

而后每个实例用各自目录下的 start.sh 和 stop.sh 脚本启停即可。

对于MySQL Router多实例部署的办法，能够参考这篇参考文档：《叶问》38期，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉。

20. 两个MGR集群间还能够构建主从复制关系吗

首先，答案是必定的，能够的。

其次，为了保障MGR的数据安全性，对不同角色节点的要求是这样的：

  • 在单主模式（Single-Primary）时，从节点（Secondary）不能同时作为Master-Slave的从节点（Slave）
  • 在单主模式时，主节点（Primary）能够同时作为M-S的从节点（Slave）
  • 在多主模式时，任何节点能够作为MS的从节点（Slave）。揭示：强烈建议不要应用多主模式
  • 要求都是InnoDB表，且没有数据抵触（例如数据反复、数据不存在等），没有应用外键
  • 节点重启时，留神要先启动MGR服务，再启动M-S服务。这时候能够设置 group_replication_start_on_boot=ON 和 skip_slave_start=ON 予以保障

在这两个MGR集群间的主从复制能够采纳异步复制，也能够采纳半同步复制，次要取决于两个集群间的网络提早状况及架构设计计划。这时候，整体架构计划相似上面这样：

在这个架构下，两个MGR集群间是互相独立的，如果前端挂载MySQL Router的话，须要独自创立对应的连贯。

如果放心MGR节点因为产生切换，只有原来指向的Master没有退出MGR集群，则这个主从复制关系还是存在的，不受影响。如果放心原来的Master节点退出MGR集群而导致复制中断，则能够采纳MySQL 8.0.22后推出的新个性 Async Replication Auto failover 来解决，把各节点都加到复制源中，能够参考上面的材料：

  • 金融利用场景下跨数据中心的MGR架构计划
  • Switching Sources and Replicas with Asynchronous Connection Failover
  • 视频：MGR是如何保障数据一致性的

21. 三节点的MGR集群，有两个节点宕机后还能失常工作吗

要看具体是哪种状况。

如果两个节点是失常敞开的话，则会向MGR集群发送退出信号，这种状况下，这两个节点属于失常退出，最初仅剩的节点会被晋升为Primary角色，还能够失常工作，容许对其进行读写，只是此时没有可用性冗余了。当其余节点再次启动并退出集群后，又能恢复正常服务。

如果是因为网络故障，或者mysqld过程产生oom、或被误杀、或其余起因退出了，则这些节点会被标识为 UNREACHABLE 状态，期待直到 group_replication_member_expel_timeout 时长（单位：秒）后这个节点才会正式退出集群。在这种状况下，一旦超过多数派节点处于 UNREACHABLE 状态时，则整个集群不可用，无奈提供读写服务。这种状况下，须要把剩下的节点重启MGR服务能力复原。

失常状况下，不要把 group_replication_member_expel_timeout 值调整太大，并且MGR的事务一致性级别尽量不要抉择 AFTER 模式，以防呈现整个集群服务不可用的问题，具体参见这篇文章：为什么MGR一致性模式不举荐AFTER。

22. MGR能够像主从复制那样只启动两个节点吗

MGR在初始化启动时，是能够只启动两个节点，甚至只有一个节点，然而这样就失去MGR的意义了。因为只有少于三个节点，就没方法进行多数派投票，当产生网络故障等状况时，无奈投票确认哪些节点该被踢出集群。

23. MGR中能够创立无主键的InnoDB表吗

是能够的，并且会复制到所有MGR节点，然而仅能创立空表，业务上不能写入数据。

往无主键的InnoDB表中写入数据时，会报告相似上面的谬误：

[root@GreatSQL] [test]> insert into t3 select 1;ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

同理，也能够创立MyISAM表，但写入时会提醒失败。

此外，当欲退出MGR集群的新实例中有无主键的InnoDB表时，如果要通过 MySQL Shell 增加该节点，会收回相似上面的报错，无奈退出：

Validating instance configuration at mgr03:3306...This instance reports its own address as mgr03:3306ERROR: The following tables do not have a Primary Key or equivalent column:test.t3Group Replication requires tables to use InnoDB and have a PRIMARY KEY or PRIMARY KEY Equivalent (non-null unique key). Tables that do not follow these requirements will be readable but not updateable when used with Group Replication. If your applications make updates (INSERT, UPDATE or DELETE) to these tables, ensure they use the InnoDB storage engine and have a PRIMARY KEY or PRIMARY KEY Equivalent.If you can't change the tables structure to include an extra visible key to be used as PRIMARY KEY, you can make use of the INVISIBLE COLUMN feature available since 8.0.23: https://dev.mysql.com/doc/refman/8.0/en/invisible-columns.htmlERROR: Instance must be configured and validated with dba.checkInstanceConfiguration() and dba.configureInstance() before it can be used in an InnoDB cluster.Cluster.addInstance: Instance check failed (RuntimeError)

这个报错在MySQL 8.0.25仍然存在，据说在MySQL 8.0.27失去解决。

如果改成手动退出新节点，或者间接删除无主键表，则能够胜利。

从下面的谬误提醒也能看进去，如果创立一个和主键等价的惟一索引（且要求不容许为NULL），该惟一索引可用做InnoDB表的汇集索引，就不会再报错了，业务也能失常写入数据。

24. MySQL Router能够配置在MGR主从节点间轮询吗

MySQL Router通过两个端口来辨别读写服务申请，默认是 6446端口提供读写服务，6447端口提供只读服务。
在单主模式下，读写服务只会连贯到Primary节点。对于读写服务端口，可选的策略有以下两种：

  • first-available，只连贯第一个可用节点
  • round-robin（默认），在多个主节点间轮询

只读服务默认是对所有Secondary节点轮询。对于只读服务端口，可选的策略有以下X种：

  • first-available，只连第一个可用节点
  • round-robin，在所有可用Secondary节点间轮询，如果所有Secondary节点都不可用时，只读服务则不可用，不会连贯到Primary节点
  • round-robin-with-fallback（默认），在所有Secondary节点间轮询。如果所有Secondary节点都不可用时，会再连贯到Primary节点

当初咱们晓得了，MySQL Router只有在所有Secondary节点都不可用时，才会去连贯Primary节点读数据，无奈做到在发动只读申请时，同时连贯主从节点。

更多对于 MySQL Router 可用的策略请参见文档 routing_strategy参数/选项。

25. 都有哪些状况可能导致MGR服务无奈启动

简略整顿了下，大略有以下起因可能导致MGR服务无奈启动：

  1. 网络起因，例如网络原本就不通，或被防火墙拦住。防火墙通常至多有两道，操作系统默认的firewall策略，以及云主机被默认的安全策略。
  2. 第一个启动的节点没先做初始疏导操作（group_replication_bootstrap_group=ON）。
  3. 没有正确配置group_name，所有节点的 group_replication_group_name 值要统一才能够。
  4. 没正确配置 group_replication_group_name，常见于老手。要为MGR服务专门新开一个服务端口，罕用33061端口，但老手可能会照样写成3306端口。
  5. 通常，咱们会在各MGR节点的 hosts 文件里加上所有节点的hostname。这是为了避免本地节点应用的hostname和MGR收到的hostname不统一，这种状况下，能够在每个本地节点设置 report-host，被动上报hostname即可解决。
  6. 没设置正确的allowlist。有可能退出MGR各节点的IP不在默认的allowlist中，可参考这篇文章：MySQL Group Replication集群对IP地址的限度导致的一些问题与解决办法。
  7. 个别节点的本地事务更多，例如误操作写入数据，也会无奈退出MGR，这种状况须要重建本地节点。
  8. 个别节点的本地事务缺失太多，且退出MGR时无奈主动实现复原，这种状况比拟少见，须要手动执行clone复制数据，或者其余相似操作。

26. MySQL Shell 8.0能治理MySQL 5.7的MGR集群吗

答案是必定的。

不过因为MySQL 5.7里没有MGR治理的几个UDF，因而在MySQL Shell里调用 setPrimaryInstance()、switchToMultiPrimaryMode() 等函数时会报错，是不反对的。

所以说，还是尽量降级到MySQL 8.0吧。

27. GreatSQL怎么备份

能够利用GreatSQL安装包中提供的mysqldump工具执行逻辑备份。

也能够利用雷同版本号的Percona Xtrabackup执行物理备份，例如利用Percona XtraBackup 8.0.25-17备份GreatSQL 8.0.25-15、GreatSQL 8.0.25-16版本，利用Percona XtraBackup 2.4备份GreatSQL 5.7.36-39版本。

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