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

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

GreatSQL出品技术文章

专栏作者

247

文章

145208

阅读量

31

订阅数

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

80

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

80

GreatSQL社区月报 | 2024.04

数据库开源博客事件优化

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

2024-05-20

70

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

bug class 开发内存配置

2024-05-11

800

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

890

GreatSQL统计信息相关知识点

磁盘数据索引统计优化

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

2024-04-25

750

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

690

GreatSQL 死锁案例分析

lock object record 事务数据

2024-04-19

340

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

技巧连接索引优化 null

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

2024-04-18

660

主从延迟调优思路

线程硬件变量配置事务

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 1、什么是主从延迟？本质是从库的回放跟不上主库，回放阶段的延迟

2024-04-18

980

从库延迟案例分析

事务数据算法统计线程

持续观察了一阵show slave status的变化，发现pos点位信息在不停的变化，Seconds_Behind_master也是不停的变化的，总体趋势还在不停的变大。资源使用观察了服务器资源使用情况，可以看到占用非常低

2024-04-12

790

5.7打补丁—编译和官方一致的Linux_Generic包

操作系统二进制源码 linux 编译

MySQL 5.7.21二进制包下载地址：(https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.21-linux-glibc2.12-x86_64.tar.gz) MySQL 5.7.21源码仓库github地址：(https://github.com/mysql/mysql-server/tree/mysql-5.7.21) MySQL 5.7的手册中"根据源码安装MySQL：(https://dev.mysql.com/doc/refman/5.7/en/source-installation.html)"章节中有如下内容，可参考"docs/INFO_BIN"文件中的内容获取官方编译时的环境信息： If you are interested in building MySQL from a source distribution using build options the same as or similar to those use by Oracle to produce binary distributions on your platform, obtain a binary distribution, unpack it, and look in the docs/INFO_BIN file, which contains information about how that MySQL distribution was configured and compiled. 解压安装包查看"docs/INFO_BIN"文件，可看到一系列的编译相关信息，其中kernel和cmake版本信息如下： Build was done on Linux-3.8.13-16.2.1.el6uek.x86_64 using x86_64 Build was done using cmake 2.8.12 根据kernel命名，可确定MySQL官方用的是Oracle Linux操作系统，对应的版本是6.5。镜像及下载地址如下： (https://mirrors.kernel.org/oracle/OL6/U5/x86_64/OracleLinux-R6-U5-Server-x86_64-dvd.iso) 在virt-manager（基于kvm的虚拟化）创建的虚拟机上安装操作系统，安装期间提示hardwarre不受支持。忽略错误强制安装操作系统后，启动失败。

2024-04-11

710

MySQL的多层SP中Cursor的m_max_cursor_index相关BUG分析

开发 bug cursor max mysql

2024-04-11

650

GreatSQL 优化技巧：将 MINUS 改写为标量子查询

优化 rows 存储过程技巧数据

2024-04-11

840

为什么SHOW TABLE STATUS显示Rows少了40%

统计 rows show status table

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

2024-04-11

560

探究网络延迟对事务的影响

同步网络延迟数据库事务数据

2024-04-11

840

工具分享丨分析GreatSQL Binglog神器

事件事务工具排序日志

在GreatSQL中，Binlog可以说是 GreatSQL 中比较重要的日志了，在日常开发及运维过程中经常会遇到。Binlog即Binary Log，二进制日志文件，也叫作变更日志（Update Log）。详细Binglog日志介绍：https://greatsql.cn/docs/8032-25/user-manual/2-about-greatsql/4-3-greatsql-binary-log.html Binglog主要应用于数据恢复和数据复制，但是在Binlog中也含有非常多有价值的信息，比如说：

2024-03-26

840

源码解析丨一次慢SQL排查

time 日志索引源码 sql

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。当long_query_time=1时（表info的id为主键），出现下面的慢日志，可能会让你吃惊 # Time: 2024-01-28T22:52:24.500491+08:00 # User@Host: root[root] @ [127.0.0.1] Id: 8 # Query_time: 7.760787 Lock_time: 7.757456 Rows_sent: 0 Rows_examined: 0 use apple; SET timestamp=; delete from info where id < ;

2024-03-25

630

故障解析丨一次死锁问题的解决

索引 apple null server 事务

事务T1T2操作insert into info values (50,11)insert into info values (60,8)关联的对象表apple.info的唯一索引 uk_name表apple.info的唯一索引 uk_name持有的锁lock mode S waitingheap no 7 11，40（十六进制为8，28）lock_mode X locks rec but not gapheap no 7 11，40（十六进制为8，28）等待的锁lock mode S waitingheap no 7 11，40（十六进制为8，28）lock_mode X locks gap before rec insert intention waitingheap no 7 11，40（十六进制为8，28）

2024-03-25

1070

NOT IN子查询中出现NULL值对结果的影响你注意到了吗

数据效率 null select 连接

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。前言开发人员写的SQL语句中经常会用到in，exists，not in，not exists 这类子查询，通常，含in、exists的子查询称为半连接（semijoin），含not in、 not exists的子查询被称之为反连接，经常会有技术人员来评论in 与exists 效率孰高孰低的问题，我在SQL优化工作中也经常对这类子查询做优化改写，比如半连接改为内连接，反连接改为外连接等，哪个效率高是要根据执行计划做出判断的，本文不是为了讨论效率问题，是要提醒一点：not in子查询的结果集含NULL值时，会导致整个语句结果集返回空，这可能造成与SQL语句书写初衷不符。

2024-03-25

630

点击加载更多

社区活动

RAG七天入门训练营

鹅厂大牛手把手带你上手实战

Python精品学习库

代码在线跑，知识轻松学

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

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

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

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