[dev.icinga.com #3326] ido2db dumps instance_id=0 to objects during upgrade of 1.7.2=>1.8.0 causing duplicates with different instance_id #1137
This issue has been migrated from Redmine: https://dev.icinga.com/issues/3326
Created by mfriedrich on 2012-10-22 15:41:34 +00:00
Updated by mfriedrich on 2012-10-22 15:49:26 +00:00
given the user provided debug dump from the conninfo table, this indicates that the normal operations on the provided version, as well as the instance_id which was queried within ido2db_db_hello() did work out properly.
so in that case, the config dump would have missed the initial hello handshake, and not using the selected idi->dbinfo.instance_id ... which is strange even enough.
Updated by mfriedrich on 2012-10-22 15:58:24 +00:00
i would suspect that the database upgrade was done the wrong way, like
the correct way of upgrading would be
though, a null value should not happen anyways. it might help to adjust the default instance_id not to be 0, but 1 in order to workaround possible wrong states during upgrades.
Updated by mfriedrich on 2012-10-23 17:46:39 +00:00
i cannot reproduce it.
1.) get 1.7.2 and install it, with the provided mysql.sql from scratch, fresh database, running 1 day to gather some
2.) upgrade the binaries to 1.8, import the db schema, restart ido2db and icinga
3.) query for tables with instance_id=0 - none.
in 2.) i've even tried to to actually stop ido2db, then do the sql upgrade run, start ido2db, restart icinga to let the config dumps run.
Updated by mfriedrich on 2012-11-02 23:27:50 +00:00
problem is likely, that at the stage during upgrade the db_hello fails within the db schema version check, bailing early, not retrieving a valid instance_id. but as a matter of fact, ido2db silently ignores reported errors, and continues to insert data. in order to solve that integrity problems, #3419 introduces a hard bail out if the db schema does not match in that case, causing ido2db to shutdown, as well as idomod to disconnect then.