-
Problem report
-
Resolution: Fixed
-
Critical
-
5.0.22, 6.0.5rc1
-
None
-
Sprint 89 (Jun 2022), Sprint 90 (Jul 2022), Sprint 91 (Aug 2022)
-
1
Steps to reproduce:
- Administration -> General -> Housekeeping -> uncheck "Enable internal housekeeping" under "History" and "Trends"
- Create a host with some item, delete an item
- Connect to the database, execute query - select * from housekeeper
Result:
MariaDB [zabbix60_server]> select * from housekeeper; +---------------+--------------+--------+-------+ | housekeeperid | tablename | field | value | +---------------+--------------+--------+-------+ | 1 | trends | itemid | 43171 | | 2 | trends_uint | itemid | 43171 | | 3 | history_text | itemid | 43171 | | 4 | history_log | itemid | 43171 | | 5 | history_uint | itemid | 43171 | | 6 | history_str | itemid | 43171 | | 7 | history | itemid | 43171 | | 8 | events | itemid | 43171 | +---------------+--------------+--------+-------+ 8 rows in set (0.000 sec)
Expected:
MariaDB [zabbix60_server]> select * from housekeeper; +---------------+--------------+--------+-------+ | housekeeperid | tablename | field | value | +---------------+--------------+--------+-------+ | 1 | events | itemid | 43171 | +---------------+--------------+--------+-------+ 1 row in set (0.000 sec)
Larger installations can use partitioning to clean up the history* and trends* tables. In this case, internal housekeeper is disabled and will never delete those rows. Over time, this table can get so huge that even
select * from housekeeper where tablename=events
can take over 60 seconds.
Reproduced on 5.0.19 and 6.0.5, was not able to reproduce in master branch.
There are no Sub-Tasks for this issue.
