Zabbix 7.0 LTS 数据库分区实战：告别 housekeeper 性能瓶颈

简介面向Zabbix运维人员与监控系统管理员的一份实操型PDF文档聚焦Zabbix 7.0 LTS部署后MySQL/MariaDB历史记录与趋势表的分区优化帮助解决数据量增长带来的数据库性能压力与housekeeper繁忙告警问题。资源包共1个PDF文件大小约835KB内容围绕分区脚本的获取与执行、分区过程的定期自动运行、前端保留天数配置及分区天数调整等环节展开并附有备份提醒与大型库执行耗时说明兼顾新装与存量环境。目前已有357人学习。读者可从中获得一套可落地的分区维护思路与脚本使用参考理解DROP分区相较DELETE语句在清理旧数据上的效率优势并掌握事件调度或定时任务驱动分区维护的配置要点适合具备一定数据库基础、希望降低维护成本并保障监控系统长期稳定运行的中高级用户对照实践。1. Zabbix 7.0 LTS 部署后第一刀为什么我上来就动数据库分区刚把 Zabbix 7.0 LTS 跑起来的那几天前端一切正常直到某天凌晨收到一条告警housekeeper 进程占用超过 75%。点进去看历史表和趋势表已经堆到千万行级别内务清理的 DELETE 语句在 InnoDB 上跑得又慢又锁监控数据写入开始出现延迟。这不是配置问题是数据生命周期管理方式选错了。Zabbix 默认靠 housekeeper 用 DELETE 删旧数据数据量一大就变成性能黑洞。数据库分区换了个思路按小时或天把历史表、趋势表切成独立分区过期数据直接 DROP PARTITION比 DELETE 快一个数量级还几乎不产生 undo 和锁竞争。这篇记录面向已经部署完 Zabbix 7.0 LTS、正在被 housekeeper 告警困扰的运维和数据库同学把分区脚本怎么落地、事件调度怎么配、前端保留天数怎么对齐、以及我踩过的几个坑一次讲清。2. 分区脚本拆解zbx_db_partitiong.sql 里到底跑了什么2.1 四个存储过程的分工这份分区脚本的核心不是一条 SQL而是四个存储过程组成的维护链路。理解它们各自干什么后面改参数才不会改错地方。存储过程作用关键参数partition_create为指定表创建一个新分区SCHEMANAME、TABLENAME、PARTITIONNAME、CLOCK分区上限时间戳partition_drop删除早于指定日期的分区SCHEMANAME、TABLENAME、DELETE_BELOW_PARTITION_DATEpartition_verify检查表是否已分区未分区则做初始分区SCHEMANAME、TABLENAME、HOURLYINTERVALpartition_maintenance编排前三个过程先校验、再补建未来分区、最后删过期分区SCHEMA_NAME、TABLE_NAME、KEEP_DATA_DAYS、HOURLY_INTERVAL、CREATE_NEXT_INTERVALSpartition_maintenance 是入口它按 KEEP_DATA_DAYS 算出过期日期按 HOURLY_INTERVAL 决定分区粒度24 表示按天按 CREATE_NEXT_INTERVALS 决定提前建几个未来分区。脚本默认对 history、history_log、history_str、history_text、history_uint、trends、trends_uint 七张表逐一调用保留 7 天历史和 365 天趋势。2.2 分区键为什么必须是 clockZabbix 的历史表和趋势表都有 clock 字段存的是 Unix 时间戳。分区脚本用PARTITION BY RANGE (clock)每个分区的上限是一个整点时间戳。这意味着分区边界天然按时间递增过期判断只需要比较分区名里的日期数字不需要扫表。这也是为什么脚本里 partition_drop 用CAST(SUBSTRING(partition_name FROM 2) AS UNSIGNED)把p202401010000这样的分区名转成数字再比较——分区名本身就是时间索引。需要留意的是一旦表按 clock 做了 RANGE 分区clock 就必须是分区键的一部分后续任何唯一索引都得包含 clock。Zabbix 原生表结构本身满足这个条件但如果你之前手动加过唯一索引脚本执行会报错得先处理掉。2.3 脚本落地的完整命令把脚本拿到数据库服务器上先解压再导入。下面这段是标准动作用户名、密码、库名换成你自己的# 下载并解压分区脚本包 wget http://bestmonitoringtools.com/dl/zbx_db_partitiong.tar.gz tar -zxvf zbx_db_partitiong.tar.gz # 导入脚本创建四个存储过程此时还未真正分区 mysql -u zabbix -pzabbixDBpass zabbix zbx_db_partitiong.sql导入完成后存储过程已经存在但表还没分区。真正触发分区的是第一次调用 partition_maintenance_all。新库上这一步几秒到几十秒大库上可能跑几个小时因为要对存量数据做一次全表重组。我一般会先在低峰期手动跑一次观察输出里的partition_create(...)消息确认分区按预期生成# 手动执行一次全量维护触发初始分区 mysql -u zabbix -pzabbixDBpass zabbix -e CALL partition_maintenance_all(zabbix); # 检查 history 表的分区结构 mysql -u zabbix -pzabbixDBpass zabbix -e SHOW CREATE TABLE history\G输出里应该能看到PARTITION BY RANGE (clock)以及若干PARTITION pYYYYMMDDHH00 VALUES LESS THAN (...)。如果只看到表结构没有 PARTITION 段说明 partition_verify 判定表已分区或执行中断需要回看报错。提示大库首次分区前务必做一次逻辑备份。分区过程会重建表中途失败回滚代价很高新装环境可以跳过备份生产环境不要省这一步。3. 自动化调度事件调度器与 Crontab 怎么选3.1 启用 MySQL 事件调度器分区过程建好后不会自己跑必须挂一个周期任务。MySQL 自带事件调度器是最省事的方式但默认是关闭的。在 MySQL/MariaDB 配置文件[mysqld]段落下加一行[mysqld] event_scheduler ON配置文件位置因发行版而异常见在/etc/mysql/mariadb.conf.d/或/etc/my.cnf.d/下。找不到就用grep --include*.cnf -irl / -e \[mysqld\]搜一下。改完重启数据库然后确认开关状态sudo systemctl restart mysql mysql -u zabbix -pzabbixDBpass zabbix -e SHOW VARIABLES LIKE event_scheduler;Value 显示 ON 才算生效。接着创建每 12 小时执行一次的事件CREATE EVENT zbx_partitioning ON SCHEDULE EVERY 12 HOUR DO CALL partition_maintenance_all(zabbix);12 小时这个间隔是脚本作者的建议值目的是让未来分区始终领先当前时间至少一个周期避免写入时找不到对应分区。事件建好后可以用SELECT * FROM INFORMATION_SCHEMA.events\G看 LAST_EXECUTED 是否在推进。3.2 Crontab 方案与日志落盘有些环境不允许开事件调度器或者 DBA 更习惯用系统级定时任务那就走 Crontab。每天凌晨 3:30 跑一次输出重定向到日志文件方便排查# 编辑 root 的 crontab sudo crontab -e # 加入以下行 30 03 * * * /usr/bin/mysql -u zabbix -pzabbixDBpass zabbix -e CALL partition_maintenance_all(zabbix); /tmp/CronDBpartitiong.log 21两种方案二选一不要同时挂否则同一时间两个会话抢着建分区、删分区容易撞上元数据锁。Crontab 方案的好处是日志独立、失败可见事件调度器方案的好处是不依赖系统 cron 服务容器化环境里更稳。3.3 前端保留天数必须与分区参数对齐这一步最容易被忽略。分区脚本按自己的 KEEP_DATA_DAYS 删数据Zabbix 前端的管理→一般→管家里的保留天数如果和脚本不一致会出现两种尴尬前端设得比脚本长前端以为还有数据实际分区已被删图表断档前端设得比脚本短housekeeper 还在跑 DELETE分区优化等于白做。正确做法是关掉管家对历史/趋势的清理把生命周期完全交给分区。具体操作管理→一般→管家取消“开启内部管家”里历史记录和趋势部分的勾选勾上“覆盖监控项趋势期间”把历史和趋势天数填成与脚本一致的值默认 7 天和 365 天保存。这样前端只负责展示删数据的事由分区过程接管。4. 参数调整与避坑改保留天数、换分区粒度时的翻车点4.1 改保留天数不要重跑原脚本上线一段时间后经常要调保留期比如历史从 7 天放到 30 天、趋势从 365 天放到 400 天。很多人第一反应是改脚本里的数字再导入一遍这会和已有存储过程冲突。正确做法是新建一个带新参数的过程再让调度指向它DELIMITER $$ CREATE PROCEDURE partition_maintenance_all_30and400(SCHEMA_NAME VARCHAR(32)) BEGIN CALL partition_maintenance(SCHEMA_NAME, history, 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, history_log, 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, history_str, 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, history_text, 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, history_uint, 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, trends, 400, 24, 3); CALL partition_maintenance(SCHEMA_NAME, trends_uint, 400, 24, 3); END$$ DELIMITER ;参数含义第三个参数是保留天数第四个 24 表示按天分区按小时就是 1第五个 3 表示提前建 3 个未来分区。建好后把事件或 Crontab 指向新过程ALTER EVENT zbx_partitioning ON SCHEDULE EVERY 12 HOUR DO CALL partition_maintenance_all_30and400(zabbix);Crontab 用户则注释掉旧行、加新行旧过程留在库里不删方便回退。4.2 常见问题排查现象前端图表空白日志报[Z3005] query failed: [1526] Table has no partition for value ...原因未来分区没提前建够写入时间戳超出了最大分区上限。常见于调度任务失败或间隔设得太长。 解决手动执行一次CALL partition_maintenance_all(zabbix);补建分区然后把调度间隔从 24 小时缩到 12 小时或把 CREATE_NEXT_INTERVALS 从 3 调到 5。现象分区过程执行到一半报唯一索引相关错误原因表上存在不含 clock 的唯一索引与 RANGE(clock) 分区不兼容。 解决先SHOW INDEX FROM history找出非 clock 参与的唯一索引评估后删除或改为普通索引再重跑分区。现象housekeeper 告警消失但磁盘不降原因分区删了但 InnoDB 表空间没回收或者前端管家还在跑 DELETE 产生大量 undo。 解决确认管家历史/趋势清理已关闭必要时对已分区表做OPTIMIZE TABLE回收空间安排在低峰期。现象事件调度器显示 ON但 LAST_EXECUTED 一直不更新原因事件创建时用了DO CALL但过程名拼错或数据库用户没有 EVENT 权限。 解决SHOW EVENTS看状态用SHOW GRANTS FOR zabbixlocalhost确认有 EVENT 权限必要时GRANT EVENT ON zabbix.* TO zabbixlocalhost;。现象首次分区在千万级大表上跑了数小时期间监控写入变慢原因ALTER TABLE 重建表期间持有元数据锁写入排队。 解决这是预期行为安排在维护窗口执行如果业务不能停考虑先在从库或克隆库上分区再切换或者分批对单表执行 partition_maintenance 而不是一次性 all。5. 验证分区真的生效三条查询和一个习惯分区配完不等于生效我习惯用三条查询做验收。第一条看分区数量和边界SELECT partition_name, partition_description, table_rows FROM information_schema.partitions WHERE table_schema zabbix AND table_name history ORDER BY partition_ordinal_position;partition_description 是每个分区的上限时间戳正常情况下应该覆盖到未来几天且最早的分区日期不早于保留期起点。第二条看事件或 cron 是否在跑SELECT event_name, status, last_executed, interval_value, interval_field FROM information_schema.events WHERE event_schema zabbix;last_executed 应该在一个调度周期内。第三条验证过期分区确实被删隔天再查一次分区列表最早分区名应该往后推进了一天。一个具体技巧把这三条查询包成一个巡检脚本挂到 Zabbix 自己的监控项上用mysql -N -e输出分区数量设触发器“分区数连续两个周期不增长”就告警。这样分区链路本身也被监控覆盖不会出现调度悄悄挂掉、几天后才发现图表断档的情况。还有个参数边界值得记一下HOURLY_INTERVAL 设成 1 是按小时分区分区数量会膨胀到保留天数乘 24元数据开销明显上升除非写入量极大否则不建议设成 24 按天分区是大多数场景的平衡点。CREATE_NEXT_INTERVALS 不要小于 2否则一次调度失败就可能出现无分区可写的窗口。从那以后我每次给 Zabbix 做分区都会先把前端管家和脚本保留天数对齐、再手动跑一次全量维护看输出、最后把三条验收查询挂成监控项三步缺一不可。希望帮到你。本文还有配套的精品资源点击获取