技术分享 | MySQL中MGR中SECONDARY节点磁盘满,导致mysqld进程被OOM Killed

深入解析LCD DRM驱动框架中的KMS与GEM机制 本文深入解析了Linux内核中DRM(Direct Rendering Manager)驱动框架的核心机制,重点剖析了KMS(内核模式设置)与GEM(图形执行管理器)的工作原理。KMS作为显示系统的总指挥,负责原子化地控制CRTC、Encoder、Plane等硬件资源,确保画面同步更新,避免撕裂;GEM则作为显存大管家,通过DUMB和PRIME机制高效管理图形缓冲区的分配、共享与同步。文章结合RK3568平台实战,阐述了如何利用这些机制优化显示性能,并提供了调试技巧与常见问题解决方案。 阅读详情

欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答

在MGR测试中,人为制造磁盘满问题后,节点被oom killed

问题描述

在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中,有一个环节是人为制造磁盘满的场景,看看MGR是否还能正常响应请求。

在实测过程中,最后发现磁盘满的那个节点,持续时间足够久后,会因为内存消耗过大而最终被OS给OOM Kill。

这个问题我已报告BUG(#104979),下面是该过程的详细记录。

首先,直接利用dd复制空文件填满磁盘。

MySQL 8.0.26 测试过程

disk full报告过程及何时被oom killed

来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容:

# 首次提示disk full的时刻是 09:44:10.052558,这时其实还能写入日志,只是不能写数据和binlog
2021-09-18T09:44:10.052558+08:00 10 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applier.000046' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.
2021-09-18T09:44:10.052558+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.
2021-09-18T09:54:10.109075+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.
2021-09-18T09:54:10.109828+08:00 10 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applier.000046' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.
2021-09-18T09:56:15.020870+08:00 152 [ERROR] [MY-010907] [Server] Error writing file '/data/MySQL/slow.log' (errno: 28 - No space left on device)
# 最后一次提示disk full时是10:04:10.166349,这时候彻底无法写入日志了
2021-09-18T10:04:10.166349+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs.

从disk full时刻开始,大约过了2.5小时,mysqld进程内存消耗持续上升,最终引发oom kill

Sep 18 12:56:28 mgr3 kernel: docker-containe invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=-500
...
Sep 18 12:56:29 mgr3 kernel: Out of memory: Kill process 9539 (mysqld) score 902 or sacrifice child
Sep 18 12:56:29 mgr3 kernel: Killed process 9539 (mysqld), UID 27, total-vm:17020364kB, anon-rss:14644556kB, file-rss:0kB, shmem-rss:0kB

在这期间某个时刻抓到的待认证事务堆积,在被oom kill前实际不止这么多:

+--------------------------------------+----------+
| id                                   | trx_que  |
+--------------------------------------+----------+
| dbe4f563-1622-11ec-8cc8-525400e802e2 | 87863918 |
+--------------------------------------+----------+

关注mysqld进程内存消耗变化

下面是mysqld进程内存消耗变化情况

# 一开始3G
 9539 3144872 /usr/local/mysql-8.0.26-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/data/MySQL/my.cnf
...
# 涨到3.47G
 9539 3641984 /usr/local/mysql-8.0.26-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/data/MySQL/my.cnf
...
# 涨到7G
 9539 7416908 /usr/local/mysql-8.0.26-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/data/MySQL/my.cnf
...
# 不断增长,直至最后被oom killed前,大约飙到14G
 9539 14638256 /usr/local/mysql-8.0.26-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/data/MySQL/my.cnf

OS层oom-killer相关日志:

# mysqld进程内存大约飙到14G
Sep 18 12:56:29 mgr3 kernel: Out of memory: Kill process 9539 (mysqld) score 902 or sacrifice child
Sep 18 12:56:29 mgr3 kernel: Killed process 9539 (mysqld), UID 27, total-vm:17020364kB, anon-rss:14644556kB, file-rss:0kB, shmem-rss:0kB

GreatSQL 8.0.25测试过程

作为对比,我用GreatSQL 8.0.25也做了同样的测试。

# 首次报告disk full
2021-09-18T23:07:49.264992+08:00 89 [ERROR] [MY-000035] [Server] Disk is full writing '/data/GreatSQL/binlog.000085' (OS errno 28 - N
o space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.
2021-09-18T23:07:49.264992+08:00 82 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applie
r.000147' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 se
cs.

# 发出报错,提示因为disk full,无法写入data/binlog
2021-09-18T23:07:49.838301+08:00 84 [ERROR] [MY-011071] [Repl] Plugin group_replication reported: 'io full on data or binlog director
y'
# 本节点自动改为RO
2021-09-18T23:07:49.852475+08:00 84 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set i
nto read only mode after an error was detected.'
2021-09-18T23:07:49.852633+08:00 0 [ERROR] [MY-011486] [Repl] Plugin group_replication reported: 'Message received while the plugin i
s not ready, message discarded.'
# 接下来准备退出集群了
2021-09-18T23:07:49.856907+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Re-using server node 0 host 17
2.16.16.53'
2021-09-18T23:07:49.856937+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Re-using server node 1 host 17
2.16.16.16'
2021-09-18T23:07:49.856950+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] pid 5211 Installed site start={dba4e34 1394386 1} boot_key={dba4e34 1394375 1} event_horizon=10 node 4294967295 chksum_node_list(&site->nodes) 704906340'
2021-09-18T23:07:55.380111+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Installing leave view.'
2021-09-18T23:07:55.380169+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] ::install_view():: No exchanged data'
2021-09-18T23:07:55.380188+08:00 0 [Note] [MY-011071] [Repl] Plugin group_replication reported: 'on_view_changed is called'
# 发生view change,正式退出集群
2021-09-18T23:07:55.380242+08:00 0 [System] [MY-011504] [Repl] Plugin group_replication reported: 'Group membership changed: This member has left the group.'
2021-09-18T23:07:55.382254+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Rejecting this message. The gr
oup communication engine has already stopped.'
...中间几条相同的日志
2021-09-18T23:07:55.382325+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Rejecting this message. The group communication engine has already stopped.'
2021-09-18T23:07:55.382333+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Rejecting this message. The group....日志没写完,磁盘彻底填满了
# 下面是第二天我清理磁盘空间后的新日志
2021-09-19T07:10:52.071942+08:00 82 [ERROR] [MY-013309] [Repl] Plugin group_replication reported: 'Transaction '1:38481943' does not exist on Group Replication consistency manager while receiving remote transaction prepare.'
2021-09-19T07:10:52.071990+08:00 82 [ERROR] [MY-011452] [Repl] Plugin group_replication reported: 'Fatal error during execution on the Applier process of Group Replication. The server will now leave the group.'
2021-09-19T07:10:52.072032+08:00 82 [Warning] [MY-011646] [Repl] Plugin group_replication reported: 'Skipping leave operation: member already left the group.'
2021-09-19T07:10:52.072049+08:00 82 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'

从日志详情中可以看到,当磁盘空间满了之后,GreatSQL会将那个节点主动退出集群,对整个集群的影响非常小。

此外,从集群退出后,也不会再接收认证事务了,所以也没发生内存持续暴涨最终被oom killed的情况,实际观察过程中发现内存反倒还下降了

# 还```在集群中的内存消耗
 5211 2790736 /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.17-x86_64-minimal/bin/mysqld
 ...
 # 退出集群后的内存反倒降低了
 5211 2801696 /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.17-x86_64-minimal/bin/mysqld
 5211 968876 /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.17-x86_64-minimal/bin/mysqld
 ...
 # 此后内存一直保持这个值
  5211 969172 /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.17-x86_64-minimal/bin/mysqld

这样对比来看,GreatSQL的可靠性还真是可以的,官方的MySQL MGR的可靠性还有待进一步加强呀。

Enjoy GreatSQL :)

文章推荐:

GreatSQL MGR FAQ https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA

万答#12,MGR整个集群挂掉后,如何才能自动选主,不用手动干预 https://mp.weixin.qq.com/s/07o1poO44zwQIvaJNKEoPA

『2021数据技术嘉年华·ON LINE』:《MySQL高可用架构演进及实践》 https://mp.weixin.qq.com/s/u7k99y6i7riq7ScYs7ySnA

一条sql语句慢在哪之抓包分析 https://mp.weixin.qq.com/s/AYibbzl860D90rOeyjB6IQ

万答#15,都有哪些情况可能导致MGR服务无法启动 https://mp.weixin.qq.com/s/inSGpd0Q_XIl2Mb-VsvNsA

技术分享 | 为什么MGR一致性模式不推荐AFTER https://mp.weixin.qq.com/s/rNeq479RNsklY1BlfKOsYg

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

Gitee: https://gitee.com/GreatSQL/GreatSQL

GitHub: https://github.com/GreatSQL/GreatSQL

Bilibili: https://space.bilibili.com/1363850082/video

微信&QQ群: 可搜索添加GreatSQL社区助手微信好友,发送验证信息“加群”加入GreatSQL/MGR交流微信群

QQ群:533341697 微信小助手:wanlidbc

本文由博客一文多发平台 OpenWrite 发布!

DAF-Net:动态注意力红外-可见光图像融合 DAF-Net 红外-可见光融合链路:IR/VIS 双分支 (Conv+ResBlock → 64ch) → DynamicAttentionFusion (Cat→Sigmoid→加权) → 重建 (Conv→Sigmoid)。TNO 上 SSIM=0.782 (vs IR), 0.734 (vs VIS), 参数量仅 218K。核心贡献:轻量动态注意力门控, 无监督 SSIM+MSE 损失不需要配准 ground truth。 阅读详情

相关推荐

微信小程序消息推送全攻略:从模板消息到订阅消息的实战避坑指南

本文深入解析微信小程序消息推送机制,对比模板消息、订阅消息与客服消息的核心差异与适用场景。重点提供订阅消息从用户授权设计、前端代码实现到后端稳定发送的完整实战指南,并分享提升消息点击率的文案与运营技巧,帮助开发者构建高效、用户友好的消息推送体系。

b3n4m5q6w7的博客 336

The table ‘xxxx‘ is full

1. 版本 1)操作系统版本 cat /proc/version Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2...

渔夫数据库笔记 3327

基于WEB的报价管理系统的设计与实现

该系统采用B/S模式,后台运用SpringMVC和MyBatis搭建,利用MySQL数据库,来组织存储和管理数据,使用tomcat服务器向外提供服务。使用该系统对外有利于提高企业的综合竞争力,对内有利于提高成本管理和控制的水平,简化了报价流程、提高了工作效率、精简了报价机构,降低了成本。研究和掌握必要的信息采集和数据查询技术,是各个企业,事业单位信息化的一个重要标志。当前大多数企业采取的报价方式仍然是用EXCEL表格和人工的方式,这不仅不利于大量数据的总结,更不利于对销售利润的控制。

m0_60918862的博客 999

MySQL OOM

如果MySQL所在的cgroup设置了较小的内存限制,当MySQL进程占用的内存超过了限制时,cgroup的OOM杀手会终止该进程。调整cgroup的资源限制:如果MySQL所在的cgroup设置了较小的内存限制,可以考虑适当增加cgroup的内存限制,以满足MySQL进程的内存需求。同时,监控MySQL的内存使用情况和性能指标,以便及时调整参数并优化系统的内存管理。当系统的内存资源耗尽并出现OOM情况时,操作系统会使用OOM杀手来选择并终止使用过多内存的进程,以便回收内存并保护系统的稳定性。

喝醉酒的小白 2364

AD9361 LVDS数据接口时序解析与FPGA实现

本文详细解析了AD9361 LVDS数据接口的时序特性与FPGA实现方法,重点探讨了DATA_CLK、Rx_FRAME等关键信号的时序关系及数据拼接技巧。通过Verilog代码示例和调试经验分享,帮助开发者解决跨时钟域处理、IQ数据重组等常见问题,提升射频收发系统的稳定性与性能。

weixin_29186249的博客 128

Python 爬虫实战:爬取 Bing 搜索功能链接(国际搜索引擎数据采集技巧)

在当今数字化信息爆炸的时代,搜索引擎已成为我们获取知识、了解世界的得力助手。Bing,作为全球知名的搜索引擎之一,拥有庞大的数据索引和精准的搜索算法。通过 Python 爬虫技术爬取 Bing 搜索区域的链接信息,不仅能帮助我们快速收集大量有价值的数据,还能为后续的数据分析、内容挖掘等任务提供丰富的素材。

yansideyucsdn的博客 1339

java内存泄漏

所谓的内存泄漏不是说内存坏掉了,内存溜出去了,而是因为线程进行中一直占用了某块内存无法进行GC,这块内存之后永远都无法被使用,导致这块内存像是没有了一样,嗯哼

YangYoung_的博客 1617

61、神经科学中的分岔与双分子反应研究

本文探讨了神经科学中的分岔现象与双分子反应建模。在神经元网络中,通过分析四细胞网络的呼吸节律振荡,揭示了分岔对振荡频率和占空比的影响,并区分了单神经元与网络层面的分岔特性。在神经群体模型中,系统参数变化引发的分岔可导致振荡、混沌等动态行为转变,文中详细介绍了局部分岔、全局分岔和高余维分岔的机制,并以Jansen-Rit模型为例展示了输入水平变化下的分岔过程。在分子层面,重点介绍了MWC模型在描述配体与多位点蛋白质结合中的应用,涵盖其构象状态、平衡常数及统计因子。研究表明,分岔理论和双分子反应建模为理解神经系

yog99的博客 80

mysql 1021 disk full,磁盘爆满导致MySQL无法启动:Disk is full writing './mysql-bin.000031' (Errcode: 2...

210116 18:27:55 [Warning] Disk is full writing './mysql-bin.000031' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)2101...

weixin_31484881的博客 2328

10年上位机开发踩过的20个坑:C#通信/线程/UI适配避坑指南

通信层:所有通信操作异步化、异常全覆盖,加断线重连+心跳检测,多设备隔离资源;线程层:UI更新必做跨线程判断,共享数据加锁,线程池限流,异常不静默;UI层:适配高分屏/DPI,用布局容器替代固定坐标,多屏场景绑定主屏幕。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 904

YOLO11实战优化:长尾分布解决 | 引入Seesaw Loss配合YOLO11分类头,完美应对类别极其不平衡的现实业务场景

摘要: YOLO11在工业缺陷检测等长尾分布场景中面临尾部类别检测失效的问题,根源在于头部类别样本的负样本梯度压制了尾部类别的学习。传统方法如重采样、Focal Loss等效果有限。Seesaw Loss通过动态调整缓解因子和补偿因子,平衡类别间的梯度分布,结合YOLO11的解耦分类头、Anchor-Free设计和C2PSA/C3K2模块,显著提升尾部类别识别能力。文章详细解析了Seesaw Loss的数学原理,并提供了可直接集成到YOLO11的PyTorch实现代码,为长尾分布下的目标检测提供了实用解决方

2601_95807009的博客 252

高级DBA带你处理MySQL集群爆表导致硬盘爆满系统产品宕机实际生产事故处理实战案例全网唯一

高级DBA带你解决mysql集群生产事故的实际案例全网唯一,花钱买课程也遇不到的!

nasen512的博客 1261

全覆盖路径规划开源项目Clean-robot-turtlebot3原理及流程概括总结

本系列文章主要介绍全覆盖路径规划开源项目Clean-robot-turtlebot3的相关内容,包含如下四篇文章,分别介绍了开源项目Clean-robot-turtlebot3流程的概括总结、ROS坐标系常用坐标及其变换、Clean-robot-turtlebot3关键函数解析等内容。

慕羽★的博客 6103

解决mySQL占用内存超大问题

解决mySQL占用内存超大问题

wangchaoqi1985的博客 218

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

mysql oom killer_MySQL Slave 触发 oom-killer解决方法

最近经常有收到MySQL实例类似内存不足的报警信息,登陆到服务器上一看发现MySQL 吃掉了99%的内存,God !有时候没有及时处理,内核就会自己帮我们重启下MySQL,然后我们就可以看到 dmesg 信息有如下记录:Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_ad...

weixin_34970098的博客 457

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

redis 集群

环境信息 centos7 redis5 安装redis wget http://download.redis.io/releases/redis-5.0.3.tar.gz tar -zxvf redis-5.0.3.tar.gz cd redis-5.0.3 make # 安装到 /usr/local/redis 目录中 安装的文件只有一个bin目录 make install PREFIX=/usr/local/redis/ # 创建配置文件和data存放目录 mkdir /usr/local/red

weixin_42494845的博客 373

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

线上问题排查——磁盘满

现象 群里反馈管理后台登录不上了,我一访问,整个界面空白,没有提示,打开 F12,发现控制台提示 js、css 等静态资源报 net::ERR_HTTP2_PROTOCOL_ERROR,客户端可以下载到服务端资源,第一次碰到这个,StackOverflow 走起 net::ERR_HTTP2_PROTOCOL_ERROR 是关于什么的? 可能出现的问题非常多,包括磁盘满、nginx 配置问题、请...

weixin_36842390的博客 228

高级DBA带你解决Mysql主从集群主库产生过多binlog文件引起生产服务器硬盘爆满处理方法实战全网唯一

DBA解决Mysql主从集群主库产生过多binlog日志文件导致硬盘爆满的实战,并详细介绍应急处理方法与思路!

nasen512的博客 2215

MySQL中MGR中SECONDARY节点磁盘满,导致mysqld进程被OOM Killed

本文首发于 GreatSQL社区 微信公众号。问题描述MySQL 8.0.26 测试过程disk full报告过程及何时被oom killed关注mysqld进程内存消耗变化GreatSQ...

老叶茶馆 578

Plugin ‘group_replication‘ is not loaded

MGR8.0.19上生产喽~ mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so'; ERROR 1524 (HY000): Plugin 'group_replication' is not loaded 报错就看error.log 解决方法: chown mysql.mysql my.cnf ##修改权限 chmod 644 my.cnf 就是需要 ...

qq_38461773的博客 592

mysql5.7 查询引起奔溃_MySQL 5.7.24磁盘满了,导致数据库崩溃

2020-05-08T03:25:12.059499+08:00 2863585 [ERROR] Disk is full writing '/data/mysql/mysql3306/logs/mysql-bin.000086' (Errcode: 16044192 - No space left on device). Waiting for someone to free space...2...

weixin_32457141的博客 1630

mysql oom killer_Mysql oom killer 故障浅析

最近新服务上线遇到一个问题:mysql因为内存分配问题被内核干掉。问题处理过程:1.查看系统资源情况。a)系统为多服务共存:mysql,pythonservice ,redis等,内存占用70%,cpu占用小于50%。b)禁用了swap2.问题追踪a)分析syslog及mysql错误日志。Mysql被kill掉的时间为00:00:20,原因为内存不足,由oom killer停止mysql进程。Ma...

weixin_31845811的博客 958

二进制日志占满空间

130808 23:30:23 [Warning] Disk is full writing './mysql-bin.000063' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space) 13

aeoluspu的专栏 1557

磁盘满导致mysql连接丢失_一次由于磁盘空间满导致的MySQL故障

一、故障描述:今天早上起来,发现收到了邮件报警,提示网站500错误。测试服务器上的网站,凡是没使用数据库的页面能正常打开、而使用到数据库的要么500错误,要么一直在加载中。二、追根溯源:1、“show processlist”:看到这种现象,第一个想到的可能是不良SQL语句导致的锁表,才会导致网站页面一直加载中;连接到数据库,发现“use dbname”语句不能用,也就是不能切换数据库;直接运行“...

weixin_42528090的博客 973

mysql disk full_由于日志占满空间导致MySQL无法启动的问题-已解决

昨天采集完数据准备发布的时候,一直提示错误,重启一下服务器,重启nginx没有问题,但是重启MYSQL却启不来了。google了一下,问题源头基本找到。看了一下Mysql的错误日志,问题在这里。131210 1:49:55 [Warning] Disk is full writing './mysql-bin.000016' (Errcode: 28). Waiting for someone ...

weixin_39942213的博客 1792

purge mysql_Mysql binlog 无法删除(purge命令无法删除)

1.版本1)操作系统cat /etc/issueCentOS release 6.6 (Final)Kernel \r on an \mcat /proc/versionLinux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7...

weixin_31125161的博客 360
上一篇: 技术分享 | 简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现
下一篇: MySQL:关于MGR中监控的两个重要指标简析
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值