关于mysql:GreatSQL-FAQ

15次阅读

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

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

[toc]

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

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

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

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

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

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_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。能够顺便继续关注这个差值的变动状况，估算出本地节点是否能追平提早，还是会加大提早。

是的，反对。
在 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 整个集群挂掉后，如何能力主动选主，不必手动干涉 。

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

其次，为了保障 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 是如何保障数据一致性的

要看具体是哪种状况。

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

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

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

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

是能够的，并且会复制到所有 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:3306
ERROR: The following tables do not have a Primary Key or equivalent column:
test.t3

Group 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.html

ERROR: 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 表的汇集索引，就不会再报错了，业务也能失常写入数据。

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 参数 / 选项 。

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

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

答案是必定的。

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

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

能够利用 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 公布！

正文完

mysql

发表至： mysql

2022-05-16

0

关于mysql:云溪数据库delete流程解读

关于mysql:进来偷学一招数据归档二三事儿

关于mysql:MySQL-入门教程第-01-篇-MySQL-简介

关于mysql:MySQL的数据库操作

关于开源:开源之夏502个项目上线最火热的暑期开源活动发车了

关于mysql:GreatSQL-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 从节点是否有提早

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

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

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

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

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

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

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

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

27. GreatSQL 怎么备份

文章举荐：

站内搜索