-
Change Request
-
Resolution: Fixed
-
Trivial
-
None
-
None
-
Team A
-
Sprint 80 (Sep 2021), Sprint 81 (Oct 2021), Sprint 82 (Nov 2021), Sprint 83 (Dec 2021), Sprint 84 (Jan 2022), Sprint 85 (Feb 2022)
-
2
- Zabbix must use primary keys for all tables including history* tables
- New schema will be used only for Zabbix 6.0 and later installations
- Older schema will be used when upgrading to Zabbix 6.0
- Existing database queries must be reviewed to take advantage of the primary keys
- For example: the function that calculates last value for a given itemid
- Zabbix Server syncer processes must nicely handle duplicate data without loss of data in case if a transaction that writes data to history fails
- Possible solution: if transaction fails due to "primary key violation" then we may split data into two chunks and retry, then repeat. Alternatively we may try to check for duplicates by selecting data from the database
- We must make sure that the new schema works fine with PostgreSQL, MySQL, MariaDB and Oracle and does not create any issues with existing partitioning schemas and TimescaleDB logic
- We must research benefits of using primary keys v.s. older schema and document findings at least for MySQL and PostgreSQL: performance gains, saving of disk space
- It must be done for a large data set
- caused by
-
-
- Closed
-
- causes
-
ZBX-20603 Typo in PK migration guide
-
- Closed
-
-
ZBX-22695 Message "query failed due to primary key constraint:" in history syncer process.
-
- Closed
-
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
(1 is duplicated by, 2 mentioned in)
