腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

MySQL修行 | 老叶茶馆

专栏作者

250

文章

210284

阅读量

45

订阅数

MySQL复制从库延迟优化思路

事务优化 mysql 变量配置

2、主从延迟常见的原因有哪些？ 1、大事务，从库回放时间较长，导致主从延迟 2、主库写入过于频繁，从库回放跟不上 3、参数配置不合理 4、主从硬件差异 5、网络延迟 6、表没有主键或者索引大量频繁的更新 7、一些读写分离的架构，从库的压力比较大 3、解决主从延迟有哪些方法 1、对于大事务，拆分成小事务 2、开启并行复制 3、升级从库硬件 4、尽量都有主键 4、什么是并行复制，参数有哪些？先回顾MySQL并行复制的路程 a. MySQL5.6 是基于数据库级别的并行复制 slave-parallel-type=DATABASE(不同库的事务，没有锁冲突)

2024-05-09

910

MySQL复制从库延迟原因深入分析

线程 mysql 事务数据算法

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。背景介绍近来一套业务系统，从库一直处于延迟状态，无法追上主库，导致业务风险较大。从资源上看，从库的CPU、IO、网络使用率较低，不存在服务器压力过高导致回放慢的情况；从库开启了并行回放；在从库上执行 SHOW PROCESSLIST 看到没有回放线程阻塞，回放一直在持续；解析relay log日志文件，发现其中并没大事务回放。过程分析现象确认收到运维同事的反馈，有一套从库延迟的非常厉害，提供了SHOW SLAVE STATUS延迟的截图信息

2024-05-08

600

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

max 解决方案开发 bug cursor

一、问题发现在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少，以用来做后续开发。于是做了以下的试验，但是发现第一个level=2那层的m_max_cursor_index的值有点问题。注：本次使用的GreatSQL 8.0.32-25 SQL语句示例： greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10)); 以下注释里面是该层sp_pcontext的参数值。 DELIMITER $$ CREATE PROCEDURE processnames() -- level=0，m_max_cursor_index=1+8+1 BEGIN DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1，m_cursor_offset=0，m_max_cursor_index=1+8+1 begin DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1+8 ☆问题点 begin DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=1 DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=2 DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=3 DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=4 end; end; begin DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1 end; END $$ DELIMITER ; 首先查看上面的sp的code，可以发现nameCursor6和nameCursor1属于同一层，因此他们的offset值一样。 greatsql> show procedure code processnames; +-----+---------------------------------------+ | Pos | Instruction | +-----+---------------------------------------+ | 0 | cpush nameCursor0@0: SELECT * FROM t1 | | 1 | cpush nameCursor1@1: SELECT * FROM t1 | | 2 | cpush nameCursor2@2: SELECT * FROM t1 | | 3 | cpush nameCursor3@3: SELECT * FROM t1 | | 4 | cpush nameCursor4@4: SELECT * FROM t1 | | 5 | cpush nameCursor5@5: SELECT * FROM t1 | | 6 | cpop 4 | | 7 | cpop 1 | | 8 | cpush nameCursor6@1: SELECT * FROM t1 | | 9 | cpop 1 | | 10 | cpop 1 | +-----+---------------------------------------+ 11 rows in set (6.02 sec) 然后通过debug查看每层 sp_pcontext 的参数值（相关参数值已经在上面标识出），发现第一个level=2的sp_pcontext的m_max_cursor_index值多了很多，预期值应

2024-04-28

810

源码解析丨一次慢SQL排查之旅

time 日志索引源码 sql

void THD::update_slow_query_status() { if (my_micro_time() > utime_after_lock + variables.long_query_time) server_status | = SERVER_QUERY_WAS_SLOW; } // my_micro_time() 获取当前系统时间点，单位为微妙 // utime_after_lock 为MDL LOCK和row lock等待时间后的时间点，单位为微妙 // variables.long_query_time 慢日志阈值long_query_time * 1000000 ，单位为微妙 // 等价于：my_micro_time() - utime_after_lock > variables.long_query_time // 不包含锁等待时间

2024-04-28

650

面试题：INSERT...t...SELECT s会对s表加锁吗

select 事务数据 insert lock

insert into t2 select * from t1; 这条语句会对查询表 t1 加锁吗？不要轻易下结论。对GreatSQL的锁进行研究之前，首先要确认一下事务的隔离级别，不同的事务隔离级别，锁的表现是不一样的。

2024-04-28

770

工具分享丨分析GreatSQL Binglog神器

工具排序日志事件事务

事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息，我们能够计算事务的大小，进而评估其是否属于大型事务，以及是否可能引起主从同步的延迟问题，及时发现大事务,可避免复制故障。简介本文分享的神器的名字就叫做binlog_summary，出自陈臣老师的手笔，也是开源的Python脚本文件，开源地址：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py 下载运行此工具需要有Python环境，若没有python环境请自行下载下载binlog_summary.py脚本，并授权 $ wget https://raw.githubusercontent.com/slowtech/dba-toolkit/master/mysql/binlog_summary.py $ chmod 755 binlog_summary.py 先用./binlog_summary.py -h查看下帮助 $ ./binlog_summary.py -h usage: binlog_summary.py [-h] [-f BINLOG_TEXT_FILE] [--new] [-c {tps,opr,transaction}] [--start START_DATETIME] [--stop STOP_DATETIME] [--sort SORT_CONDITION] [-e] [--limit LIMIT] options: -h, --help show this help message and exit -f BINLOG_TEXT_FILE, --file BINLOG_TEXT_FILE Binlog text file, not the Raw binary file --new Make a fresh start -c {tps,opr,transaction}, --command {tps,opr,transaction} Command type: [tps, opr, transaction],tps: transaction per second, opr: dml per table, transaction: show transaction info --start START_DATETIME Start datetime, for example: 2004-12-25 11:25:56 --stop STOP_DATETIME Stop datetime, for example: 2004-12-25 11:25:56 --sort SORT_CONDITION Sort condition: time or size, you can use it when command type is transaction -e, --extend Show transaction info in detail,you can use it when command type is transaction --limit LIMIT Limit the number of rows to display 其中参数介绍:

2024-04-28

890

MyCat分库分表实时同步到GreatSQL

索引同步 sql mycat 数据

MyCat作为经典的分库分表中间件，在长时间内被广泛认为是管理超大MySQL数据库集合的有效解决方案。近来接到客户需求，需要将MyCat集群迁移到GreatSQL中，并且在一段时间内需要实时从MyCat中同步数据到GreatSQL中，全量同步数据比较容易操作，增量同步有如下两个棘手的问题：

2024-04-15

920

被误写入Slave的数据如何恢复到主库

二进制日志数据数据同步同步

在GreatSQL主从复制环境中，有时候可能会出现一些误操作，将本应该写入到主库的数据写入到了从库，导致主从数据不一致，影响数据同步。是否可以将写入从库的数据同步写入主库呢？

2024-04-15

720

MySQL 8.0.26版本升级32版本查询数据为空的跟踪

mysql select set 客户端数据

某业务系统将MySQL 8.0.26升级为 GreatSQL 8.0.32-24 后，某些特定的SQL语句不能查询到数据。经测试 MySQL 8.0.32也存在相同的问题

2024-04-15

710

SQL优化案例解析：MINUS改写为标量子查询后提升5倍，但还可以再快近百倍

数据优化 sql rows 存储过程

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。写在前面(By老叶)从GreatSQL 8.0.32-25版本开始支持Rapid引擎，该引擎使得GreatSQL能满足联机分析（OLAP）查询请求。老叶尝试利用Rapid引擎优化本案例，结果是相当可喜的，对比如下： -SQL执行耗时(秒)Rows_examinedRead_keyRead_nextRead_rnd_nextTmp_tablesTmp_disk_tablesTmp_table_sizesInnoDB_pages_distinct原始SQL9.943230200036368909070210877403112372448181标量子查询改写优化后2.294906728836617308100036382011284368182走Rapid引擎0.11763300001090000 上述测试结果表明：

2024-04-03

940

关于GreatSQL字符集的总结

系统变量编码服务器客户端

最近的SQL优化工作中经常遇到因字符集或校验规则不一致导致索引使用不了的问题，修改表的字符集或校验规则相当于把表重构，表中数据量大时，处理起来费时费力，希望应用开发者在设计之初时注意到此问题，让后期接手运维的小伙伴少一些负担。

2024-04-02

820

LOAD DATA中包含NULL导致主从报错结局

数据字符串 data load null

目前需要搭建一个从库，由于单表数据量较大，时间比较有限，考虑到导入导出的时间，并且GreatSQL支持并行load data的功能，能够加速数据的导入，因此决定使用 select into outfile 和 load data 的方式进行数据的迁移；

2024-04-02

1050

GreatSQL登陆Arch Linux之旅

数据库 linux 内核软件系统

Arch Linux是一个轻量、灵活、基于x86-64架构的Linux发行版，遵循K.I.S.S.原则。注重代码正确、优雅和极简主义，期待用户能够愿意去理解系统的操作。

2024-04-02

690

GreatSQL Shell如何接管手动搭建（含仲裁节点）MGR集群

shell 集群进程权限数据

连接 Primary 节点，查看下原来的账户权限情况，对MGR专属账户增加相应授权

2024-04-02

840

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

status table 统计 rows show

测试环境中，有一个表执行 SHOW TABLE STATUS 时看到的 rows 结果总是和真实数量相差了将近40%：

2024-03-12

1000

GreatSQL TPC-H 性能测试报告正式发布！

性能测试测试脚本数据数据库

完整性能测试报告：https://greatsql.cn/docs/8032-25/user-manual/10-optimze/3-3-benchmark-greatsql-tpch-report.html

2024-03-02

680

故障解析丨Clone节点导致主从故障

架构数据 clone event 定时任务

在一次主从复制架构中，由于主节点binlog损坏，导致从节点无法正常同步数据，只能重做从节点；因此使用MySQL 8.0.17开始提供的clone技术进行恢复，恢复后的2天都发生了主从报错数据冲突。

2024-03-02

970

编译GreatSQL with RocksDB引擎

存储编译服务器高性能事务

RocksDB 是基于Facebook 开源的一种支持事务的、高度可压缩、高性能的MyRocks存储引擎，特别适用于高度压缩和大容量的数据。以下是一些关键特点：

2024-02-22

1340

图文结合丨Prometheus+Grafana+GreatSQL性能监控系统搭建指南(下)

系统性能监控 grafana prometheus 配置

往期回顾：图文结合丨Prometheus+Grafana+GreatSQL性能监控系统搭建指南(上)

2024-02-22

1250

图文结合丨Prometheus+Grafana+GreatSQL性能监控系统搭建指南(上)

prometheus 监控系统性能监控 grafana

官网下载最新二进制安装包➥ https://prometheus.io/download/

2024-02-01

2050

点击加载更多

社区活动

RAG七天入门训练营

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

Python精品学习库

代码在线跑，知识轻松学

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

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

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

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