GreatDB的博客

🌟GreatSQL 8.0.32-26版本全新发布🙌高可用+高性能+高安全+高兼容全面加强！🙌增强多项新特性，打造更优使用体验！戳上方链接一键了解详情~

➥ https://greatsql.cn/docs/8032-25/user-manual/5-enhance/5-1-highperf-parallel-load.html 并行导入TPC-H测试数据。➥ https://greatsql.cn/docs/8032-25/user-manual/10-optimze/3-2-benchmark-tpch.html，完成TPC-H工具编译安装。参考GreatSQL社区提供的TPC-H性能测试脚本，完成测试，并记录各个SQL的耗时。

create connections failed的深度剖析@还故障一个真相

高效解析 binlog

GreatSQL数据库搭载DapuStor Roealsen5 NVMe SSD，平稳高效！

什么是MVCC

GreatSQL vsMySQL性能测试

1. 计算节点是无SSD盘的裸金属服务器，运行MySQL数据库服务程序；2. 存储节点提供NVMe SSD资源池，通过软件聚合方式提供高性能Lun实现对于数据库的数据的存储服务；两部分服务器通过Quantum 平台的InfiniBand网络实现对计算节点和存储节点的无损连接，结合NVMe-oF（NVMe over Fabric）高效的数据存储传输协议，将存储节点的Lun挂载到计算节点，实现结算节点本地高性能的数据存储能力。...

另外，GreatDB的分片在计算节点上，相对业内采用“元数据管理节点”或者“K-VALUES”更新表的元数据分片信息，其优势在于能将数据相对均匀地分散在后端存储节点上，更易发挥分布式数据库多点多实例计算的性能。如网站商品的标签表、类别表。目的是优化分布式的下推和后端存储数据的内部计算，减少跨节点的数据交互和分布式事务开销，提升SQL的查询效率和性能。为了提升分布式表跨节点关联查询的性能，而创建的业务配置表，静态表，或极少更新的表，不建议大表使用全局表，其副本冗余较多，磁盘空间占用较大大，更新性能代价大。..

赛迪顾问发布了《“十四五”关键应用领域之数据库市场研究报告》万里数据，领导者象限，成为最大黑马。

数据中间件如何与GreatSQL数据同步？

快来领取DBA运维大法，保你“断案如神”~

深夜收到客户紧急求助、万里DBA 6小时攻克难关

经过近期的努力，支持仲裁（投票）节点特性的 GreatSQL 8.0.25-16今天正式发布啦，可以用接近两台服务器的成本构建MGR（节省服务器资源），此外还支持快速单主模式以及改进选主策略等特性，该版本里也修复了众多MGR关键bug。用MGR，选GreatSQL，更放心~GreatSQL 8.0.25-16 新版本亮点1.新增特性1.1 新增仲裁节点（投票节点）角色1.2 新增快速单主模式1.3 新增MGR网络开销阈值1.4 自定义选主模式2.稳定性提升3.其他调整4.bug修复5.G

在多写（多节点写入）数据库（例如MySQL MGR的multi-primary mode）与应用之间，往往会加一层代理组件，通过算法调节不同节点负载，分发高并发读写请求。要求代理工具具有请求转发、负载均衡、故障转移的功能。在后端节点故障发生或连接因为客户端异常、网络问题断开时，需要及时将故障节点及时踢出负载均衡队列或者关闭异常连接，做到故障转移。这就是接下来介绍的主要内容，使用golang简单编写一个这样的工具，来深入学习一下负载均衡代理的实现。功能一览负载均衡将应用端的连接请求（负载）按照既定

经过近期几个月的努力，开源产品GreatSQL 5.7.36今天正式发布了，欢迎小伙伴们积极选用、多多交流。新推出的GreatSQL 版本新增了MGR角色列、MGR网络开销阈值等一系列特性，并大幅提升了稳定性、性能，修复了以往的一些bug，产品功能、性能较以往版本进行了优化升级，可以让大家在5.7版本下更放心地使用MGR。GreatSQL 5.7.36新版本亮点►新增特性1.1 新增MGR角色列1.2 采用全新的流控机制1.3 新增MGR网络开销阈值1.4 调整MGR大事务限制.

MGR是MySQL Group Replication的缩写，即MySQL组复制。以往，技术DBA一般是利用MySQL的主从复制或半同步复制来提供高可用解决方案，但存在复制延迟、数据一致性、新节点选择、事务无法及时确认等缺陷，因此，MySQL推出了全新的高可用解决方案 – 组复制（MGR）。深入浅出MGR专栏为帮助技术小伙伴详细了解MGR的功能特性及实操方法，近期，万里数据库旗下的开源技术社区——GreatSQL社区推出了深入浅出MGR的系列干货教程，目前已连载至第10期，后期将持续更新，欢迎技术小伙伴

背景介绍项目选型中，在KVM(16c 16G ssd160G )的 Linux7.6系统上部署了MySQL MGR集群 (GreatSQL 8.0.25)。使用 sysbench 创建了100仓数据，且针对表创建为 partition 表，进行连续12小时的稳定下压测，来评估对应的架构能支撑的业务并发数，以及最高的TPS/QPS是多少。在使用256并发连续进行12小时压测后，发现节点的SSD磁盘空间使用率达到 95% 以上，当时第一时间查看log目录，发现log目录已经达到 100G+，以为是 bi

11月26日下午2点，数据技术嘉年华 • ON LINE第四期如期而至。万里数据库开源生态负责人叶金荣老师受邀发表《MySQ高可用演进及实践》主题演讲，与人大金仓、南大通用、中兴、云和恩墨等业内知名的国产数据库技术专家同台论道，畅谈数据库领域的技术成果与应用实践。图 | 数据技术嘉年华 • ON LINE第四期数次跃升迭代 MySQL高可用发展史悉数呈现叶老师表示，数据库的高可用主要面临两方面挑战：一是如何提升RPO数据一致性，即在做高可用切换的时候，如何尽可能地保证不丢数据或少丢数据；二是如何保障

有时候，我们需要在单机环境下跑多实例。在以前，一般是习惯用mysqld_multi来跑多实例。不过从CentOS 7开始引入systemd作为新的系统管理器后，用它来管理多实例也是很方便的。本文我们以RPM/YUM方式安装后的MySQL为例，介绍如何用systemd管理多实例。以RPM/YUM方式安装完后，会生成systemd服务文件 /usr/lib/systemd/system/mysqld.service，可以看到其中有两行：ExecStartPre=/usr/bin/mysqld_pre_sy

生产上发生误删数据或者误更新数据的事故时，传统恢复方法是利用备份重搭实例，利用binlog来恢复数据，有时候需要找回的数据条数非常少，却要恢复几十甚至上百G的备份，费时费力。那有没有像Oracle一样用闪回的方式来方便地恢复数据呢？答案是有的。MySQL有binlog，binlog以event的形式，记录了MySQL server从启用binlog以来所有的变化。关于binlog不做过多赘述，我们可以利用binlog记录的信息，在不做备份恢复的情况下来迅速找回误操作的数据。MySQL不像Oracle直

内容提纲一、简介二、Update 生命周期2.1 连接器2.2 分析器2.3 优化器2.4 执行器2.4.1 事务执行阶段2.4.2 事务提交阶段2.4.3 假设事务 ROLLBACK三、影响事务提交延迟的几种情况四、Update 更新慢的排查思路五、常见问题一、简介在开始排错Update之前，我们需要知道 Update 在 MySQL 中的生命周期是什么，MySQL 如何执行一个事务的。理解了如何执行，才知道如何去排查故障。二、Update 生命周期Server 层阶段2

DBA们在数据库运维工作中可能会遇到这样一个问题：在一台旧的 centos 7 服务器上面新安装了 mysql 8.0.19，使用下面的初始化命令：mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --lower-case-table-names=1 --datadir=/data/mysql初始化且启动成功后，使用命令mysql -S /data/mysql/mysql.sock用于登录实例，做其他操作，结果遇到

**MGR新手福利来了，一文帮大家快速掌握MGR集群的部署和运维知识点，**新建集群、添加新节点、滚动升级、切主在这全都有，超详细。0内容提纲1、运行环境2、准备my.cnf配置文件3、初始化MySQL实例4、构建MGR集群4.1 构建MGR集群前的准备工作4.2 配置MGR集群PRIMARY节点4.3 查看MGR集群状态4.4 测试数据读写5、进一步，再增加一个新节点6、再进一步，切换主节点6.1 先升级SECONDARY节点6.2 再升级PRIMA

前言innodb_buffer_pool_size可以调大，却不能调小至1GB以内，这是为什么？MySQL 版本：5.7.30测试环境有台 MySQL 服务器反应很慢，检查系统后发现内存使用量已超过90%，并且有大量的SWAP占用：运行top按内存占用排序，查看系统资源使用情况可以看到内存占用最多的是java进程和4个mysqld进程。由于短期内无法加内存，java内存大小应用不让调整，那就只能想办法压缩mysqld使用的内存大小了。这台服务器部署了4个 MySQL 实例，其中两个是轻

0.背景介绍在某系统中为了保证历史数据的压缩性，采用tokudb引擎存储数据。slave节点所在机器数据盘总大小33TB，故障时磁盘剩余空间1.1TB。[root@redhat76-greatdb greatdb]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 33T 32T 1.1T 97% /devtmpfs 63G 0 63G 0% /devtmpfs

0. 导读相同的账号、密码，手动客户端连接可以成功，通过MySQL Connectors却失败了，为什么？1. 现象描述通过MySQL C API编写的一个程序，在进行用户登录操作的时候，程序报错，登录失败。但是如果通过mysql客户端，手动登录成功后，再启动客户端程序，不再报错，程序运行成功。2. 抓包分析问题学会抓包，就超越了90%的程序员。 sudo tcpdump -i any tcp and port xxx -s 1500 -wfilename -vC程序登录失败时的包

客户发给我一个SQL，让我看看，为什么执行几分钟没有执行完。我第一眼看到SQL的时候，也觉得很简单，优化过程比较简单，但是带来的分析过程与经验还是值得分享的。SQL语句如下：update ap_receive_benefits_log set orderstate= i_orderstate where requestid = i_orderid;但是这个SQL执行时被严重阻塞了该SQL的执行计划疑问1发现执行计划key走的主键，但是细看行数，会发现是全表扫描了数据。如果没有可

背景在一台旧的 centos 7 服务器上面新安装了 mysql 8.0.19，使用下面的初始化命令mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --lower-case-table-names=1 --datadir=/data/mysql初始化且启动成功后，使用命令mysql -S /data/mysql/mysql.sock 用于登录实例 做其他操作，遇到故障。定位过程：在只使用 socket 无

引言批量更新数据，不同于这种 update a=a+1 where pk > 500，而是需要对每一行进行单独更新 update a=1 where pk=1;update a=12 where pk=7;… 这样连续多行update语句的场景，是少见的。可以说是偶然也是一种必然，在GreatDB 5.0的开发过程中，我们需要对多语句批量update的场景进行优化。两种多行更新操作的耗时对比在我们对表做多行更新的时候通常会遇到以下两种情况1.单语句批量更新（update a=a+1 wher

0. 前言是什么原因不敢上MySQL MGR？1. 什么是MySQL MGR当我在群里说起MySQL MGR时，的确还有人不知道这是啥东东。有群友打趣，说这是：美国人卖狗肉蒙古人我只能说，你们真的都是天才。图片言归正传。MySQL MGR是MySQL组复制（Group Replication）的简称。MGR是一种基于shared-nothing的，更方便实现数据一致性及高可用集群方案，此外它还支持故障自动检测及多节点并行写等特性。它由一组MySQL实例构成，每个实例都有一份完整的

近日，3306π社区新一代数据库技术论坛将于5月22日在广州再度启航。因此，3306π特邀万里数据库CTO娄帅，就万里数据库团队在MGR方面的技术研究和应用实践等技术问题进行了专题访谈，并向广大技术开发者提供了GreatSQL产品试用，希望以GreatDB团队的技术实践经验给广大技术开发者提供一些经验借鉴。访谈大纲 ：1、娄老师在MGR方面颇有造诣了，能否给大家推荐一条学习之路，更快更稳地上手MGR呢？2、经常有朋友问“MGR是否可以作为跨中心多活方案”，娄老师您怎么看？3、这次万里数据库提供了最新

在技术社区中，有DBA小伙伴反馈碰到这样一个难题：几乎同样的Python代码，能正常删表，但却无法更新数据，这到底是为啥呢？具体情形如下：运行下面这段Python代码，总是无法更新数据：import pymysqlconn=pymysql.connect(host = '127.0.0.1', user = 'yewen', passwd='YeWen.3306',port= 3306, db='test', charset='utf8mb4')cur = conn.cursor()sql =

在MySQL数据库后期运维中，DBA们有时会遇到这样一个现象：在排查问题时发现MySQL主备做了切换，而查看MySQL服务是正常的，DBA也没有做切换操作，服务器也没有维护操作，万幸的是业务还没有受到大的波及。这到底是为啥呢？今天，小编就带大家从遇到的这个问题出发，层层排查，找出最终的根源所在，并给出解决办法。假设原主服务器地址为：172.16.87.72，原备主服务器地址为：172.16.87.123。01 排查思路1、通过监控查看MySQL的各个指标2、查看双主（keepalived）服务切换

前言GreatSQL运行更平稳，不会有大的抖动。MySQL官方版本的MGR更适合在中小规模业务环境下运行。1. GreatSQL的优势GreatSQL的优势在于提升了MGR的性能及可靠性，及修复了众多bug。主要有以下几点：提升大事务并发性能及稳定性 优化MGR队列garbage collect机制、改进流控算法，以及减少每次发送数据量，避免性能抖动解决了AFTER模式下，存在节点加入集群时容易出错的问题 在AFTER模式下，强一致性采用多数派原则，以适应网络分区的场景当MGR节点崩溃时，能