Zabbix 7.0 LTS 部署与 MySQL 分区实战：从零搭建到自动维护

简介本资源为Zabbix 7.0 LTS部署及数据库分区优化的操作记录文档面向运维工程师、监控系统管理员及需要处理Zabbix数据库性能瓶颈的技术人员。针对Zabbix历史记录与趋势表数据量膨胀、housekeeper进程繁忙告警频发的问题文档系统梳理了MySQL/MariaDB分区方案涵盖分区脚本获取、分区过程创建、定时自动执行、前端保留天数配置及分区参数调整等关键环节并附有备份提醒与大型库执行耗时说明。资源包为1个PDF文件大小约835KB内容紧凑便于随查随用。目前已有354人学习。读者可从中获得一套可落地的分区优化思路与脚本使用指引理解DROP分区相较DELETE语句在数据生命周期管理上的效率优势适用于Zabbix 3.0以后各版本帮助降低维护成本、提升数据库处理能力与监控系统长期稳定性。1. Zabbix 7.0 LTS 落地为什么数据库分区是绕不开的一步很多团队第一次部署 Zabbix 7.0 LTS都是照着官网文档一路dnf install或apt install前端能打开、主机能加、图形能出就以为完事了。真正的问题往往在三个月后爆发history、history_uint、trends这几张表涨到几千万行MySQL 单表查询开始拖慢前端加载历史数据转圈housekeeper 清理任务跑一整晚都清不完磁盘 IO 被拖满。这时候再回头做数据库分区就得停机、导数据、改表结构代价比一开始就规划好大得多。这篇记录讲的就是这件事在 Zabbix 7.0 LTS 上从零部署一套 Server MySQL/MariaDB并且把数据库分区方案一次性做对。适合两类人——准备新上 Zabbix 的运维和已经跑起来但被大表拖慢、想补分区的中级工程师。核心不是装个软件而是把部署和分区当成一个整体来设计让监控系统能稳定跑两三年不用动数据库。下面按部署、分区、踩坑、验证的顺序展开命令和参数都能直接抄。2. 部署前的选型与系统准备版本、数据库、硬件怎么定2.1 Zabbix 7.0 LTS 的组件构成与版本约束Zabbix 7.0 是 LTS 版本支持周期长生产环境优先选它而不是 6.0 或 7.2 这类非 LTS。它由几个独立组件组成zabbix-server核心采集与计算、zabbix-agent被监控端、zabbix-frontendPHP 前端、zabbix-proxy分布式采集可选。数据库是外部依赖Zabbix 自己不存数据全部落到 MySQL/MariaDB 或 PostgreSQL。版本上有个硬约束Zabbix 7.0 要求 MySQL 8.0.30 或 MariaDB 10.5。CentOS 7.9 自带的 MariaDB 5.5 太老直接装会报错必须换源或用官方仓库。这也是热词里centos7.9 安装 zabbix 最新版经常翻车的地方——系统太老依赖链跟不上。我的建议是新部署直接上 Rocky Linux 9 / AlmaLinux 9 / Ubuntu 22.04别在 CentOS 7 上硬撑。组件分工要清楚Server 负责轮询和触发器计算Frontend 只是 PHP 页面Agent 装在被监控机。数据库压力几乎全在 Server 侧所以 Server 和数据库最好同机或同内网低延迟别跨机房。2.2 数据库选 MySQL 还是 MariaDB这是部署前必须定的事。两者在 Zabbix 场景下都能用但分区行为有差异对比项MySQL 8.0MariaDB 10.5分区引擎InnoDB 原生分区InnoDB 原生分区分区管理语法ALTER TABLE ... REORGANIZE支持ALTER TABLE ... ADD PARTITION更灵活默认字符集utf8mb4utf8mb4Zabbix 官方推荐推荐推荐大表在线 DDL支持较好支持较好实操里我一般选 MySQL 8.0因为生态文档多、information_schema.partitions查询稳定、和 Zabbix 的兼容测试更充分。MariaDB 也能跑但分区维护脚本的语法细节要单独调。热词里给 mariadb root 设置密码mysql 安装配置教程这类需求本质都是部署第一步下面统一按 MySQL 8.0 写MariaDB 差异会单独标注。2.3 系统参数与依赖准备装之前先把系统层调好否则后面数据库和 Server 都会受影响。以 Rocky/AlmaLinux 9 为例# 关闭 SELinux生产可改为 permissive 并配策略测试环境直接关 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config # 时间同步Zabbix 对时间敏感偏差大会导致数据错乱 dnf install -y chrony systemctl enable --now chronyd chronyc sources # 文件句柄和进程数Zabbix Server 高并发时需要 cat /etc/security/limits.conf EOF zabbix soft nofile 65535 zabbix hard nofile 65535 zabbix soft nproc 65535 zabbix hard nproc 65535 EOF # 内核参数数据库和网络都要 cat /etc/sysctl.conf EOF vm.swappiness 10 net.core.somaxconn 1024 net.ipv4.tcp_max_syn_backlog 2048 fs.file-max 200000 EOF sysctl -p逻辑说明SELinux 在 Zabbix 前端连数据库时经常拦 socket 和端口测试环境先关掉省事生产环境建议保留 enforcing 但加对应布尔值。chrony 必须配Zabbix 的nodata触发器和趋势计算都依赖准确时间。limits.conf里的nofile是血泪经验——默认 1024 在高负载下 Server 会报 too many open files 然后采集中断。vm.swappiness10是让数据库尽量用内存而不是换页对分区大表的查询延迟有明显改善。参数怎么改nofile按监控主机数估1000 台以内 65535 够用上万台要上 200000。somaxconn和tcp_max_syn_backlog在 Agent 大量主动上报时有用默认值偏小。改完sysctl -p生效limits.conf需要重新登录 zabbix 用户才生效或者重启服务。失败时看什么chronyc sources如果显示^?说明没同步上检查 UDP 123 是否被防火墙拦。ulimit -n用 zabbix 用户执行确认是否生效没生效多半是 systemd 服务没读 limits需要在 unit 文件里加LimitNOFILE65535。3. 安装 Zabbix 7.0 LTS 与 MySQL 8.0从仓库到前端跑通3.1 安装 MySQL 8.0 并初始化先装数据库。用官方仓库别用系统自带的# 安装 MySQL 官方仓库Rocky/AlmaLinux 9 dnf install -y https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm dnf install -y mysql-community-server # 启动并设置开机自启 systemctl enable --now mysqld # 获取初始临时密码 grep temporary password /var/log/mysqld.log # 用临时密码登录并改密码MySQL 8 默认有密码强度策略 mysql -uroot -p登录后执行-- 修改 root 密码注意 MySQL 8 默认要求大小写数字符号 ALTER USER rootlocalhost IDENTIFIED BY Zbx_Str0ng_Pass!; -- 创建 Zabbix 专用库和用户字符集必须 utf8mb4 CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbixlocalhost IDENTIFIED BY Zbx_Db_Pass!; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; -- 分区和存储过程需要Zabbix 的 housekeeper 会用到 SET GLOBAL log_bin_trust_function_creators 1; FLUSH PRIVILEGES;逻辑说明utf8mb4_bin是 Zabbix 官方要求的排序规则用utf8mb4_general_ci会导致某些字符串比较和索引行为不一致。log_bin_trust_function_creators1是因为 Zabbix 建库时会创建存储过程和函数开了 binlog 的实例默认不允许不开这个会导入失败。这个参数重启会失效要写进my.cnf。参数说明innodb_buffer_pool_size是最关键的建议设为物理内存的 50%~70%。在/etc/my.cnf里加[mysqld] innodb_buffer_pool_size 4G innodb_log_file_size 1G innodb_flush_log_at_trx_commit 2 innodb_file_per_table 1 max_connections 500innodb_flush_log_at_trx_commit2是监控场景的常用折中牺牲一点持久性换写入性能Zabbix 数据丢几秒可接受。innodb_file_per_table1是分区的前提每个分区独立表空间方便后续维护。3.2 导入 Zabbix 初始 Schema装 Zabbix Server 包会自带 schema 文件位置在/usr/share/zabbix-sql-scripts/mysql/# 安装 Zabbix 7.0 仓库 rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm dnf clean all # 安装 server、frontend、agent dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent # 导入 schema注意先建库再导 zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix导入过程视机器性能要几分钟到十几分钟history相关表结构建好后是空的分区要在导入后、数据写入前做否则要迁移数据。逻辑说明server.sql.gz包含所有表结构、初始模板、触发器定义。导入顺序不能乱先建库再导否则报 Unknown database。导入完成后log_bin_trust_function_creators可以关掉。失败时看什么如果报ERROR 1419就是函数创建权限问题回去开log_bin_trust_function_creators。如果报字符集错误检查建库语句是不是utf8mb4_bin。导入中断可以用mysql -uzabbix -p zabbix 文件重跑但表已存在会报错建议先DROP DATABASE重来。3.3 配置 Server 与前端并启动编辑/etc/zabbix/zabbix_server.confDBHostlocalhost DBNamezabbix DBUserzabbix DBPasswordZbx_Db_Pass! DBSocket/var/lib/mysql/mysql.sock StartPollers20 StartPollersUnreachable10 StartTrappers10 StartPingers5 CacheSize128M HistoryCacheSize64M TrendCacheSize32M ValueCacheSize128M参数说明StartPollers按监控主机数调1000 台以内 20 够用每增加 1000 台加 10。CacheSize是配置缓存ValueCacheSize是触发器计算缓存这两个在大规模环境下要往上加默认 8M/8M 会频繁告警 value cache is full。HistoryCacheSize影响写入缓冲分区后写入压力分散可以适当调大。前端配置在/etc/php-fpm.d/zabbix.conf确认时区php_value[date.timezone] Asia/Shanghai然后启动systemctl restart zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent httpd php-fpm浏览器访问http://服务器IP/zabbix按向导走数据库填 zabbix 用户信息时区选 Asia/Shanghai完成后默认账号Admin/zabbix。登录后第一件事改密码第二件事检查Reports - System information里 Server 是否 running。失败时看什么前端报 Database error 多半是zabbix.conf.php里密码或 socket 路径不对。Server 起不来先看/var/log/zabbix/zabbix_server.log常见是数据库连不上或CacheSize设太大内存不够。net.tcp.port这类 key 测试不通检查 Agent 防火墙和zabbix_agentd.conf里的Server是否包含 Server IP。4. 数据库分区实操把 history 和 trends 大表拆开4.1 为什么必须分区以及分区的原理Zabbix 的数据表分两类配置表hosts、items、triggers和 histor 数据表history、history_uint、history_str、history_text、history_log、trends、trends_uint。配置表数据量小不用管。数据表里history和history_uint增长最快一个 1000 台主机的环境每天能写几千万行。不分区的话housekeeper 删除旧数据是DELETE FROM history WHERE clock xxx这是全表扫描加逐行删除几千万行能跑几小时期间锁表、IO 打满。分区后删除变成ALTER TABLE history DROP PARTITION p20240101直接删文件秒级完成。这就是分区的核心价值把删数据从 DML 变成 DDL。Zabbix 官方推荐按时间做 RANGE 分区每天一个分区保留 N 天。分区键必须是主键的一部分所以建表时主键要包含clock。Zabbix 7.0 的 schema 默认主键是(itemid, clock)或(itemid, clock, ns)正好满足分区要求不用改主键。4.2 分区前的准备确认表结构和主键先确认要分区的表主键是否包含 clockUSE zabbix; SHOW CREATE TABLE history\G SHOW CREATE TABLE history_uint\G SHOW CREATE TABLE trends\G SHOW CREATE TABLE trends_uint\G输出里找PRIMARY KEY应该是(itemid, clock)形式。如果只有itemid说明 schema 版本不对需要先升级或手动改主键这一步很关键主键不含 clock 无法按 clock 分区。还要确认innodb_file_per_table1否则分区数据还是挤在 ibdata 里DROP PARTITION 不释放空间SHOW VARIABLES LIKE innodb_file_per_table;返回 ON 才继续。另外确认没有外键约束引用这些表Zabbix 默认没有但如果有自定义改动要先处理。4.3 用存储过程批量建分区手动一天天建分区不现实用存储过程自动生成。下面这个脚本给history、history_uint、trends、trends_uint四张表各建未来 N 天的分区DELIMITER $$ DROP PROCEDURE IF EXISTS create_partitions$$ CREATE PROCEDURE create_partitions(IN days_ahead INT) BEGIN DECLARE d INT DEFAULT 0; DECLARE pname VARCHAR(20); DECLARE ptime INT; DECLARE nexttime INT; DECLARE tbl VARCHAR(50); DECLARE done INT DEFAULT 0; -- 需要分区的表列表 DECLARE cur CURSOR FOR SELECT table_name FROM information_schema.tables WHERE table_schema zabbix AND table_name IN (history,history_uint,trends,trends_uint); DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur; read_loop: LOOP FETCH cur INTO tbl; IF done THEN LEAVE read_loop; END IF; SET d 0; WHILE d days_ahead DO -- 分区名格式 p20240101按天 SET pname CONCAT(p, DATE_FORMAT(DATE_ADD(CURDATE(), INTERVAL d DAY), %Y%m%d)); SET ptime UNIX_TIMESTAMP(DATE_ADD(CURDATE(), INTERVAL d DAY)); SET nexttime UNIX_TIMESTAMP(DATE_ADD(CURDATE(), INTERVAL d1 DAY)); -- 分区不存在才建避免重复报错 IF NOT EXISTS ( SELECT 1 FROM information_schema.partitions WHERE table_schema zabbix AND table_name tbl AND partition_name pname ) THEN SET sql CONCAT(ALTER TABLE , tbl, ADD PARTITION (PARTITION , pname, VALUES LESS THAN (, nexttime, ))); PREPARE stmt FROM sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; END IF; SET d d 1; END WHILE; END LOOP; CLOSE cur; END$$ DELIMITER ;逻辑说明游标遍历四张表内层循环按天生成分区名和边界值。VALUES LESS THAN (nexttime)表示这个分区存clock nexttime的数据边界用次日零点时间戳保证每天数据落在对应分区。IF NOT EXISTS查information_schema.partitions避免重复建分区报错这个判断让脚本可以反复执行适合放进定时任务。参数说明days_ahead是提前建多少天建议设 7~14配合每天定时任务滚动创建。分区名p20240101格式便于识别和删除。时间戳用UNIX_TIMESTAMP生成注意服务器时区要和 Zabbix 一致否则边界会错位。调用CALL create_partitions(14);执行后验证SELECT table_name, partition_name, partition_description, table_rows FROM information_schema.partitions WHERE table_schema zabbix AND table_name history ORDER BY partition_ordinal_position;能看到 p20240101 到 p20240114 的分区就对了。4.4 自动删除过期分区保留策略按需定一般 history 保留 30~90 天trends 保留 1~2 年。删除脚本DELIMITER $$ DROP PROCEDURE IF EXISTS drop_old_partitions$$ CREATE PROCEDURE drop_old_partitions(IN keep_days INT) BEGIN DECLARE pname VARCHAR(20); DECLARE pdesc VARCHAR(20); DECLARE cutoff INT; DECLARE done INT DEFAULT 0; DECLARE tbl VARCHAR(50); DECLARE cur CURSOR FOR SELECT table_name FROM information_schema.tables WHERE table_schema zabbix AND table_name IN (history,history_uint,trends,trends_uint); DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; SET cutoff UNIX_TIMESTAMP(DATE_SUB(CURDATE(), INTERVAL keep_days DAY)); OPEN cur; read_loop: LOOP FETCH cur INTO tbl; IF done THEN LEAVE read_loop; END IF; -- 找所有边界小于 cutoff 的分区 BEGIN DECLARE done2 INT DEFAULT 0; DECLARE cur2 CURSOR FOR SELECT partition_name, partition_description FROM information_schema.partitions WHERE table_schema zabbix AND table_name tbl AND partition_name IS NOT NULL AND partition_description REGEXP ^[0-9]$ AND CAST(partition_description AS UNSIGNED) cutoff; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done2 1; OPEN cur2; drop_loop: LOOP FETCH cur2 INTO pname, pdesc; IF done2 THEN LEAVE drop_loop; END IF; SET sql CONCAT(ALTER TABLE , tbl, DROP PARTITION , pname); PREPARE stmt FROM sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; END LOOP; CLOSE cur2; END; END LOOP; CLOSE cur; END$$ DELIMITER ;逻辑说明cutoff是保留边界早于它的分区都删。partition_description是边界时间戳用正则过滤掉MAXVALUE这类非数字值。嵌套游标处理每张表的分区列表逐个 DROP。DROP PARTITION 是 DDL瞬间完成不产生大量 undo。参数说明keep_days按表类型区分history 类设 30trends 类设 365。但脚本里四张表共用一个参数实际用可以拆成两个过程或者按表名判断。我一般写两个调用history 用 30trends 用 365脚本里加个表名过滤即可。调用CALL drop_old_partitions(30);4.5 用定时任务滚动维护分区把建和删放进 crontab每天凌晨跑# 编辑 zabbix 或 root 的 crontab crontab -e # 每天 1 点建未来 14 天分区2 点删 30 天前的 history 分区 0 1 * * * mysql -uzabbix -pZbx_Db_Pass! zabbix -e CALL create_partitions(14); /var/log/zbx_partition.log 21 0 2 * * * mysql -uzabbix -pZbx_Db_Pass! zabbix -e CALL drop_old_partitions(30); /var/log/zbx_partition.log 21逻辑说明建分区放在删之前保证始终有可用分区。日志重定向便于排查。密码写在命令行有泄露风险生产建议用~/.my.cnf配置[client]段然后命令里不写密码。参数说明建分区时间选业务低峰DDL 虽然快但仍有短暂元数据锁。删分区同理。create_partitions(14)的 14 要大于 cron 执行间隔防止某天任务失败导致分区断档。失败时看什么如果报 Duplicate partition name说明分区已存在脚本的 IF NOT EXISTS 没生效检查information_schema.partitions查询条件。如果报 VALUES LESS THAN value must be strictly increasing说明新分区边界小于已有最大边界通常是时区或日期算错。分区断档会导致插入失败报 Table has no partition for value这时手动补建缺失日期即可。5. 分区部署的避坑清单五个真实翻车现场5.1 坑一导入 schema 后才想起分区数据已写入现象装完 Zabbix 跑了一周发现表大了才做分区ALTER TABLE ... PARTITION BY RANGE报错或耗时极长。原因已有数据的表做分区MySQL 要重建整张表几千万行会锁表很久期间 Zabbix 写入全部阻塞监控断档。解决分区必须在导入 schema 后、Zabbix Server 启动前做。如果已经跑了先停 Server用pt-online-schema-change或gh-ost在线改或者导出数据、重建分区表、再导入。最省事的办法是新建库重新导入 schema 并分区历史数据如果不要就丢弃要就单独迁移。5.2 坑二主键不含 clock分区建不了现象执行ALTER TABLE history PARTITION BY RANGE(clock)报 A PRIMARY KEY must include all columns in the tables partitioning function。原因MySQL 要求分区键必须是所有唯一键含主键的一部分。Zabbix 老版本 schema 主键可能只有itemid。解决确认 schema 版本Zabbix 7.0 默认主键已含 clock。如果是升级上来的老库需要先ALTER TABLE history DROP PRIMARY KEY, ADD PRIMARY KEY(itemid, clock)但这一步在大表上很慢建议在低峰期做或者干脆重建。5.3 坑三housekeeper 和分区打架数据被重复删现象做了分区又开着 housekeeper发现 housekeeper 还在跑 DELETEIO 没降下来。原因Zabbix 的 housekeeper 默认开启按HistoryStoragePeriod删数据和分区删除重复。分区后应该关掉 housekeeper 对 history/trends 的清理。解决在zabbix_server.conf里设HousekeepingFrequency0关闭自动 housekeeping或者在前端Administration - Housekeeping里把 history/trends 的保留期设为 0 并禁用。数据保留完全交给分区脚本管理。5.4 坑四分区边界时区错位数据插不进现象Zabbix 报 Table has no partition for value 1704067200但明明建了那天的分区。原因MySQL 服务器时区和 Zabbix Server 时区不一致UNIX_TIMESTAMP按 MySQL 时区算Zabbix 写入的 clock 按自己时区算差 8 小时导致边界错位。解决统一时区。MySQL 配default-time-zone08:00Zabbix Server 和前端 PHP 都设Asia/Shanghai。建分区脚本里的CURDATE()依赖 MySQL 时区必须一致。验证方法SELECT NOW(), UNIX_TIMESTAMP(NOW())和date %s对比。5.5 坑五DROP PARTITION 后磁盘空间没释放现象删了分区df -h显示磁盘没变小。原因innodb_file_per_table0时分区数据在共享表空间 ibdata 里DROP 不释放文件。或者有长事务持有旧分区快照空间延迟回收。解决确认innodb_file_per_table1这是分区释放空间的前提。如果有长事务SHOW PROCESSLIST找出来 kill 掉。另外DROP PARTITION后空间释放是异步的等几分钟再看。如果还是没释放检查是不是有ibd文件残留必要时OPTIMIZE TABLE重建。6. 验证分区效果与长期维护的几个技巧分区做完不是终点得验证它真的起作用并且能长期稳定跑。下面是我常用的验证和维护手法。先看分区是否均匀。执行SELECT partition_name, table_rows, ROUND(data_length/1024/1024, 2) AS data_mb, ROUND(index_length/1024/1024, 2) AS idx_mb FROM information_schema.partitions WHERE table_schema zabbix AND table_name history_uint ORDER BY partition_ordinal_position DESC LIMIT 10;如果每个分区table_rows量级接近说明写入均匀如果某个分区特别大可能是那天有异常刷数据或者分区边界算错导致数据挤在一个分区。data_mb和idx_mb能看出单分区大小一般一天一个分区在几百 MB 到几 GB 之间超过 10G 要考虑拆成更细粒度或按小时分区。再看删除效率。对比分区前后的 housekeeper 耗时-- 分区前这条会跑很久 -- DELETE FROM history WHERE clock UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 30 DAY)); -- 分区后秒级 ALTER TABLE history DROP PARTITION p20240101;用SHOW PROFILES或直接看执行时间差距是数量级的。我实测过一个 5000 万行的 history 表DELETE 要 40 分钟DROP PARTITION 不到 1 秒。长期维护有几个习惯。第一分区脚本要幂等能重复执行不报错这样 cron 某天失败补跑不会出问题。第二监控分区数量写个 item 采集information_schema.partitions的 count低于阈值告警防止建分区任务挂了没人发现。第三定期检查MAXVALUE分区如果发现数据落进 MAXVALUE说明建分区断档了要立即补建并清理 MAXVALUE 里的数据。第四升级 Zabbix 大版本时先确认新 schema 的主键和分区兼容别升级完分区失效。还有个技巧trends 表数据量比 history 小得多但保留时间长可以按月分区而不是按天减少分区数量。改分区粒度要重建表建议一开始就规划好——history 按天、trends 按月这是我踩过几次坑后固定的做法。最后说个验证分区是否真正生效的命令EXPLAIN SELECT * FROM history WHERE clock UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 1 DAY));看partitions列如果只列出最近一两个分区而不是全部说明分区裁剪生效查询只扫相关分区。如果列出所有分区说明分区键没用上检查查询条件是否带 clock。这套方案我从 Zabbix 5.0 用到 7.0核心逻辑没变schema 导入后立即分区housekeeper 关掉cron 滚动维护时区统一。每次新环境部署我都会先把分区脚本准备好再启动 Server省得后面补。希望帮到你。本文还有配套的精品资源点击获取