Es mag einen Bug im Datenbankschema geben, der behoben wurde. Wenn Sie eine ältere IDOUtils-Version aktualisieren, dann müssen Sie außerdem diese Anpassungen manuell ausführen. Wenn Sie rpm/deb-Pakete benutzen, lesen Sie bitte die Hinweise und/oder fragen Sie den Maintainer, ob er diese Anpassungen in der Installationsroutine hinzugefügt hat.
Die Update-Dateien finden Sie zusammen mit den Datenbank-Installationsdateien in
/path/to/icinga-src/module/idoutils/db/DeineDB/
Die Syntax ist wie folgt
<rdbm>-upgrade-<version>.sql
wobei <rdbm> mysql, pgsql oder oracle sein kann und <version> zeigt auf die Version, auf die Sie aktualisieren wollen.
![]() |
Anmerkung |
---|---|
Wenn Sie eine ältere Version aktualisieren wollen und zwischen dieser und der aktuellen noch andere Versionen liegen, dann sollten Sie beachten, dass Sie auch die dazwischen liegenden Updates inkrementell installieren müssen! |
Sie haben z.B. 1.0RC1 installiert und möchten auf 1.0.1 aktualisieren - Sie müssen dann zuerst auf 1.0 Stable updaten und dann die Aktualierung auf 1.0.1 durchführen.
Sichern Sie Ihre aktuelle Datenbank vor der Aktualisierung!
Prüfen Sie die laufende IDOUtils-Version und die Zielversion. Prüfen Sie, ob zwischen diesen beiden Versionen noch andere Versionen liegen und aktualisieren Sie ggf. schrittweise.
Führen Sie die Aktualisierung(en) mit einem Benutzer durch, der über die notwendigen Berechtigungen verfügt. Sie können das upgradedb-Script verwenden, aber das wird nicht empfohlen (betrifft nur MySQL).
MySQL:
$ mysql -u root -p <dbname> < /path/to/icinga-src/module/idoutils/db/mysql/mysql-upgrade-<version>.sql
PostgreSQL:
# su - postgres $ psql -U icinga -d icinga < /path/to/icinga-src/module/idoutils/db/pgsql/pgsql-upgrade-<version>.sql
Oracle:
# su - oracle $ sqlplus dbuser/dbpass SQL> @oracle-upgrade-<version>.sql
Aktualisieren der IDOUtils auf 1.0.2
Es gab einen signifikanten Bug in den IDOUtils, der erst in Icinga 1.0.2 bereinigt werden konnte.
Bei jedem Core Restart wurde die gesamte Menge an Objekten in der Objekttabelle erneut hinzugefuegt, anstelle die alten weiterhin zu verwenden und wie Relationen auf den neuesten Stand zu bringen.
Beispielsweise bei 4000 Objekten (Hosts, Services, Contacts, etc) hat ein zweimaliger Core Restartet 4000+4000+4000 = 12000 Objekte bedeutet.
In Bezug auf die Konfiguration und die Statusdaten ist dies nicht relevant, da deren Relationen zur Objekttabelle bei jeden Neustart bereinigt werden.
Historische Daten allerdings behalten diese unterschiedliche Beziehung zur Objekttabelle bei - vor und nach dem Restart sind die Relationen unterschiedlich.
Diese Dateninkonsistenz ist natürlich nicht wünschenswert und es wurde dementsprechend versucht, eine einfache Lösungsmöglichkeit zu finden.
Neben den normale SQL Scripts für 1.0.2 (z.B. mysql-upgrade-1.0.2.sql) stehen erweiterte SQL Scripts zur Verfügung.
Das Script arbeitet jeweils auf einer historischen Tabelle und holt sich mit Hilfe einer gestaffelten Query die notwendigen Daten aus den beiden Tabellen - historisch 1..1 Objekte. Desweiteren werden kaputte Eintraege zur Zeit des Restarts bereinigt.
Bitte verwenden Sie diese Scripts wie Sie möchten - wahlweise direkt ausgeführt oder Schritt für Schritt, wie der Ablauf innerhalb des Scripts ist. Beachten Sie allerdings bitte, dass diese Scripts ohne Garantie auf ihr eigenes Risiko verwendet werden können.
Falls Sie lediglich Livedaten verwenden, ist unter Umständen eine Neuinstallation des Datenbankschemas die einfachere Option.
* <rdbms>-upgrade-1.0.2-fix-object-relations.sql
Das "normale" Upgrade Script ist in 1.0.2 nur für MySQL verfügbar. Es wurden binäre Casts entfernt, da case sensistives Vergleichen auch mit einer Anpassung der Collation erreicht werden kann und so massive Performanceeinbrüche verhindert werden können.
* mysql-upgrade-1.0.2.sql
Aktualisieren der IDOUtils auf 1.0.1
Bitte vergewissern Sie sich, dass Sie bereits auf Icinga IDOUtils 1.0 aktualisiert haben, bevor Sie diesen Abschnitt weierlesen! Es gab einige (große) Veränderungen für alle unterstützten RDBMS, deshalb lesen Sie diesen Abschnitt bitte sehr sorgfältig. Alle Datenbank- Skripte sind nun in entsprechenden Unterverzeichnissen zu finden. Für alle RDBMS wurden mehr Indizes gesetzt, außerdem wurde die Größe der command_line Spalte in mehreren Tabellen, die 255 Zeichen überschritten, angepasst.
RDBMS spezifische Änderungen und HowTo's:
MySQL:
Änderung der Datenbank- Engine von MYISAM zu InnoDB. Der Grund ist die Umgehung von Zeilen- Sperren/Transaktionen/Rollbacks im Gegensatz zu einer kleinen Geschwindigkeitseinbuße während der Inserts.
Das Upgrade-Skript führt eine ALTER TABLE- Anweisung aus. Falls ihnen diese Idee nicht gefällt, können Sie auch folgendes tun:
Dump erstellen der existierenden Datenbank:
# mysqldump -u root -p icinga > icinga.sql
Ändern Sie alle Einträge von "MYISAM" zu "InnoDB"
Import des angepassten Datensatzes in eine neue Datenbank (wenn Sie die alte Datenbank verwenden möchten, löschen Sie als erstes den originalen Datensatz und rekreieren Sie die Datenbank).
PostgreSQL:
Der Tabelle systemcommands fehlte die Spalte der Namens Ausgabe. Diese wird während des Upgrades hinzugefügt.
Oracle:
Um die Performance in mehreren Bereichen zu verbessern, muß der Wert für open_cursors höher gesetzt werden (Standardwert ist 50). Das Aktualisierungsskript enthält zwei neue, in DML geschriebene, Prozeduren für die DELETE- Anweisungen.
Darüber hinaus gab es umfangreiche Änderungen bezüglich der Autoincrement- Sequenz und der AFTER INSERT- Trigger (Emulation des MySQL Autoincrement auf Primärschlüssel). Die alte Routine wurde komplett verworfen, d.h. alle Trigger und die Autoincrement- Sequenz werden während des Updates entfernt. Als Ersatz werden für jede Tabelle neue Sequenzen hinzugefügt und in den IDOUtils für Oracle verwendet.
Bei bestehenden Datensätzen wird dies beim Importieren zu Problemen führen. Die Sequenzen starten mit dem Wert 1 wo hingegen der primäre Key (id) einen Maximalwert gesetzt hat. Aus diesem Grund wird eine Basisfunktion bereitgestellt, die das folgende tut: Diese extrahiert den maximalen Wert der id plus eins aus der angegebenen Tabelle und verändert den jeweiligen Sequence Start auf diesen berechneten Wert.
Bitte verwenden Sie diese Prozedur so, wie Sie es benötigen - auf alle Tabellen und Sequenzen oder auf separierte Teile. Die Prozedur ist auskommentiert, und wird ohne Garantie auf Datenkonsistenz zur Verfügung gestellt. Ziehen Sie Ihren DBA zu Rate, wenn Sie bestehende Datensätze importieren wollen.
Aktualisieren der IDOUtils auf 1.0
Es gab einen Unique-Key-Fehler durch den Fork, der bei einigen Tabellen zu doppelten und nutzlosen Zeilen führt. Dies betrifft die folgenden Tabellen:
timedevents, timedeventqueue
servicechecks
systemcommands
Wenn Sie sich z.B. Definition der Tabelle servicechecks ansehen:
mysql> show create table icinga_servicechecks;
sollten Sie etwa folgendes sehen
PRIMARY KEY (`servicecheck_id`), KEY `instance_id` (`instance_id`), KEY `service_object_id` (`service_object_id`), KEY `start_time` (`start_time`)
Um die o.g. Definition zu etwas wie diesem
PRIMARY KEY (`servicecheck_id`), UNIQUE KEY `instance_id` (`instance_id`,`service_object_id`,`start_time`,`start_time_usec`)
zu ändern, befolgen Sie bitte den folgenden Ablauf!
Wenn Sie von IDOUtils 1.0RC aktualisieren, dann benutzen Sie bitte module/idoutils/db/mysql/mysql-upgrade-1.0.sql - wenn Sie von einer älteren Version aktualisieren, dann führen Sie vorher die notwendigen Schritte durch, um auf 1.0RC zu aktualisieren!
Bitte sichern Sie Ihre Datenbank und stoppen Sie ido2db vor der Ausführung des Patches!
/etc/init.d/ido2db stop
mysql -u root -p icinga < /path/to/icinga-src/module/idoutils/db/mysql/mysql-upgrade-1.0.sql
Der Patch erledigt das Folgende mit Hilfe von MySQL-Befehlen:
hinzufügen einer temporären Spalte 'active', um die aktualisierte Zeile zu kennzeichnen
ermitteln der benötigten Informationen zweier doppelter Zeilen basierend auf dem unique contraint, aktualisieren der zweiten Zeile und markieren durch first=inactive, second=active
löschen aller als 'inactive' gekennzeichneten Zeilen
entfernen der fehlerhaften Key-Definitionen
hinzufügen des Unique Key
entfernen der temporären Spalte 'active'
Diese Prozedur wird für jede Tabelle durchgeführt, so dass es eine Weile dauern kann, abhängig von Ihren Tabellengrößen und/oder DB-Spezifikationen.
Falls Sie vorher etwas an den Keys verändert haben, dann stellen Sie sicher, dass Sie das gleiche DB-Schema wie in IDOUtils 1.0RC benutzen, andernfalls wird das Script fehlschlagen.
© 2009-2010 Icinga Development Team, http://www.icinga.org