The cause of the issue is the upgrade from version 5.0 to 6.0, On the web page, some alerts have actually been resolved, but they still appear on the dashboard. When checking the logs, the following error is occasionally reported:
[Z3008] query failed due to primary key constraint: [1062] Duplicate entry '2163748' for key 'event_recovery.PRIMARY'
It was found that the primary key of the event_recovery table is eventid, which is actually unique and non-repeating (and it also has r_eventid). Sometimes the r_eventid recorded in event_recovery table does not exist in the events table, and sometimes it exists but the corresponding objectid for eventid and r_eventid are different. This explains why this alert has not been resolved. An online post suggested rebuilding the events_recovery table and re-establishing the association with the primary keys in the events table. Although this seems to have resolved the issue, it resulted in a loss of some data, such as the recovery records for past faults.
1. I suspect that there is an issue with the logic used to generate recovery events, which has resulted in the disorder of data within the event_recovery table.
2. What conditions lead to the occurrence of such a phenomenon? It appears to be unpredictable without any discernible pattern.
Need some help!!!
[Z3008] query failed due to primary key constraint: [1062] Duplicate entry '2163748' for key 'event_recovery.PRIMARY'
It was found that the primary key of the event_recovery table is eventid, which is actually unique and non-repeating (and it also has r_eventid). Sometimes the r_eventid recorded in event_recovery table does not exist in the events table, and sometimes it exists but the corresponding objectid for eventid and r_eventid are different. This explains why this alert has not been resolved. An online post suggested rebuilding the events_recovery table and re-establishing the association with the primary keys in the events table. Although this seems to have resolved the issue, it resulted in a loss of some data, such as the recovery records for past faults.
1. I suspect that there is an issue with the logic used to generate recovery events, which has resulted in the disorder of data within the event_recovery table.
2. What conditions lead to the occurrence of such a phenomenon? It appears to be unpredictable without any discernible pattern.
Need some help!!!