[dev.icinga.com #12435] Incremental updates for the IDO database

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/12435

Created by gbeutner on 2016-08-15 08:06:06 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2016-08-15 12:45:05 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-17 15:53:39 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

---

Changesets

2016-08-15 12:43:11 +00:00 by gbeutner 2e8d3d3

Implement support for incremental IDO updates

fixes #12435

---

Relations:

• relates #12435
• relates #12435
• relates #12435
• relates #12459

[icinga-migration]

Updated by gbeutner on 2016-08-15 10:53:33 +00:00

• Relates set to 12011

[icinga-migration]

Updated by gbeutner on 2016-08-15 10:56:55 +00:00

• Relates set to 8756

[icinga-migration]

Updated by gbeutner on 2016-08-15 11:00:52 +00:00

• Relates set to 10073

[icinga-migration]

Updated by gbeutner on 2016-08-15 12:45:05 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 2e8d3d3.

[icinga-migration]

Updated by jyoung15 on 2016-08-17 05:43:35 +00:00

I suspect you made a typo in lib/db_ido/dbobject.cpp. From the commit diff:

@@ -185,26 +253,25 @@ void DbObject::SendVarsConfigUpdate(void)
                        fields->Set("varvalue", value);
                        fields->Set("is_json", is_json);
                        fields->Set("config_type", 1);
-                       fields->Set("session_token", 0); /* DbConnection class fills in real ID */
                        fields->Set("object_id", obj);
                        fields->Set("instance_id", 0); /* DbConnection class fills in real ID */

-                       DbQuery query;
-                       query.Table = "customvariables";
-                       query.Type = DbQueryInsert | DbQueryUpdate;
-                       query.Category = DbCatConfig;
-                       query.Fields = fields;
+                       DbQuery query3;
+                       query3.Table = "customvariables";
+                       query3.Type = DbQueryInsert;
+                       query3.Category = DbCatConfig;
+                       query3.Fields = fields;

I believe it should be:

query3.Type = DbQueryInsert | DbQueryUpdate;

I suspect this is causing errors I am seeing:

critical/IdoMysqlConnection: Error "Duplicate entry '124-xxxxx' for key 'object_id_2'" when executing query "INSERT INTO icinga_customvariablestatus

If it was intended to remove the DbQueryUpdate I'll do more investigation on my side and submit a separate issue if necessary.

[icinga-migration]

Updated by gbeutner on 2016-08-17 06:17:40 +00:00

Can you attach a copy of your IDO queries for that session?

[icinga-migration]

Updated by gbeutner on 2016-08-17 06:31:32 +00:00

Also, the DbQueryInsert change was intentional. The two DELETEs right before that loop should take care of any existing rows in the customvariables/customvariablestatus tables. The only other query that affects the customvariablestatus table has DbQueryInsert / DbQueryUpdate (in DbObject::SendVarsStatusUpdate). However, "query3.Object = xxx" seems to be out of place there. I guess I'll do some testing. :P

[icinga-migration]

Updated by gbeutner on 2016-08-17 06:38:00 +00:00

I've submitted a new ticket for this: #12459 - we've definitely had this bug for quite a while now. It only seems to affect queries with type DbQueryInsert (as opposed to DbQueryInsert | DbQueryUpdate) which is why we haven't noticed this before.

[icinga-migration]

Updated by gbeutner on 2016-08-17 06:44:48 +00:00

• Relates set to 12459

[icinga-migration]

Updated by gbeutner on 2016-08-17 06:48:14 +00:00

After careful consideration I'm not sure whether that bug is related to your problem. I'd still like to see a copy of your queries. :)

[icinga-migration]

Updated by gbeutner on 2016-08-17 09:37:46 +00:00

I've been able to reproduce the problem once so far - even with the patch from #12459. Created another ticket for this: #12461

[icinga-migration]

Updated by jyoung15 on 2016-08-17 15:53:40 +00:00

With the latest commit I am no longer seeing this issue. I believe it was resolved in #12461. Thank You!