Primary keys in history tables, backward compatible?

[mterrero]

Hello

I'm sorry if this was asked before, I've searched the forums but I didn't found this question.

I'd like to know if the primary keys that are now part of the history table's schemas, introduced in the release 6, are backward compatible. We're currently running the the 5.4 release.

Thnaks in advance.

Regards,
Miguel

[splitek]

Zabbix 6.0 will work without primary keys in those tables after DB upgrade.
If you want them then you must do a manual changes in DB. doc: https://www.zabbix.com/documentation...b_primary_keys

[mterrero]

Hi

Thanks for your answer.

Yes, I know that, but I'm interested in having them in our current release, as long as our data (repeated tuples for itemid & clock & ns columns) allows that.

Regards.

[daftu]

Same here. I want to prepare my 5.4 database (which is PostgreSQL 11 with partitions) to migrate to 6.0, but I'd wait with migration until 6.0.1 or sth.
So I'll be migrating to PostgreSQL13, removing partitioning and turning into TimescaleDB. This is a good occasion to turn on the PRIMARY KEYS at once, but will it be compatible with 5.4?

[daftu]

I'll answer myself
I've enabled PRIMARY KEY (migrated all data from old history* tables to new with PRIMARY KEY) running Zabbix 5.4. Everything seems working fine so far, so it doesn't affect previous version (no errors or performance issues) and is fully prepared for new 6.0 in the future. I'll let know if something'll happen.

[mterrero]

Thanks a lot for your response!

[mterrero]

Hi

I've tested the primary keys in a 5.4 with no errors so far, in a small testitng box.

When I force a primary key insert error, as zabbix inserts the data in sets of n values (100 or more), when this duplicate error raises, the transaction is rolled back and all the data is lost.

I'd like to know if the version 6 handles this errors differently. I haven't found any info about this respect.

Regards,
Miguel