Skip to content
This repository has been archived by the owner. It is now read-only.

[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

Closed
icinga-migration opened this issue Oct 22, 2012 · 6 comments

Comments

Projects
None yet
1 participant
@icinga-migration
Copy link
Member

commented Oct 22, 2012

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:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Oct 22, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Oct 22, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Oct 23, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Nov 2, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Nov 9, 2012

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

  • Status changed from New to Closed

fixed in #3419

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Dec 8, 2014

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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.