MySQL 常见日志清理策略

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介: 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 中六种常见日志及其清理策略,不同环境可以采用不同的清理策略,本文只是提供一种思路,方法各种各样,重要的是要根据实际情况制定合理的日志保留策略,并确保不会影响到数据库的正常运行和备份需求。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2天前
|
缓存 关系型数据库 MySQL
MySQL慢查询优化策略
MySQL慢查询优化是一个复杂的过程,需要根据具体的应用场景和数据特点进行。以上策略是提升数据库查询性能的有效途径,但最关键的是对系统进行持续的监控和分析,及时发现并解决性能瓶颈。通过实践这些策略,你可以显著提高MySQL数据库的性能,为用户提供更快的响应时间和更好的体验。
15 3
|
10天前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
34 0
|
10天前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
26 0
|
11天前
|
SQL 关系型数据库 MySQL
深入探索MySQL索引策略
本文旨在深入探讨MySQL(8.0.26)数据库中索引的设计与优化方法。
|
17天前
|
消息中间件 API C#
【Azure API 管理】APIM添加Log-to-eventhub的策略后,一些相关APIM与Event Hub的问题
【Azure API 管理】APIM添加Log-to-eventhub的策略后,一些相关APIM与Event Hub的问题
|
17天前
|
存储 API C#
【Azure API 管理】在APIM 中添加 log-to-eventhub 策略,把 Request Body 信息全部记录在Event Hub中
【Azure API 管理】在APIM 中添加 log-to-eventhub 策略,把 Request Body 信息全部记录在Event Hub中
|
17天前
|
存储 关系型数据库 MySQL
深入MySQL:事务日志redo log详解与实践
【8月更文挑战第24天】在MySQL的InnoDB存储引擎中,为确保事务的持久性和数据一致性,采用了redo log(重做日志)机制。redo log记录了所有数据修改,在系统崩溃后可通过它恢复未完成的事务。它由内存中的redo log buffer和磁盘上的redo log file组成。事务修改先写入buffer,再异步刷新至磁盘,最后提交事务。若系统崩溃,InnoDB通过redo log重放已提交事务并利用undo log回滚未提交事务,确保数据完整。理解redo log工作流程有助于优化数据库性能和确保数据安全。
73 0
|
17天前
|
存储 SQL 关系型数据库
MySQL事务日志奥秘:undo log大揭秘,一文让你彻底解锁!
【8月更文挑战第24天】本文深入探讨了MySQL中undo log的关键作用及其在确保事务原子性和一致性方面的机制。MySQL通过记录事务前的数据状态,在需要时能回滚至初始状态。主要介绍InnoDB存储引擎下的undo log实现,包括undo segment和record的结构,而MyISAM则采用redo log保障持久性而非一致性。通过一个简单的SQL回滚示例,展示了undo log如何在实际操作中发挥作用,帮助读者更好地理解并运用MySQL事务管理功能。
76 0
|
18天前
|
SQL 存储 关系型数据库
MySQL日志,你知多少?
MySQL日志,你知多少?
35 0
|
16天前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)

相关产品

  • 云数据库 RDS MySQL 版
  • 下一篇
    DDNS