活动 | GreatSQL社区亮相2023 DTC 分享开源技术成果实践

Posted GreatSQL

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了活动 | GreatSQL社区亮相2023 DTC 分享开源技术成果实践相关的知识，希望对你有一定的参考价值。

4月7-8日，年度数据库行业盛会——2023数据技术嘉年华（DTC 2023）如期而至。

此次盛会汇聚了全国各地数千名数据领域学术精英、领袖人物、技术专家、从业者和技术爱好者，共同见证行业蓬勃发展、生态融合共赢、技术迭代升级及市场风云变迁。

GreatSQL作为万里数据库主导成立的开源数据库社区，首次亮相嘉年华大会，并带来开源社区的技术成果与应用探索，助力数据库产业建设与生态繁荣。

投身开源 打造广受欢迎的开源数据库社区

开源作为持续创新的催化剂，使组织能够快速获得全球人才库和开发安全、可靠、可扩展的软件工具，正在成为推动科技产业发展的一大动力，在大数据、人工智能、云计算等信息技术领域运用非常广泛。

4月8日开源创新分论坛上，万里数据库CTO娄帅发表题为《GreatSQL开源社区——做中国广受欢迎的开源数据库》的主题演讲。娄帅拥有超10年数据库研发经验，先后从事数据库服务器、数据库架构、国产分布式数据库等产品技术研发工作，对数据库技术路线、产品架构、应用场景有深厚积淀与理解，可主导产品从0到1的架构设计、研发与实现。

娄帅表示，万里数据库作为关系型数据库重要的开拓者和实践者，深知开源的重要性。公司积极投身于开源生态建设，于2021年主导创立GreatSQL开源数据库社区，将自身成熟的数据库技术开源，并在国内吸引了超过2000名参与者与技术爱好者的关注与贡献，目前已成长为国内活跃的MySQL技术路线开源社区，获得中国信通院“可信开源项目认证”及“Gitee最有价值开源项目”荣誉。

社区核心开源项目GreatSQL数据库源于Percona Server分支，在其既有的稳定可靠、高效和管理等优势基础上，进一步优化了MGR功能特性，新增地理标签功能，支持快速单主模式和仲裁节点，大幅提升稳定性。

同时，GreatSQL合并了华为鲲鹏计算团队贡献的针对OLTP和OLAP两种业务场景的2个Patch，尤其是InnoDB并行查询特性，TPC-H测试中平均提升聚合分析型SQL性能15倍，最高提升40多倍。

在今年10月，MySQL开源数据库中使用最为广泛的5.7版本即将停服，这使得部署在MySQL5.7上的业务系统面临安全层面和保障层面的隐患，用户面临停服后系统如何进行更新、维护、迁移等问题。GreatSQL相较官方MySQL官方版本，速度更快、并发更高、功能更强，特别适用于周期性数据汇总报表之类的SAP、财务统计等业务，且满足国产化要求，是替代官方开源MySQL的最佳选择。

本次展会上，GreatSQL社区与万里数据库联合参展，在展位上展示社区成立2年来的开源技术探索与成果，与参会嘉宾共同探讨数据库的产品技术与社区生态建设，获得了广泛的互动交流与参观。

以匠心致初心，创新从未止步。 数据库作为底层通用的关键核心技术，关系信息系统根本，是数字经济的坚实底座支撑，致力于发展为造福人民的“国之重器”。GreatSQL社区致力于打造国内MySQL技术路线根分支，未来将在万里数据库的引领和众多生态伙伴、技术爱好者的合力贡献下，实现快速发展，以开源的蓬勃之力，助力数据库产业生态光明未来！

Enjoy GreatSQL

GreatSQL MGR FAQ

本文首发于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从节点是否有延迟

关于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的优势可阅读下面几篇文章：

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/GreatSQL-Ansible/releases

  • https://github.com/GreatSQL/GreatSQL-Ansible/releases

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

扫码添加GreatSQL社区助手

或扫码加入GreatSQL社区QQ群（533341697）：

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 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服务无法启动。

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。可以顺便持续关注这个差值的变化情况，估算出本地节点是否能追平延迟，还是会加大延迟。

本文档同步在gitee及github更新，地址

- https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/docs/GreatSQL-FAQ.md

- https://github.com/GreatSQL/GreatSQL-Doc/blob/master/docs/GreatSQL-FAQ.md

Enjoy GreatSQL :)

《实战MGR》视频课程

戳此小程序即可直达B站

或复制链接在浏览器中打开

  • https://space.bilibili.com/1363850082

文章推荐：

点击文末“阅读原文”直达老叶专栏

以上是关于活动 | GreatSQL社区亮相2023 DTC 分享开源技术成果实践的主要内容，如果未能解决你的问题，请参考以下文章

GreatSQL 8.0.25-17今日发布

GreatSQL 8.0.25-17今日发布

速速报名| 米尔将精彩亮相2023 STM32中国峰会暨粉丝狂欢节

社区活动(深圳)2023年深圳.NET线下技术沙龙要开始了

自制GreatSQL Docker镜像

CSDN 亮相 2023 全球人工智能开发者先锋大会