GreatSQL 异步复制及搭建 一、简介 复制就是将一个数据库数据复制到一个或多个数据库上，复制的过程是异步的，其工作原理是通过binlog（二进制日志）记录事务变更然后传送到从库并重放事务，保持数据一致 二、复制过程 1-1 复制过程图 2.1 binlog日志 GreatSQL 复制是基于 binlog 日志来实现复制的 2.1.1 二进制日志输出格式比较 二进制日志格式 记录内容
Percona Toolkit 神器全攻略（性能类） Percona Toolkit 神器全攻略系列共八篇，前文回顾： 前文回顾 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略（配置类） Percona Toolkit 神器全攻略（监控类） Percona Toolkit
Percona Toolkit 神器全攻略（复制类） Percona Toolkit 神器全攻略系列共八篇，前文回顾： 前文回顾 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略（配置类） Percona Toolkit 神器全攻略（监控类） Percona Toolkit
GreatSQL执行Update失败案例分析 一 问题概述 业务反馈在应用核心库的用户基本信息表执行部分update命令失败，报错如下： update xxx.xxx_staffbasicinfo set staffidstatus='04’ where staffid in (select * from duyuanyu.tmp_d_xiaoyuan ) > 1265 Data t
Percona Toolkit 神器全攻略（开发类） Percona Toolkit 神器全攻略系列共八篇，前文回顾： 前文回顾 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略（配置类） Percona Toolkit 神器全攻略（监控类） Percona Toolkit
独家揭秘丨GreatSQL 的MDL锁策略升级对执行的影响 一、MDL锁策略介绍 GreatSQL 的MDL锁有个策略方法类MDL_lock_strategy，它根据对象的类型分为了scope类型和object类型，前者主要用于GLOBAL, COMMIT, TABLESPACE, BACKUP_LOCK and SCHEMA ,RESOURCE_GROUPS,FOREIGN_KEY,CHECK_
GreatSQL 并行Load Data加快数据导入 数据库信息 数据库版本:GreatSQL 8.0.32-25 Clickhouse表需要导入到 GreatSQL 中，表数据量庞大所以选用导出CSV的方式。 测试数据复现操作 load data MySQL load data 语句能快速将一个文本文件的内容导入到对应的数据库表中（一般文本的一行对应表的一条记录）。 数据库应用程序开发中，涉及大
单条记录大小增长倍数和ibd文件大小的增长倍数不成正比 环境信息 数据库版本: GreatSQL 8.0.25 字符集：utf8mb4 innodb_default_row_format: dynamic innodb_page_size: 16384 问题描述 表数据为新insert数据，无delete、无update GreatSQL 一个数据量为1万的A表，有100个varchar字段，每个
Percona Toolkit 神器全攻略系列之系统类已发布，本次的章节，我们将聚焦在六款关于系统相关的工具上
GreatSQL 的刷新锁 前言 因为运维小伙伴执行dump备份命令，导致数据库卡住，很多会话都在waiting for table flush，基于这一故障，我对GreatSQL的刷新锁进行了研究。感兴趣的小伙伴请随我一探究竟吧。 刷新锁的症状 刷新锁问题的主要症状是数据库会进入嘎然而止的状态，所有需要使用部分或全部表的新查询都停下来等待刷新锁。要寻找的如下： 1.新查询的查询状态为Wait
GreatSQL 构建高效 HTAP 服务架构指南（MGR） 引言 全文约定：$为命令提示符、greatsql>为 GreatSQL 数据库提示符。在后续阅读中，依据此约定进行理解与操作 上一篇已经介绍了如何在主从复制架构中，搭建一个专属 HTAP 服务。本篇将在 MGR 架构中部署一个专属 HTAP 服务。 整体方案架构图 本服务架构采用 GreatSQL MGR 架构，在 MGR
一、问题发现 在一次数据迁移中，用到了INSERT INTO t1 SELECT * FROM t2这样的 SQL 用来搬迁大表，为了提高插入效率关闭了Binlog，考虑用多线程来插入提高速度。表的类型信息和插入效率如下所示。 测试环境： Linux node-76-11 4.19.90-17.ky10.aarch64，128核CPU，512G内存。 GreatSQL参数配置如下（为降低 I/
GreatSQL 构建高效 HTAP 服务架构指南（主从复制） 引言 全文约定：$为命令提示符、greatsql>为 GreatSQL 数据库提示符。在后续阅读中，依据此约定进行理解与操作 Rapid 引擎 从 GreatSQL 8.0.32-25 版本开始，新增Rapid存储引擎，该引擎使得 GreatSQL 能满足联机分析（OLAP）查询请求。 GreatSQL Rapid引擎性能表
GreatSQL中 Insert 慢是什么情况？ 背景概述 客户反映，业务上某张表的 Insert 操作速度很慢，单条 Insert 语句的最大执行时间超过了 5 秒。在收到客户问题后，我们仔细检查了数据库状态以及主机的负载情况，发现目前一切正常，并没有发现数据库故障或主机负载过高导致 insert 操作变慢的问题。 因此，我们分析了慢日志，希望从中找出问题。经过分析，发现这条插入语句的query
Percona Toolkit 神器全攻略（监控类） Percona Toolkit 神器全攻略系列共八篇，前文回顾： 前文回顾 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略（配置类） 全文约定：$为命令提示符、greatsql>为GreatSQL数据库提示符。在后
一、背景概述 在将数据库从MySQL 5.7迁移到GreatSQL8.0.32时，由于数据量较小且关注安全性，决定使用mysqldump执行逻辑备份，并将数据导入GreatSQL。但在备份时采用了备份全库(--all-databases)的方式，在导入GreatSQL后，修改用户密码时出现错误。这是因为mysqldump备份时包括了mysql系统库，而MySQL 5.7中的mysql系统库采用了M
Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略系列共八篇，前文回顾： <center> 前文回顾 Percona Toolkit 神器全攻略 <center> 全文约定：$为命令提示符、greatsql>为GreatSQL数据库提示符。在后续阅读中，依据此约定进行理解与操作 实用类 在Perc
为何内存中slow_query_log_file变量与配置文件不一致？一探究竟！
官答|slow_query_log_file实例内存中变量与配置文件设置的不一致 官答栏目针对GreatSQL数据库中的问题，选取官方论坛和讨论群中的典型提问进行深入解答。内容涵盖数据库安装部署、配置优化、故障排查、性能测试等方面。 在文章中，我们不仅提供解决方案，还会结合实例深入剖析问题的成因，提升读者对GreatSQL数据库的理解能力。 如果你在管理、使用GreatSQL数据库时遇到棘手的技术
在Percona Toolkit 神器全攻略系列文章中，将全面介绍PT的各个工具及其应用场景。无论是初学者还是经验丰富的数据库专家，都能从中找到对自己有用的信息和技巧:)
Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略系列共八篇分为 文章名 文章名 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略（实用类） Percona Toolkit 神器全攻略（配置类） Percona Toolkit 神器全攻略（监控类） Percona Toolkit 神器全攻略（系统类）
一、数据库信息： 数据库版本：5.7.21-log 某银行测试数据库，APP业务库内有一个含有大量（几百个）分区表的大表test_app。DROP该分区表的大表后导致无法重建该分区表。 二、问题描述： 客户使用“drop table test_app;”时，显示表删除成功。当重新执行该表的建表语句时，报错“Table 'app.test_app /* Partition p0 */' alre
GreatSQL的sp中添加新的sp_instr引入的bug解析 一、问题发现 在一次开发中用到的sp需要添加新的sp_instr以满足需求，但是添加了数个sp_instr以后发现执行新的sp会发生core。 注：本次使用的GreatSQL 8.0.32-25 1、sp_head.cc的init_sp_psi_keys()代码里面添加10个新的sp_instr： void init_sp_ps
1. 问题背景 2.27号凌晨生产环境MySQL备库在执行备份期间出现因FLUSH TABLES WITH READ LOCK未释放导致备库复制延时拉大，慢日志内看持锁接近25分钟未释放。 版本： MySQL 5.7.21 PXB 2.4.18 慢查询日志： 备份脚本中的备份命令： mysql_kill.sh的主要逻辑内容： 备份参数： 2. 问题复现及分析 2.1 问题分析 14
1.背景概述 客户业务发生死锁的报错，根据业务程序日志及业务流程，发现造成死锁的原因是：事务1 delete + insert ，事务2 delete + insert 2个事务交替执行导致的死锁；由于GAP锁阻塞了插入意向锁，并且当delete的数据存在时死锁不会发生，当delete的数据不存在时，会发生死锁。 2.问题复现 本次测试基于 GreatSQL-8.0.32-24，隔离级别为 RR
此篇介绍的是半连接(semijoin)优化的技巧
何为半连接？ 半连接是在GreatSQL内部采用的一种执行子查询的方式，semi join不是语法关键字，不能像使用inner join、left join、right join这种语法关键字一样提供给用户来编写SQL语句。 两个表t1表和t2表进行半连接的含义是：对于t1表的某条记录来说，我们只关心在t2表中是否存在与之匹配的记录，而不关心有多少条记录与之匹配，最终的结果集中只保留t1表的记录。
主从延迟调优思路 1、什么是主从延迟？ 本质是从库的回放跟不上主库，回放阶段的延迟 2、主从延迟常见的原因有哪些？ 1、大事务，从库回放时间较长，导致主从延迟 2、主库写入过于频繁，从库回放跟不上 3、参数配置不合理 4、主从硬件差异 5、网络延迟 6、表没有主键或者索引大量频繁的更新 7、一些读写分离的架构，从库的压力比较大 3、解决主从延迟有哪些方法 1、对于大事务，拆分成小事务 2、开启并
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
