GreatSQL出品技术文章-腾讯云开发者社区

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

GreatSQL出品技术文章

专栏成员

258

文章

170336

阅读量

31

订阅数

GreatSQL 构建高效 HTAP 服务架构指南（MGR）

部署测试服务架构数据

本服务架构采用 GreatSQL MGR 架构，在 MGR 架构中部署一个专属 HTAP 服务节点。Primary 节点采用默认 InnoDB 引擎，Secondary 节点使用辅助引擎 Rapid 加速查询构建专属 HTAP 只读节点。加上 MySQL Router 等之类的代理/中间件负责读写分离来完成 HTAP 服务架构。

2024-07-26

1110

独家揭秘丨GreatSQL 没开Binlog时多线程插入数据性能劣化之谜

线程效率性能多线程数据

GreatSQL参数配置如下（为降低 I/O 因素影响，关闭 Binlog）： #**********************Performance********************* #******connect max_connections=10000 max_connect_errors=1000000 open_files_limit=65535 back_log=1500 table_definition_cache=10000 thread_stack=256K thread_cache_size=3000 #******session sort_buffer_size=4M join_buffer_size=4M read_buffer_size=4M read_rnd_buffer_size=4M bulk_insert_buffer_size=64M tmp_table_size=64M max_heap_table_size=64M net_buffer_length=16K max_allowed_packet=1G #******timeout lock_wait_timeout=600 connect_timeout=10 interactive_timeout=31536000 wait_timeout=31536000 net_read_timeout=86400 net_write_timeout=86400 net_retry_count=10 #**********************InnoDB************************** transaction_isolation=READ-COMMITTED innodb_buffer_pool_size=200G innodb_buffer_pool_instances=16 innodb_max_dirty_pages_pct=90 innodb_flush_log_at_trx_commit=0 innodb_log_buffer_size=1G innodb_page_cleaners=8 innodb_buffer_pool_dump_at_shutdown=ON innodb_buffer_pool_load_at_startup=ON innodb_buffer_pool_dump_pct=100 innodb_checksum_algorithm=NONE innodb_log_checksums=NO innodb_undo_log_truncate=OFF innodb_change_buffering = none innodb_spin_wait_delay=6 innodb_spin_wait_pause_multiplier=50 innodb_sync_spin_loops=30 #******feature innodb_open_files=65535 innodb_flush_method=O_DIRECT innodb_flush_neighbors=0 innodb_flush_sync=ON innodb_io_capacity=20000 innodb_io_capacity_max=40000 innodb_lru_scan_depth=9000 innodb_lock_wait_timeout=30 innodb_print_all_deadlocks=ON innodb_online_alter_log_max_size=4G innodb_thread_concurrency=0 innodb_read_io_threads=32 innodb_write_io_threads=32 innodb_doublewrite=ON innodb_doublewrite_pages=64 innodb_adaptive_hash_index=OFF innodb_status_file=OFF 1、窄表 + 有自增主键 greatsql> CREATE TABLE t1 ( c1 int invisible auto_increment primary key, c2 int, str1 int DEFAULT(100) NOT NULL, str2 int DEFAULT(100) NOT NULL, str3 int DEFAULT(100) NOT NULL, str4 int DEFAULT(100) NOT NULL ) engine=InnoDB; greatsql> CREATE TABLE t2 LIKE t1; 行平均长度约 30 字节行数插入sql线程数总用时解释1000万行insert into t2 sel

2024-07-26

860

GreatSQL 构建高效 HTAP 服务架构指南（主从复制）

架构数据中间件服务服务器

引言全文约定：$为命令提示符、greatsql>为 GreatSQL 数据库提示符。在后续阅读中，依据此约定进行理解与操作 Rapid 引擎从 GreatSQL 8.0.32-25 版本开始，新增Rapid存储引擎，该引擎使得 GreatSQL 能满足联机分析（OLAP）查询请求。 GreatSQL Rapid引擎性能表现优异，在32C64G测试机环境下，TPC-H 100G测试中22条SQL总耗时仅需不到80秒

2024-07-16

960

FILE+POS 方式 GreatSQL 主从复制架构给主节点磁盘扩容

数据线程 file 磁盘架构

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。一、前提在一套非常老的系统上，有一套GreatSQL主从集群（1主1从），主从复制采用的是FILE+POS方式复制，磁盘使用紧张需要扩容，只能在该台机器上添加更大的磁盘，将原数据盘替换，也没有其他的机器资源替换。这套系统没有VIP，没有高可用切换工具，业务读写直连主节点，从节点可供读，允许有一定的延迟，全程磁盘扩容需要手动操作，以下方案步骤是模拟最快的方式去进行磁盘扩容。二、整体思路是在主节点机器上挂载一块新磁盘，在新磁盘上搭建一个新的从节点，旧从节点的主变为新从节点，最后将主节点与新从节点准备好配置文件后，关闭主节点，将新从节点使用新的配置文件重启，端口号为旧主port，新主实例顶替旧主成功。三、模拟环境主从架构 db01:master，172.17.135.81:3306 db02:slave02，172.17.134.225:3306 原主从db01 master复制数据到db02 slave02，现在在db01上搭建新的从节点slave01，并将slave01提升为新的主节点master02 db01：IP为172.17.135.81 master ：port 3306 slave01：port 3307 db02：IP为172.17.134.225 slave02：port 3306 四、以下操作为模拟切换流程 1）.在db01上master 数据放在磁盘 /data/ 使用xtrabackup工具备份并搭建db01 slave01 数据放在磁盘/data2/上 2）.改变db02 slave02 数据源为 db01 slave01（即db02 slave02 从db01-slave01同步数据），后期切换数据库操作过程 01.停掉db02 slave02 复制线程先停slave02目的是，slave02获取执行的binlog比db01 slave01上的binlog少，方便后续db02 slave02 追数据到db01 slave01 指定的位点

2024-07-16

700

官答丨操作系统升级 Openssl 导致 GreatSQL 无法启动

配置数据库 openssl 操作系统服务

本问题来自讨论区群，用户使用数据库环境大概介绍如下：名称版本操作系统CentOS 7系统内核版本3.10.0-1160.118.1.el7.x86_64openssl升级之前版本1.0.2kopenssl升级之后版本1.1.1w数据库版本GreatSQL-8.0.32-25 用户问题用户提供的问题信息内容如下： 1、Openssl 版本升级之后 GreatSQL 无法启动报错如下： -- Unit mysqld.service has begun starting up. Jun 07 14:03:21 m-node1 mysqld[34078]: /usr/local/GreatSQL/bin/mysqld: /usr/local/openssl/lib/libcrypto.so: version `OPENSSL_1.0.1_EC' not found (required by /usr/local/GreatSQL/bin/../lib/private/libssl.so.10) Jun 07 14:03:21 m-node1 mysqld[34078]: /usr/local/GreatSQL/bin/mysqld: /usr/local/openssl/lib/libcrypto.so: version `libcrypto.so.10' not found (required by /usr/local/GreatSQL/bin/../lib/private/libssl.so.10) Jun 07 14:03:21 m-node1 systemd[1]: mysqld.service: control process exited, code=exited status=1 Jun 07 14:03:21 m-node1 systemd[1]: Failed to start MySQL Server. 2、用户经过检查，再次安装了 GreatSQL 的 rpm 依赖包，依然报错 so 动态库文件问题 $ yum install -y pkg-config perl libaio-devel numactl-devel numactl-libs net-tools openssl openssl-devel jemalloc jemalloc-devel perl-Data-Dumper perl-Digest-MD5 python2 perl-JSON perl-Test-Simple 3、将 GreatSQL 命令配置到环境变量 PATH 中，依然报错 so 动态库文件问题 $ ln -s /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64 /usr/local/greatsql $ vim /etc/profile export PATH=$PATH:/usr/local/greatsql/bin $ source /etc/profile $ mysql -V mysql: /usr/local/openssl/lib/libcrypto.so: version `libcrypto.so.10' not found (required by mysql) mysql: /usr/local/openssl/lib/libssl.so: version `libssl.so.10' not found (required by mysql) 解答用户疑问根据现象及报错内容分析，推测极可能是在 /usr/local 目录下安装了更高版本的 Openssl，导致动态库链接失败。这种情况可以把 Openssl 下的 lib 库加载到 LD_LIBRARY_PATH 环境变量中。解决用户问题将 Openssl 下的 lib 库加载到 LD_LIBRARY_PATH 环境变量中。意思也是为了，不将 /usr/local/openssl/lib 加载到 LD_LIBRARY_PATH 中了。 $ vim /etc/profile export LD_LIBRARY_PATH=/usr/lib64 $ source /etc/profile 使用ldd命令检查mysqld是否缺失依赖so库文件 $ ldd mysqld | grep ssl libssl.so.10 => /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17- x86_64/bin/./../lib/private/libssl.so.10 (0x00007f292ed72000) $ ldd mysql | grep ssl libssl.so => /lib64/libssl.so (0x000

2024-07-06

1020

Percona Toolkit 神器全攻略（监控类）

监控连接事务主机工具

pt-deadlock-logger 概要提取和记录MySQL/GreatSQL死锁用法

2024-07-06

1070

GreatSQL 中 Insert 慢是什么情况？

主机数据库 insert lock 事务

2024-07-06

920

Percona Toolkit 神器全攻略（配置类）

服务器工具配置数据库变量

pt-config-diff 概要比较 MySQL/GreatSQL 配置文件和服务器变量用法

2024-06-21

1080

MySQL5.7 通过逻辑备份迁移到GreatSQL注意事项

数据系统迁移备份权限

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。一、背景概述在将数据库从MySQL 5.7迁移到GreatSQL8.0.32时，由于数据量较小且关注安全性，决定使用mysqldump执行逻辑备份，并将数据导入GreatSQL。但在备份时采用了备份全库(--all-databases)的方式，在导入GreatSQL后，修改用户密码时出现错误。这是因为mysqldump备份时包括了mysql系统库，而MySQL 5.7中的mysql系统库采用了MyISAM存储引擎，而GreatSQL的mysql系统库采用了InnoDB存储引擎。因此，在导入数据后，部分系统表被覆盖，导致了错误的出现。二丶问题复现 1.部署2个实例部署MySQL 5.7与GreatSQL 8.0.32，具体步骤省略 2.MySQL 创建测试数据通过sysbench创建10张表 $ sysbench lua/oltp_read_write.lua --mysql-db=sysbench --mysql-host=192.168.1.162 --mysql-port=6003 --mysql-user=root --mysql-password=greatsql --tables=10 --table_size=5000 --report-interval=2 --threads=10 --time=600 --mysql-ignore-errors=all prepare 3.MySQL 创建测试用户 mysql> create user test1@'%' identified by 'greatsql'; Query OK, 0 rows affected (0.01 sec) mysql> grant all on *.* to test1@'%'; Query OK, 0 rows affected (0.01 sec) 4.MySQL进行全库备份 $ /mysql57/svr/mysql/bin/mysqldump -uroot -pgreatsql -h192.168.1.162 -P6003 --single-transaction --set-gtid-purged=OFF --all-databases > all.sql 5.GreatSQL导入备份数据 greatsql> source all.sql; 在导入过程中有如下报错，从这里可以看出导入时有系统表被导入，并且部分系统表不支持被修改：

2024-06-11

850

Percona Toolkit 神器全攻略（实用类）

存储工具加密连接数据

Percona Toolkit 神器全攻略系列共八篇，前文回顾：前文回顾Percona Toolkit 神器全攻略全文约定：$为命令提示符、greatsql>为GreatSQL数据库提示符。在后续阅读中，依据此约定进行理解与操作实用类在Percona Toolkit中实用类共有以下工具

2024-05-30

1380

官答丨slow_query_log_file实例内存中变量与配置文件设置的不一致

数据库 file 变量内存配置

官答栏目针对GreatSQL数据库中的问题，选取官方论坛和讨论群中的典型提问进行深入解答。内容涵盖数据库安装部署、配置优化、故障排查、性能测试等方面。在文章中，我们不仅提供解决方案，还会结合实例深入剖析问题的成因，提升读者对GreatSQL数据库的理解能力。如果你在管理、使用GreatSQL数据库时遇到棘手的技术难题，想系统地学习提高数据库技能，就来看看官答的文章吧。这里不仅可以找到可靠的解决方法，还能从中学习到数据库优化的经验和思路。通过阅读官答的内容，可以全面地掌握GreatSQL数据库管理的技能，熟练应对各种故障情况。快来关注官答栏目，与我们一起成长!

2024-05-30

1070

Percona Toolkit 神器全攻略

工具监控配置日志系统

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略系列共八篇分为文章名文章名Percona Toolkit 神器全攻略Percona Toolkit 神器全攻略（实用类）Percona Toolkit 神器全攻略（配置类）Percona Toolkit 神器全攻略（监控类）Percona Toolkit 神器全攻略（系统类）Percona Toolkit 神器全攻略（开发类）Percona Toolkit 神器全攻略（复制类）Percona Toolkit 神器全攻略（性能类）全文约定：$为命令提示符、greatsql>为GreatSQL数据库提示符。在后续阅读中，依据此约定进行理解与操作 Percona Toolkit 简介 Percona Toolkit简称（PT工具），是一组高级命令行工具，用于管理MySQL/GreatSQL的工具。可以用它来执行各种难以手动执行的MySQL/GreatSQL和系统任务。其功能包括检查主从复制的数据一致性、检查重复索引、定位IO占用高的表文件、在线DDL等，DBA熟悉掌握PT工具后将极大提高工作效率。

2024-05-20

1130

GreatSQL5.7数据库DROP表后无法重建

数据库 app table 备份测试

一、数据库信息：数据库版本：5.7.21-log 某银行测试数据库，APP业务库内有一个含有大量（几百个）分区表的大表test_app。DROP该分区表的大表后导致无法重建该分区表。二、问题描述：客户使用“drop table test_app;”时，显示表删除成功。当重新执行该表的建表语句时，报错“Table 'app.test_app /* Partition p0 */' already exists” 三、问题分析： 3.1> 原因是GreatSQL 5.7数据库DDL没有原子性，drop表的删除动作没有执行完成； 3.2> 进入数据库“show tables”查看test_app表已不存在； 3.3> 进入数据库所在的目录下，查看test_app表的相关文件。test_app.frm文件已不存在，但是有大量的"test_app#P***.ibd"分区表文件存在。关闭数据库，移除这些分区表文件到其他目录，启动数据库；数据库无法启动，报“无法找到这些分区表文件”的错误； 3.4> 重新创建test_app表时，报“table already exists”错。 3.5> 感觉进入了死胡同，最先想到的直截了当方法是备份APP业务库内除这张表的其他表，删除该数据库后，进行APP业务数据库的恢复，该方法没有测试，觉得太麻烦。四、问题处理（方法一，测试步骤）： 4.1> 新建一个临时库test，依据app库目录里的数据文件名称，修改建表语句后，执行test_app表的建表SQL语句，生成test_app.frm文件； 4.2> 关闭数据库，修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=OFF”； 4.3> 把临时库test目录下的test_app.frm文件拷贝到业务数据库app目录下，启动数据库； 4.4> 进入业务数据库APP，可以看到test_app表； 4.5> 执行“drop table test_app;”语句，成功删除了表。关闭数据库； 4.6> 进入业务数据库app对应的目录下，test_app.frm文件已不存在，但是有个test_app#P***.ibd分区表文件存在。手工删除该ibd文件。 4.7>修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=ON”;启动数据库。 4.8> 重新执行test_app表的建表SQL语句。即可成功创建表。五、问题处理（方法二，客户执行步骤）： 5.1> 设置innodb_file_per_table=OFF：set global innodb_file_per_table='OFF'; 5.2> 执行test_app表的建表语句，建表成功。 5.3> 删除test_app表drop table test_app； 5.4> 重启数据库。 5.5> 再执行test_app表的建表语句，建表成功。

2024-05-20

790

GreatSQL社区月报 | 2024.04

数据库开源博客事件优化

GreatSQL 成立于 2021 年，由万里数据库发起，是开放原子开源基金会旗下捐赠项目，及 Gitee 最有价值项目，拥有信通院可信开源社区+可信开源项目双认证。社区致力于通过开放的社区合作，构建自主开源数据库版本及开源数据库技术，推动开源数据库及应用生态繁荣发展。为了帮助社区的小伙伴们更好地了解 GreatSQL 社区的实时进展，我们决定每月更新发布一次 GreatSQL 社区月报。月报的主要内容包括：整理展示最近一个月的社区大事动态，最近一个月内为项目提交过 Commit 的贡献者，并对近期重要的 PR 进行解析；同时还包含了社区上一个月发布的原创技术博客整理分类。如果大家还希望未来在社区月报中增添哪些内容，也欢迎到“社区论坛→建议反馈”版块中发帖提出：https://greatsql.cn/forum-39-1.html

2024-05-20

870

GreatSQL的sp中添加新的sp_instr引入的bug解析

bug class 开发内存配置

2024-05-11

980

Slave SQL线程与PXB FTWRL死锁问题分析

sql 备份日志事务线程

144 Coordinator线程分发relay log中事务时发现这个事务不能执行，要等待前面的事务完成提交，所以处于waiting for dependent transaction to commit的状态。145/146线程和备份线程162形成死锁，145线程等待162线程 global read lock 释放，162线程占有MDL::global read lock 全局读锁，申请全局commit lock的时候阻塞等待146线程，146线程占有MDL:: commit lock，因为从库设置slave_preserve_commit_order=1，保证从库binlog提交顺序，而146线程执行事务对应的binlog靠后面，所以等待145的事务提交。最终形成了145->162->146->145的死循环，形成死锁。三个线程相互形成死锁，还是很少见的。 2.2 相关参数为何未生效 --ftwrl-wait-timeout=60　指的是执行FTWRL之前，如果检测到存在长SQL，先等待指定时间（秒），如果超时后还存在长SQL，则备份报错退出。默认为0则表示立即执行。 --ftwrl-wait-threshold=5 指的是执行FTWRL之前，检测长SQL的方法，如果在执行flush前存在已经运行了超过指定时间（秒）的SQL，则将该SQL定义为长SQL，默认60s。 --kill-long-queries_timeout=0 在执行FTWRL后，如果flush操作被阻塞了N秒，则kill掉阻塞它的线程，默认0的情况就是不kill任何阻塞flush的SQL，直到该SQL执行完成。从上面各个参数的解释，不难看出，--ftwrl-wait-*参数是针对执行FTWRL之前的长SQL检测机制，对于已执行FTWRL时无济于事，--kill-long-*参数则是设置默认值0，不起任何作用。 3. 结论与建议

2024-04-30

1090

GreatSQL统计信息相关知识点

磁盘数据索引统计优化

非持久化统计信息的缺点显而易见，数据库重启后如果大量表开始更新统计信息，会对实例造成很大影响，所以目前都会使用持久化统计信息。 2、持久化统计信息在以下情况会被自动更新：

2024-04-25

910

Datax助力轻松迁移SQLServer数据至GreatSQL

容器迁移配置数据数据库

2.1.4使用数据库 1.进入容器 $ docker exec -it sqlserver2017 bash 2.连接数据库 $ /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P "********" 3.查询数据库 1> select name from sys.Databases; 2> go 4.创建数据库 1> create database testdb; 2> go 5.创建表并插入数据 use testdb create table t1(id int) go Insert into t1 values(1),(2) go 2.2安装GreatSQL环境使用Docker镜像进行安装，直接拉取GreatSQL镜像即可 $ docker pull greatsql/greatsql 并创建GreatSQL容器 $ docker run -d --name greatsql --hostname=greatsql -e MYSQL_ALLOW_EMPTY_PASSWORD=1 greatsql/greatsql 2.3安装datax DataX安装需要依赖的环境

2024-04-25

1140

GreatSQL 死锁案例分析

lock object record 事务数据

2024-04-19

540

GreatSQL优化技巧：半连接(semijoin)优化

技巧连接索引优化 null

半连接是在GreatSQL内部采用的一种执行子查询的方式，semi join不是语法关键字，不能像使用inner join、left join、right join这种语法关键字一样提供给用户来编写SQL语句。

2024-04-18

880

点击加载更多

社区活动

【纪录片】中国数据库前世今生

穿越半个世纪，探寻中国数据库50年的发展历程

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态