View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
2025 | RackTables | default | public | 2021-05-07 11:15 | 2021-05-23 23:47 |
Reporter | FGu | Assigned To | infrastation | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 0.21.5 | ||||
Summary | 2025: Upgrade 0.21.1 -> 0.21.5 fails upgrade query in 0.21.2 | ||||
Description | Similar as https://bugs.racktables.org/view.php?id=1999 but with different ID The following queries failed: INSERT INTO Chapter (`id`, `sticky`, `name`) VALUES (39,'no','UPS models') -- Duplicate entry '39' for key 'PRIMARY' INSERT INTO AttributeMap (`objtype_id`,`attr_id`,`chapter_id`) VALUES (12,2,39) -- Duplicate entry '12-2' for key 'objtype_id' tried solution from Bug#1999, didn't resolve the issue | ||||
Steps To Reproduce | Install 0.21.1 Upgrade to 0.21.5 | ||||
Additional Information | Before upgrade: SELECT * FROM Chapter WHERE name = 'UPS models'; Empty set (0.01 sec) After upgrade: SELECT * FROM Chapter WHERE name = 'UPS models'; +----+--------+------------+ | id | sticky | name | +----+--------+------------+ | 39 | no | UPS models | +----+--------+------------+ | ||||
Tags | No tags attached. | ||||
When exactly does the error happen? | |
right during the upgrade |
|
Thank you for confirming. This issue is different from 1999, the only similarity seems to be some local custom backporting of database changes that were made in post-0.21.1 releases. If you get the same result as below, these two error messages during the upgrade do not require any more troubleshooting. mysql> SELECT chapter_id FROM AttributeMap WHERE objtype_id = 12 AND attr_id = 2; +------------+ | chapter_id | +------------+ | 39 | +------------+ 1 row in set (0.00 sec) |
|
Unfortunately not: SELECT chapter_id FROM AttributeMap WHERE objtype_id = 12 AND attr_id = 2; +------------+ | chapter_id | +------------+ | 10049 | +------------+ 1 row in set (0.01 sec) Running the same statements you recommended in 1999 also didn't fix the issue: UPDATE Chapter SET name = 'UPS models custom' WHERE id = 10049; Query OK, 1 row affected (0.02 sec) Rows matched: 1 Changed: 1 Warnings: 0 INSERT INTO Chapter (`id`, `sticky`, `name`) VALUES (39,'no','UPS models'); ERROR 1062 (23000): Duplicate entry '39' for key 'PRIMARY' The database is rolled back to 0.21.1 again now so we can start all over again |
|
Thank you. One of the things I do not understand is what the pre-existing chapter 39 is. Please examine the output of these queries and confirm whether it stands for UPS hardware (you do not need to post the results here if you do not want to):mysql> SELECT name from Chapter WHERE id = 39; mysql> SELECT dict_key, dict_value FROM Dictionary WHERE chapter_id = 39; |
|
this is pre-upgrade: SELECT name from Chapter WHERE id = 39; Empty set (0.00 sec) SELECT dict_key, dict_value FROM Dictionary WHERE chapter_id = 39; Empty set (0.00 sec) so nothing at all |
|
This is an unexpected result: you should not be getting the first error from the "0.21.2" batch in the first place. Anyway, based on you latest comments please find the next steps to try below: 0. Be at the same point as the backup (before the upgrade). 1. Upgrade to 0.21.5 and confirm that the fist error from the problem description does not appear, and the second does. 2. Run the script from bug 1999 with CUSTOM_CID=10049 and confirm it does not print any errors. Let me know how it went. |
|
0 - done 1 - interestingly enough only the second error appeared even though the backup was the same as before the initial upgrade (screenshots were taken after a restore to confirm this bug wasn't a one time only thing). Anyway only the second line appeared now 2 - the script ran without errors but didn't print any output either if you want we can always have a session together |
|
Then to me it sounds like your database is consistent now and at 0.21.5. The dictionary should have exactly one "UPS models" chapter, if entries in the latter display any references to objects, you can look at the objects to confirm the UPS attribute has the expected values, and to apply any changes required. Also in the reports you can check that "data integrity" does not raise any issues. But other than that, the original problem looks solved. Please confirm before closing. |
|
sorry for the late reply, I didn't have time to check things in the last couple of days. I can confirm there is only one chapter of "UPS models" and the expected attributes match. The data integrity report currently shows the attached issues for the test system, our productive currently only show the Foreign Keys but I suspect that's because of the link management plugin. However both of them don't seem to indicate any issues with the UPS systems so I don't think it's related to the initial bug report. If you can point me in the right direction to solve these issues and learn how to interpret the data integrity report I'd really appreciate any input. Thank you! |
|
just to add: the prod system is still on 0.21.1 - still need to perform the restore to verify the missing triggers are not caused by the upgrade | |
Excuse me, I was busy. Thank you for confirming. The unknown foreign keys indeed belong to the link management plugin, so these are not a problem. The missing triggers are a problem. All four were introduced in release 0.20.7 (2014-03-03), so if that failed at the time, the database might have accumulated some inconsistent rows as a consequence. Some of these inconsistent rows would be highlighted in the integrity report if that was the case, but it is difficult to tell quickly if the report fully checks all related cases. In other words, lack of other warnings does not necessarily mean lack of associated issues. Regarding the best way of resolving this, you can learn the schema and the code if you want to do that yourself, but it would take quite a bit of work. I might be able to confirm the data consistency later, but please do not count on it. In any case, the missing triggers problem is not related to the original request and should be handled separately, so I am closing this request as resolved. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2021-05-07 11:15 | FGu | New Issue | |
2021-05-07 13:30 | infrastation | Note Added: 0004283 | |
2021-05-07 14:28 | FGu | Note Added: 0004285 | |
2021-05-07 14:28 | FGu | File Added: upgrade.PNG | |
2021-05-07 20:45 | infrastation | Note Added: 0004287 | |
2021-05-10 09:16 | FGu | Note Added: 0004289 | |
2021-05-10 19:18 | infrastation | Note Added: 0004291 | |
2021-05-10 19:18 | infrastation | Assigned To | => infrastation |
2021-05-10 19:18 | infrastation | Status | new => assigned |
2021-05-11 07:03 | FGu | Note Added: 0004293 | |
2021-05-11 19:24 | infrastation | Note Added: 0004295 | |
2021-05-12 08:25 | FGu | Note Added: 0004297 | |
2021-05-12 11:36 | infrastation | Note Added: 0004299 | |
2021-05-17 09:45 | FGu | Note Added: 0004301 | |
2021-05-17 09:45 | FGu | File Added: integrity.PNG | |
2021-05-17 09:47 | FGu | Note Added: 0004303 | |
2021-05-23 23:47 | infrastation | Note Added: 0004305 | |
2021-05-23 23:47 | infrastation | Status | assigned => closed |
2021-05-23 23:47 | infrastation | Resolution | open => no change required |