MySQL 常见日志清理策略

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: MySQL 数据库服务器使用多种类型的日志来记录操作和事件,这对于故障诊断、审计和性能分析非常重要。然而,这些日志文件会随着时间的推移而不断增长,可能会占用大量的磁盘空间。因此,定期清理这些日志是必要的,本篇文章我们一起来学习下如何清理 MySQL 中的日志文件。

前言:

MySQL 数据库服务器使用多种类型的日志来记录操作和事件,这对于故障诊断、审计和性能分析非常重要。然而,这些日志文件会随着时间的推移而不断增长,可能会占用大量的磁盘空间。因此,定期清理这些日志是必要的,本篇文章我们一起来学习下如何清理 MySQL 中的日志文件。

二进制日志 (Binary Log)

binlog 记录了数据库所有的 DDL(数据定义语言)和 DML(数据操作语言)更改操作,一般都是建议开启 binlog 的,要注意的是 binlog 会占用大量磁盘空间,特别是你的数据库特别繁忙的情况下。这个时候就要制定清理策略了。

MySQL 5.7 可以通过 expire_logs_days 参数来设置 binlog 删除时间,在 my.cnf 配置文件中设置 expire_logs_days 参数,指定二进制日志文件的过期天数,过期的日志文件将会自动被删除。在 MySQL 8.0 中建议使用 binlog_expire_logs_seconds 参数,此参数同样是控制二进制文件过期时间,单位是秒。binlog 具体要保留多久,可以根据磁盘空间决定,磁盘充足可以多保留,一般建议至少保留 7 天。

除了通过设置参数自动清理外,binlog 还可以使用 PURGE BINARY LOGS 命令来手动执行清理。例如,使用 purge binary logs to 'mysql-bin.000009' 来删除 mysql-bin.000009 之前的日志文件,或者使用 purge binary logs before '2024-07-15 00:00:00' 来删除指定时间之前的日志文件。

通用查询日志 (General Query Log)

MySQL 的 general_log 是记录所有到达 MySQL 服务器的 SQL 语句的日志。由于它记录了所有的 SQL 语句,包括连接、查询、更新等操作,因此其日志量可能增长非常迅速,通常在生产环境中不建议开启此功能,以免影响性能。如果你的数据库为了等保评测或者其他原因开启了 general_log ,那就要及时制定清理策略了。

官方并没有提供用于清理 general_log 的参数或命令,因此清理 general_log 只能各显神通了,一般情况下可以通过写 shell 脚本来执行清理,比如说每天凌晨进行日志切换,删除几天前的日志文件。也可以使用 logrotate 功能来配置 general_log 自动轮转及清理。

错误日志 (Error Log)

错误日志记录 MySQL 服务器启动、关闭及运行时发生的错误及警告信息。一般是默认开启的,不过错误日志增长速度很慢,通常不需要频繁清理,可以手动清理或设置定期任务清理旧的日志文件。错误日志保留时间可以更长些。

慢查询日志 (Slow Query Log)

慢日志主要用于记录执行时间超过设定阈值的 SQL 查询。慢查询日志对于数据库的性能优化非常重要,因为它可以帮助数据库管理员和开发者识别和优化那些执行效率低下的查询。慢日志也是建议开启的。

通常情况下,我们可以根据系统情况来设置慢 SQL 阈值,比如 1s 或 3s 。慢日志一般情况下增长速度也不是很快,只要持续进行 SQL 优化,慢日志会越来越少的。通常慢日志也不需要频繁清理,一般我们可以每一周或每一月重命名一次,然后保留几份这样来制定清理策略,可以交由 shell 脚本自动执行。

审计日志 (Audit Log)

MySQL 社区版官方并没有提供审计日志,如果想开启审计日志,只能借助 MariaDB 或 Percona Server 等其他审计插件。审计日志增长速度也比较快,一般审计插件都提供清理参数,比如说日志文件到达多少 M 自动轮换,保留几份日志文件等,一定要设置好此类参数,以防占用大量磁盘空间。

中继日志 (Relay Log)

中继日志是 MySQL 复制过程中用于存储从主服务器接收的二进制日志事件的临时日志文件。这些日志文件由从服务器用来应用来自主服务器的更新。中继日志只存在于从服务器上,relay log 文件会随着事件被应用而逐渐增长,因此也需要适当的清理策略来管理这些文件。

MySQL 官方提供了 relay_log_pure 参数,此参数决定了 relay log 文件在被完全应用后是否应该被自动删除。这个参数有两个可能的值:ON 和 OFF ,设置为 ON 代表当中继日志应用完成后会自动删除,OFF 则不会自动删除。一般情况下,建议开启此参数,这样 relay log 应用完就会被清理掉,不会占用大量磁盘空间。

如果你的从服务器要求关闭 relay_log_pure 参数,例如在 MHA 高可用架构下,为了确保在故障转移时能够使用 relay log 进行恢复,通常需要禁用从服务器上的中继日志自动清理功能。这个时候就要想其他办法来清理 relay log 了。MHA 提供了一个名为 purge_relay_logs 的 perl 脚本,可通过 purge_relay_logs 脚本配合 cronjob 来完成此清理任务。若 purge_relay_logs 脚本无法使用,那么只能自己写 shell 脚本了,比如可以定期将 relay_log_pure 设为 ON ,然后执行 flush relay logs 后,再将 relay_log_pure 设为 OFF ,这样操作下来一般也能实现清理 relay log 。实在不行我们还可以使用 find 命令来找到几天前的日志文件,然后直接 rm 清理掉,不过用 find 找到后直接 rm 删除这种方法会导致 relay-log.indx 索引文件中记录 relay log 与实际存在的不匹配,所以直接 rm 删除 relay log 后还要记得更新下 relay-log.indx 索引文件。

总结:

本篇文章简单介绍了 MySQL 中六种常见日志及其清理策略,不同环境可以采用不同的清理策略,本文只是提供一种思路,方法各种各样,重要的是要根据实际情况制定合理的日志保留策略,并确保不会影响到数据库的正常运行和备份需求。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2天前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
15 4
|
3天前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
27 16
|
5天前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
164 90
|
17天前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。
|
20天前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
38 3
|
20天前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
42 4
图解MySQL【日志】——两阶段提交
|
20天前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
28 5
图解MySQL【日志】——Redo Log
|
22天前
|
缓存 关系型数据库 MySQL
图解MySQL【日志】——Buffer Pool
Buffer Pool 是数据库管理系统(DBMS)中用于缓存磁盘数据页的内存区域,主要包含数据页、索引页、undo 页等。它通过减少磁盘 I/O 提升性能,特别是在处理大型数据库时效果显著。查询时,整个数据页而非单条记录会被加载到 Buffer Pool 中,以提高访问效率。
22 0
图解MySQL【日志】——Buffer Pool
|
3天前
|
缓存 Java 编译器
|
22天前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
35 0

相关产品

  • 云数据库 RDS MySQL 版