Details
-
Type:
Problem report
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.4.8rc1, 4.0.0alpha4, 4.0 (plan)
-
Component/s: Proxy (P), Server (S)
-
Team:Team A
-
Sprint:Sprint 28
-
Story Points:0.5
Description
This is followup of ZBX-12758, you can find more details in last comment.
The change in 3.4.6 has added an index create index problem_3 on problem (r_eventid), schema.tmpl was updated too.
Background:
"problem" table, introduced in 3.2, has c_problem_2 constraint, which automatically adds an `c_problem_2` (`r_eventid`) index on MySQL db backend.
What interesting I discovered is:
if zabbix database was existing from a moment, when "problem" table was created together with the constraint, then the existing index c_problem_2 will be magically "renamed" to problem_2, which is attempted to be created.
But, if once after upgrade to 3.2, I had to dump and restore my zabbix database - the attempt to create the new index will be done "as is", and I'll get two identical indexes - c_problem_2 and problem_2.
This is not very good.
It's suggested to improve the patch logic to in a way to rename existing index.
And probably remove the c_problem_2 index for those, who already upgraded to 3.4.6.