1. 日志文件分类与监控
- 分类:
- 为每个MySQL实例创建独立的日志目录,分别存放二进制日志(
binlog
)、错误日志(errorlog
)、慢查询日志(slowquerylog
)等。例如,对于实例1,目录结构可以是/var/lib/mysql/instance1/logs/binlog
,/var/lib/mysql/instance1/logs/errorlog
等。
- 这样可以清晰区分不同实例的日志,方便管理和维护。
- 监控:
- 使用系统自带的磁盘空间监控工具,如
df -h
命令定期检查磁盘使用情况。同时,可以集成监控系统,如Prometheus + Grafana,对每个实例日志目录的磁盘使用量进行实时监控和可视化展示。例如,通过编写脚本获取每个实例日志目录的磁盘使用百分比,并将数据推送到Prometheus中,在Grafana中创建仪表盘展示。
- 监控MySQL实例内部的日志相关指标,如
SHOW BINARY LOGS
查看二进制日志文件列表及大小,SHOW VARIABLES LIKE'slow_query_log_file'
查看慢查询日志路径和相关配置等。通过监控这些指标,可以提前发现日志增长异常情况。
2. 二进制日志清理策略
- 基于时间的清理:
- 在MySQL配置文件(
my.cnf
)中,为每个实例设置binlog_expire_logs_seconds
参数。例如,对于需要保留7天二进制日志的实例,可以设置binlog_expire_logs_seconds = 604800
(7 * 24 * 60 * 60)。这样MySQL会自动清理过期的二进制日志文件,释放磁盘空间。
- 可以编写定时任务,定期运行
PURGE BINARY LOGS BEFORE 'YYYY - MM - DD HH:MM:SS';
语句,进一步确保二进制日志按预期清理。例如,每天凌晨2点运行该语句清理7天前的日志。
- 基于大小的清理:
- 设置
max_binlog_size
参数,限制单个二进制日志文件的大小。当二进制日志文件达到该大小时,MySQL会自动创建新的二进制日志文件。例如,设置max_binlog_size = 100M
,当当前二进制日志文件达到100MB时,会生成新的日志文件。
- 结合基于时间的清理策略,当磁盘空间紧张时,可以手动触发
PURGE BINARY LOGS
操作,清理较旧且较小的二进制日志文件,优先释放空间。
3. 错误日志和慢查询日志清理策略
- 错误日志:
- 可以设置
log_error_verbosity
参数来控制错误日志的详细程度,避免过多无用信息占用空间。一般设置为2或3,保留关键错误信息。
- 定期备份错误日志并清理,例如每周日凌晨3点将错误日志备份到
/var/lib/mysql/instance1/logs/errorlog_backup/errorlog_YYYYMMDD
,然后清空当前错误日志文件。可以使用如下脚本实现:
#!/bin/bash
INSTANCE=instance1
DATE=$(date +%Y%m%d)
mkdir -p /var/lib/mysql/${INSTANCE}/logs/errorlog_backup
cp /var/lib/mysql/${INSTANCE}/logs/errorlog /var/lib/mysql/${INSTANCE}/logs/errorlog_backup/errorlog_${DATE}
echo "" > /var/lib/mysql/${INSTANCE}/logs/errorlog
- 慢查询日志:
- 合理设置
long_query_time
参数,定义慢查询的时间阈值,避免记录过多非慢查询语句。例如设置为2秒,表示查询时间超过2秒的语句才会记录到慢查询日志。
- 定期分析慢查询日志,优化查询语句。分析完成后,按照一定周期清理慢查询日志,如每月1号凌晨4点备份并清理。备份脚本类似错误日志备份脚本:
#!/bin/bash
INSTANCE=instance1
DATE=$(date +%Y%m%d)
mkdir -p /var/lib/mysql/${INSTANCE}/logs/slowquerylog_backup
cp /var/lib/mysql/${INSTANCE}/logs/slowquerylog /var/lib/mysql/${INSTANCE}/logs/slowquerylog_backup/slowquerylog_${DATE}
echo "" > /var/lib/mysql/${INSTANCE}/logs/slowquerylog
4. 高可用性场景下的健壮性与可扩展性
- 健壮性:
- 在主从复制架构中,从库的日志清理策略要与主库保持一致。可以通过在主从库的配置文件中设置相同的日志清理相关参数来实现。同时,要确保在主从切换时,新的主库能够继续按照既定的日志清理策略运行。
- 对于多节点的高可用集群(如Galera Cluster),每个节点的日志清理任务要独立运行且不影响集群的正常同步。可以通过配置文件在每个节点上设置相同的日志清理参数,并且在执行清理任务时,确保不会误删除正在被其他节点同步的日志文件。
- 可扩展性:
- 当新增MySQL实例时,自动化部署脚本应包含日志目录创建、日志清理相关参数设置等步骤。例如,使用Ansible或Puppet等自动化工具,在部署新实例时,根据模板配置文件为新实例创建日志目录,并设置合理的日志清理参数。
- 监控系统要具备可扩展性,能够方便地添加新实例的日志监控指标。例如,在Prometheus中,可以通过配置文件动态发现新实例的日志监控数据采集任务,在Grafana中能够快速添加新实例的日志监控仪表盘。