优化GreatSQL日志文件空间占用
优化GreatSQL日志文件空间占用
GreatSQL对于日志文件磁盘空间占用,做了一些优化,对于binlog、relay log、slow log和audit log的总空间占用进行了限制,使DBA免除了大量日志生成导致磁盘满的顾虑,极大的方便了数据库磁盘空间管理。
1.binlog二进制日志
- binlog_space_limit
- GreatSQL增加了静态参数
binlog_space_limit
,限制数据库binlog的最大磁盘占用。当所有binlog文件的空间占用合计,超过此设置时,GreatSQL自动清理最旧的binlog文件。
- GreatSQL增加了静态参数
参数行为表现测试:
# 查询参数配置值 greatsql> SHOW GLOBAL VARIABLES LIKE 'binlog_space_limit'; +--------------------+------------+ | Variable_name | Value | +--------------------+------------+ | binlog_space_limit | 1073741824 | +--------------------+------------+ 1 row in set (0.00 sec) # 进行业务处理,检查binlog大小 greatsql> SHOW BINARY LOGS; +-----------------+-----------+-----------+ | Log_name | File_size | Encrypted | +-----------------+-----------+-----------+ | mybinlog.000009 | 433980378 | No | | mybinlog.000010 | 7590652 | No | | mybinlog.000011 | 208398410 | No | | mybinlog.000012 | 414221182 | No | +-----------------+-----------+-----------+ 4 rows in set (0.00 sec) # 达到binlog_space_limit的1G限制,清理了最旧的binlog文件 greatsql> SHOW BINARY LOGS; +-----------------+-----------+-----------+ | Log_name | File_size | Encrypted | +-----------------+-----------+-----------+ | mybinlog.000010 | 7590652 | No | | mybinlog.000011 | 208398410 | No | | mybinlog.000012 | 455964041 | No | +-----------------+-----------+-----------+ 3 rows in set (0.00 sec)
2.relay log中继日志
- relay_log_space_limit
-
静态参数,此选项为复制副本上所有中继日志的总大小(以字节为单位)设置了上限。这对于磁盘空间有限的副本服务器主机非常有用。值为0表示"无限制"。当达到限制时,I/O(接收器)线程停止从源服务器读取二进制日志事件,直到SQL线程赶上并删除了一些不再使用的中继日志。
-
请注意,此限制不是绝对的:在某些情况下,SQL线程需要更多的事件才能删除中继日志。在这种情况下,会超过此限制,直到SQL线程可以删除一些中继日志,因为不这样做会导致死锁。不应将
--relay-log-space-limit
设置为小于--max-relay-log-size
值的2倍。在这种情况下,IO线程可能会等待空闲空间,因为超过了--relay-log-space-limit
限制,但SQL线程没有中继日志可以清除,无法满足IO线程的需求。这会迫使IO线程暂时忽略--relay-log-space-limit
限制。
-
参数行为表现测试:
修改配置后,重启 mysqld,将slave改为延时8小时应用。
greatsql> SHOW GLOBAL VARIABLES LIKE 'relay_log_space_limit'; +-----------------------+------------+ | Variable_name | Value | +-----------------------+------------+ | relay_log_space_limit | 3221225472 | +-----------------------+------------+ 1 row in set (0.01 sec) greatsql> STOP SLAVE SQL_THREAD;CHANGE MASTER TO MASTER_DELAY=28800;START SLAVE SQL_THREAD;
在主节点,业务加压,生成relay log,当relay log的文件总和达到3G时,relay log不在增加。
$ du -sm /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/*relay* 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000018 596 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000019 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000020 1025 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000021 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000022 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000023 1028 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000024 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000025 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000026 426 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000027 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.index
检查slave status,Slave的IO和SQL线程都是Yes,当IO线程已停止接收新的事务。
greatsql> pager grep -E '_Log_|Gtid|Running' PAGER set to 'grep -E '_Log_|Gtid|Running'' greatsql> SHOW SLAVE STATUS\G Master_Log_File: greatsql-bin.000006 Read_Master_Log_Pos: 445825094 Relay_Log_File: greatsql-relay.000019 Relay_Log_Pos: 410 Relay_Master_Log_File: greatsql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 459045495 Relay_Log_Space: 3221226704 Until_Log_File: Until_Log_Pos: 0 Slave_SQL_Running_State: Waiting until SOURCE_DELAY seconds after source executed event Retrieved_Gtid_Set: d02f35e9-afdc-11ef-a49b-00163e0ea4a5:138815-387659 Executed_Gtid_Set: d02f35e9-afdc-11ef-a49b-00163e0ea4a5:1-138814 1 row in set, 1 warning (0.00 sec) greatsql> SHOW SLAVE STATUS\G Master_Log_File: greatsql-bin.000006 Read_Master_Log_Pos: 445825094 Relay_Log_File: greatsql-relay.000019 Relay_Log_Pos: 410 Relay_Master_Log_File: greatsql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 459045495 Relay_Log_Space: 3221226704 Until_Log_File: Until_Log_Pos: 0 Slave_SQL_Running_State: Waiting until SOURCE_DELAY seconds after source executed event Retrieved_Gtid_Set: d02f35e9-afdc-11ef-a49b-00163e0ea4a5:138815-387659 Executed_Gtid_Set: d02f35e9-afdc-11ef-a49b-00163e0ea4a5:1-138814 1 row in set, 1 warning (0.00 sec)
将slave改为延时10分钟应用,sql线程在应用完greatsql-relay.000019的事务后,io线程开始接收新的事务到greatsql-relay.000027,sql线程在应用完greatsql-relay.000021的事务之前,IO线程再次暂停。
greatsql> STOP SLAVE SQL_THREAD;CHANGE MASTER TO MASTER_DELAY=600;START SLAVE SQL_THREAD;
relay log的始终合计控制在3G左右。
$ du -sm /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/*relay* 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000020 1025 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000021 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000022 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000023 1028 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000024 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000025 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000026 1450 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000027 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.index ...... $ du -sm /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/*relay* 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000032 1025 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000033 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000034 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000035 1025 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000036 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000037 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000038 1024 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.000039 1 /data/greatsqldata/16315fff-72c5-4ea6-b26e-3604869063a6/dbdata/greatsql-relay.index
slow log 慢日志
GreatSQL增加slow log的如下控制参数:
- max_slowlog_size
- 数据库每个slow log文件的最大空间占用。
- max_slowlog_files
- 数据库保留的slow log的文件个数,慢查询日志总的磁盘空间占用是max_slowlog_size*max_slowlog_files。
参数行为表现测试:
#参数默认值为0,表示不限制 greatsql> SHOW GLOBAL VARIABLES LIKE 'max_slow%'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | max_slowlog_files | 0 | | max_slowlog_size | 0 | +-------------------+-------+ 2 rows in set (0.01 sec) #修改参数值 greatsql> SET GLOBAL max_slowlog_files=2; Query OK, 0 rows affected (0.00 sec) greatsql> SET GLOBAL max_slowlog_size=1024*1024; Query OK, 0 rows affected (0.01 sec) greatsql> SHOW VARIABLES LIKE 'max_slow%'; +-------------------+---------+ | Variable_name | Value | +-------------------+---------+ | max_slowlog_files | 2 | | max_slowlog_size | 1048576 | +-------------------+---------+ 2 rows in set (0.01 sec)
slow.log当达max_slowlog_size 设置的大小时,会发生轮转生成一个新的文件,当文件数达到max_slowlog_files设置的数量时,删除最旧的文件。
$ ll slow* -rw-r----- 1 GreatSQL GreatSQL 1048621 Dec 17 10:52 slow.log.000010 -rw-r----- 1 GreatSQL GreatSQL 1043247 Dec 17 10:53 slow.log.000011 #--继续生成slow.log,删除了slow.log.000010 $ ll slow* -rw-r----- 1 GreatSQL GreatSQL 1048692 Dec 17 10:53 slow.log.000011 -rw-r----- 1 GreatSQL GreatSQL 46119 Dec 17 10:53 slow.log.000012
audit log审计日志
GreatSQL 的 audit 插件参数audit_log_rotate_on_size
,audit_log_rotations
用于控制审计日志。
- audit_log_rotate_on_size
- 审计日志文件大小超过此设置时,进行轮转,存储为新的文件。
- audit_log_rotations
- 除audit.log外,保留的audit.log轮转文件的个数。
参数行为表现测试:
greatsql> INSTALL PLUGIN audit_log SONAME 'audit_log.so'; Query OK, 0 rows affected (0.12 sec) #默认值为0,不轮转,不限制文件大小 greatsql> SHOW GLOBAL VARIABLES LIKE 'audit_log_rotat%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | audit_log_rotate_on_size | 0 | | audit_log_rotations | 0 | +--------------------------+-------+ 2 rows in set (0.01 sec) #设置参数值 greatsql> SET GLOBAL audit_log_rotate_on_size=1048576; Query OK, 0 rows affected (0.00 sec) greatsql> SET GLOBAL audit_log_rotations=4; Query OK, 0 rows affected (0.00 sec) greatsql> SHOW VARIABLES LIKE 'audit_log_rota%'; +--------------------------+---------+ | Variable_name | Value | +--------------------------+---------+ | audit_log_rotate_on_size | 1048576 | | audit_log_rotations | 4 | +--------------------------+---------+ 2 rows in set (0.01 sec)
检查audi.log文件的变化:
$ ll audit* -rw-r----- 1 GreatSQL GreatSQL 492556 Dec 17 11:26 audit.log -rw-r----- 1 GreatSQL GreatSQL 1050204 Dec 17 11:26 audit.log.1 -rw-r----- 1 GreatSQL GreatSQL 1050485 Dec 17 11:26 audit.log.2 -rw-r----- 1 GreatSQL GreatSQL 1051191 Dec 17 11:26 audit.log.3 -rw-r----- 1 GreatSQL GreatSQL 1050767 Dec 17 11:26 audit.log.4 # audit.log发生轮转 $ ll audit* -rw-r----- 1 GreatSQL GreatSQL 993 Dec 17 11:26 audit.log -rw-r----- 1 GreatSQL GreatSQL 1542990 Dec 17 11:26 audit.log.1 -rw-r----- 1 GreatSQL GreatSQL 1050204 Dec 17 11:26 audit.log.2 -rw-r----- 1 GreatSQL GreatSQL 1050485 Dec 17 11:26 audit.log.3 -rw-r----- 1 GreatSQL GreatSQL 1051191 Dec 17 11:26 audit.log.4
日志写入audit.log文件,当达到audit_log_rotate_on_size
时,发生轮转:
删除audit.log.4,audit.log.3轮转为audit.log.4,audit.log.2轮转为audit.log.3,audit.log.1轮转为audit.log.2,audit.log轮转为audit.log.1
共保留audit_log_rotations个轮转的审计日志文件。
Enjoy GreatSQL :)
关于 GreatSQL
GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。
相关链接: GreatSQL社区 Gitee GitHub Bilibili
GreatSQL社区:
社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html
社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html
(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)
技术交流群:
微信&QQ群:
QQ群:533341697
微信群:添加GreatSQL社区助手(微信号:wanlidbc
)好友,待社区助手拉您进群。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
如何高效地为「推理模型」编写最佳提示词?万字长文介绍
编者按: 如何有效地为推理模型编写最佳提示词?对于 OpenAI 推出 O1 和 O3-mini 等这些专为深度推理而设计的模型,传统的提示词工程技巧是否仍然适用? 我们今天为大家带来的这篇文章,作者的观点是:推理模型与传统大语言模型在提示词处理方式上有本质不同,需要采用更简洁直接的提示词策略来充分发挥其优势。文章首先深入剖析了 OpenAI 的 O1/O3-mini 与 GPT-4o 三大模型的核心差异: O1/O3-mini 内置深度推理链,无需显式引导即可自主分析,而 GPT-4o 依赖提示词驱动分步思考; O1 系列在专业领域(如数学、法律)展现更强的多步骤推理与自检能力,而 GPT-4o 更擅长快速响应通用任务; O1/O3-mini 需避免冗余指令,强调简洁提问与结构化输出,而 GPT-4o 需主动引导推理过程。 然后进一步提出优化推理模型性能的实践方法,例如精简提示词、设定角色与格式指令,并以法律案例分析为例,演示如何通过精准设计提示词生成严谨的法律论证。 作者 | Agustinmantaras 编译 |岳扬 OpenAI 的 O1 和 O3-mini 是两款先进的推理...
- 下一篇
ClickHouse CPU 100%的问题排查与优化
背景 最近我们收到用户反馈,Sentry Web 无法正常刷数据,过一会儿又好了。经过初步排查,发现问题根源在于 ClickHouse 的 CPU 使用率居高不下,甚至达到了 100%,导致系统性能瓶颈。以下是我们对问题的详细分析、解决过程以及后续优化的总结,希望对遇到类似问题的团队有所帮助。 问题现象 从用户的反馈来看,Sentry Web 数据无法及时刷新,表现为页面加载缓慢甚至无响应。通过监控仪表盘,我们注意到 ClickHouse 的 CPU 使用率异常高,长时间维持在 90%-100% 之间,且 24 小时内变化不明显(如下图所示)。 上图显示,CPU 使用率波动在 90%-100% 之间。更值得注意的是,即使在凌晨流量较低的预期的流量波动规律不符。通常情况下,凌晨流量减少时,CPU 使用率应该随之下降,但实际情况并非如此。这让我们初步判断,CPU 高负载可能与流量没有直接关系,而是由其他因素导致。 原因分析 为了找到 CPU 打满的根本原因,我们从多个维度展开了排查。 1. CPU 使用率趋势与流量无关的初步判断 通过观察 24 小时的 CPU 使用率趋势,我们发现其波动幅...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Windows10,CentOS7,CentOS8安装Nodejs环境
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS关闭SELinux安全模块
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7