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

[dev.icinga.com #5272] Ido2db should check if the db schema version is appropriate for it #1402

Closed
icinga-migration opened this issue Dec 6, 2013 · 5 comments
Milestone

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Dec 6, 2013

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

Created by mhoyer on 2013-12-06 09:00:33 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2014-01-03 17:10:12 +00:00)
Target Version: 1.11
Last Update: 2014-12-08 14:38:19 +00:00 (in Redmine)


Hello,

we try to automate our monitoring infrastructure deployment in a cld style. To increase resilience on updates change i would really like to have ido2db check it's database schema version on startup and terminate if it isn't appropriate for it. This would help a lot to get remembered that there is something to be done with the database. It would be simple to determine that something is wrong if the service stops working and there should also be a log message informing about the problem.

Kind regards
Marco

Changesets

2014-01-03 17:04:25 +00:00 by (unknown) 920eee9

IDOUtils: ido2db should check db schema on startup, and bail early on errors.

Requires an additional connection struct temporarly used only for the
initial startup routine, running the first db version check.

Refs #5272

2014-01-03 17:04:47 +00:00 by (unknown) 6bcd519

Merge branch 'feature/ido2db-startup-schema-check-5272' into next

Fixes #5272

2014-01-03 17:09:00 +00:00 by (unknown) cd1d7a0

Update Changelog.

Refs #5272
Refs #5324
Refs #5412
Refs #5406
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jan 3, 2014

Updated by mfriedrich on 2014-01-03 17:05:44 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Target Version set to 1.11

The log message already exists.

                                syslog(LOG_USER | LOG_INFO, "Error: Initial DB Handshake failed.  Disconnecting client...");

                syslog(LOG_USER | LOG_INFO, "Error: DB Version Check against %s database query failed! Please check %s database configuration and schema!", ido2db_db_settings.dbserver, ido2db_db_settings.dbserver);

The problem is the flow when such a connection attempt happens - after idomod sending a message, and not on daemon startup. All the database connectivity checks happen in the forked child which happens on idomod client connect. By simply terminating the client, a reconnect by idomod will again force the db schema version check. While this isn't essentially clean, it will attempt to flood the (sys)log with such messages indicating a re-occuring problem to the user.

An additional check on startup is required which uses its own idi struct for the initial schema version handshake.

imagine ~ # service ido2db restart
Stopping ido2db: done.
Starting ido2db: ERROR: DB Version Check failed! Please check mysql database configuration, schema and syslog for details! Bailing out ... done.
imagine ~ # echo $?
1
imagine ~ # tail /var/log/syslog

Jan  3 18:02:53 imagine ido2db: IDO2DB 1.11.0 (03-13-2014) Copyright(c) 2005-2008 Ethan Galstad, Copyright(c) 2009-2013 Icinga Development Team (https://www.icinga.org)
Jan  3 18:02:53 imagine ido2db: IDO2DB 1.11.0 starting... (PID=15640)
Jan  3 18:02:53 imagine ido2db: Successfully connected to mysql database
Jan  3 18:02:53 imagine ido2db: Error: DB Version 1.10.0 does not match needed schema version 1.11.0. Please check the upgrade docs!
Jan  3 18:02:53 imagine ido2db: ERROR: DB Version Check against mysql database query failed! Please check mysql database configuration and schema! Bailing out ...
Jan  3 18:02:53 imagine ido2db: Successfully disconnected from mysql database
Jan  3 18:02:53 imagine ido2db: Program shutdown... (PID=15640)

This renders the db version check obsolete on each client connection, therefore removing it.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jan 3, 2014

Updated by Anonymous on 2014-01-03 17:10:12 +00:00

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

Applied in changeset 6bcd519.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jan 6, 2014

Updated by mhoyer on 2014-01-06 10:48:33 +00:00

great solution!

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jan 6, 2014

Updated by mfriedrich on 2014-01-06 12:53:45 +00:00

  • Project changed from Core, Classic UI, IDOUtils to 18
  • Category changed from Other to 79

my late xmas gift ;-)

and it solves a long term headache notifying the user about upgrade requirements.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Dec 8, 2014

Updated by mfriedrich on 2014-12-08 14:38:19 +00:00

  • Project changed from 18 to Core, Classic UI, IDOUtils
  • Category changed from 79 to IDOUtils
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.