[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

[icinga-migration]

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

Assignee: (none)
Status: Closed (closed on 2012-11-09 17:44:49 +00:00)
Target Version: (none)
Last Update: 2014-12-08 14:37:54 +00:00 (in Redmine)

Icinga Version: 1.10.0
OS Version: any

---

---

Relations:

• relates #3419

[icinga-migration]

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.

(44,1,'IDO2DB Trimming Thread','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 18:31:00','0000-00-00 00:00:00','2012-10-19 18:31:00','2012-10-19 18:31:00','0000-00-00 00:00:00',0,0,0),
(45,1,'IDOMOD','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 19:29:28','2012-10-19 19:30:15','2012-10-19 19:30:15','2012-10-19 19:29:28','2012-10-19 19:30:15',114367,12469,300),
(46,1,'IDOMOD','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 19:30:15','2012-10-19 19:45:03','2012-10-19 19:45:03','2012-10-19 19:30:15','2012-10-19 19:45:03',233566,28281,846),
(47,1,'IDO2DB Trimming Thread','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 19:35:15','0000-00-00 00:00:00','2012-10-19 19:35:15','2012-10-19 19:35:15','0000-00-00 00:00:00',0,0,0),
(48,1,'IDOMOD','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 19:45:03','2012-10-22 14:54:34','2012-10-22 14:54:34','2012-10-19 19:45:03','2012-10-22 14:54:34',36004309,4648118,160170),
(49,1,'IDO2DB Trimming Thread','1.7.2','REALTIME','UNIXSOCKET','INITIAL','2012-10-19 19:50:03','0000-00-00 00:00:00','2012-10-19 19:50:03','2012-10-19 19:50:03','0000-00-00 00:00:00',0,0,0),
(50,1,'IDOMOD','1.8.0','REALTIME','UNIXSOCKET','RECONNECT','2012-10-22 15:13:41','2012-10-22 15:13:47','2012-10-22 15:13:47','2012-10-22 15:13:41','2012-10-22 15:13:47',8474,1019,35),
(51,1,'IDOMOD','1.8.0','REALTIME','UNIXSOCKET','INITIAL','2012-10-22 15:13:49','0000-00-00 00:00:00','2012-10-22 15:13:49','2012-10-22 15:13:49','0000-00-00 00:00:00',356,23,0),
(52,1,'IDOMOD','1.8.0','REALTIME','UNIXSOCKET','RECONNECT','2012-10-22 15:14:19','0000-00-00 00:00:00','2012-10-22 15:17:31','2012-10-22 15:14:19','0000-00-00 00:00:00',56519,6981,197);

[icinga-migration]

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

1. upgrade the binaries
2. restart the binaries (line 50)
3. import the db sqls while running (that would explain line 51, causing a lock on the db, dropping ido2db out)
4. reconnect function call after the db connection was re-established

the correct way of upgrading would be

1. stop icinga, stop ido2db
2. upgrade the binaries
3. upgrade db schema
4. start ido2db, start icinga

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.

[icinga-migration]

Updated by mfriedrich on 2012-10-23 17:46:39 +00:00

i cannot reproduce it.

• debian 6.0.6 x64

• mysql version

  mysql> select version();
  +-------------------+
  | version() |
  +-------------------+
  | 5.1.63-0+squeeze1 |
  +-------------------+
  1 row in set (0.01 sec)

• libdbi

  dpkg -l libdbi

  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name Version Description
  +++-================================================================-================================================================-================================================================================================================================================
  ii libdbi-perl 1.612-1 Perl Database Interface (DBI)
  ii libdbi0 0.8.2-3 Database Independent Abstraction Layer for C
  ii libdbi0-dev 0.8.2-3 DB Independent Abstraction Layer for C -- development files

  dpkg -l libdbd

  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name Version Description
  +++-================================================================-================================================================-================================================================================================================================================
  un libdbd-anydata-perl (no description available)
  un libdbd-csv-perl (no description available)
  ii libdbd-mysql 0.8.2-1-4.1+b1 MySQL database server driver for libdbi
  ii libdbd-mysql-perl 4.016-1 Perl5 database interface to the MySQL database
  ii libdbd-pgsql 0.8.2-1-4.1+b1 PostgreSQL database server driver for libdbi
  un libdbd-sqlite (no description available)
  ii libdbd-sqlite3-perl 1.29-3 Perl DBI driver with a self-contained RDBMS

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.

mysql> select * from icinga_objects where instance_id!=1;
Empty set (0.00 sec)

mysql> select * from icinga_servicestatus where instance_id!=1;
Empty set (0.00 sec)

mysql> select * from icinga_services where instance_id!=1;
Empty set (0.00 sec)

mysql> select * from icinga_instances;
+-------------+---------------+----------------------+
| instance_id | instance_name | instance_description |
+-------------+---------------+----------------------+
|           1 | icinga-dev    |                      |
+-------------+---------------+----------------------+
1 row in set (0.00 sec)

[icinga-migration]

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.

[icinga-migration]

Updated by mfriedrich on 2012-11-09 17:44:49 +00:00

• Status changed from New to Closed

fixed in #3419

[icinga-migration]

Updated by mfriedrich on 2014-12-08 14:37:54 +00:00

• Project changed from 18 to Core, Classic UI, IDOUtils
• Category set to IDOUtils
• Icinga Version changed from 1 to 1
• OS Version set to any