🥇Stream-Konvertierung von Firebird 2.5 in das ODS12-Format (Firebird 3.0)

Jede Firebird-Version hat ihre eigene Version des Datenbankstrukturformats – O(n)D(isk)S(tructure). Bis einschließlich Version 2.5 konnte die Firebird-Engine mit ODS älterer Versionen arbeiten, d.h. Datenbanken älterer Versionen konnten mit der neuen Version geöffnet und im Kompatibilitätsmodus genutzt werden. Die Firebird-Engine 3.0 hingegen arbeitet ausschließlich mit Datenbanken in ihrer eigenen ODS-Version 12.0.

Um auf 3.0 zu migrieren, muss die Datenbank von 2.5 in das neue Format durch Backup/Wiederherstellung umgewandelt werden. Dabei setzen wir voraus, dass die Datenbank bereits für die Konvertierung vorbereitet wurde – d.h. die Metadaten und Abfragen wurden auf die Kompatibilität mit Firebird 3.0 geprüft.

Wenn man dem Standardansatz folgt, bedeutet dies, dass ein Backup in Version 2.5 erstellt, dann 3.0 installiert und anschließend eine Wiederherstellung durchgeführt werden muss. Dieses Verfahren ist akzeptabel, wenn genügend Zeit zur Verfügung steht, aber bei der Migration großer Datenbanken oder bei gleichzeitiger Migration mehrerer Dutzend Datenbanken, wenn die Zeit drängt, kann die stufenweise Umwandlung genutzt werden, die 30-40% schneller ist. Wie genau dies (unter Windows und Linux) durchgeführt wird, erfahren Sie im Folgenden.

Die Grundidee besteht darin, dass wir zur Beschleunigung eine Pipeline nutzen werden:

gbak -b … database25 stdout | gbak -c … stdin database30

Gbak von 2.5 erstellt ein Backup im linearen Format und leitet es an stdout weiter, das sofort über stdin von gbak von 3.0 aufgegriffen wird, um eine neue Datenbank zu erstellen.

Eine solche Pipeline muss unbedingt über den lokalen (Datei-)Zugriff organisiert werden, da der Netzwerkzugang (selbst über localhost) den Prozess erheblich verlangsamt.

Im Folgenden betrachten wir die Details für Windows und Linux.

Windows

Im Falle von Windows ist es am einfachsten, eine vollständig autonome Version von Firebird zu erstellen. Dazu nehmen wir das embed-Archiv von Firebird 2.5, benennen die Datei fbembedded.dll in fbclient.dll um, fügen aus dem Archiv der 'normalen' 2.5 die Tools gbak.exe und (optional) – isql.exe hinzu.

Firebird 3.0 verwendet eine einheitliche Version und erfordert keinerlei Anpassungen.

Die minimalste Variante (die keine Installation der Runtime-Bibliotheken VS2008/VS2010 auf dem Zielsystem benötigt) enthält folgende Dateien:

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll

30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

Ein erfahrener Administrator wird feststellen, dass in 2.5 die Dateien intl/fbintl.dll und intl/fbintl.conf nicht enthalten sind. Das ist tatsächlich der Fall, da gbak den Zeichensatz der Verbindung nicht verwendet und keine Daten zwischen den Zeich encodierungen konvertiert. Auf der 'Empfangsseite' von Firebird 3.0 sind diese Dateien jedoch notwendig, wenn Indizes erstellt werden.

In der firebird.conf wird empfohlen, für Firebird 3.0 Folgendes hinzuzufügen:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Zudem ist es wünschenswert, unterschiedliche Werte für IpcName für 2.5 und 3.0 festzulegen.

Bei der Auswahl anderer Parameterwerte in firebird.conf gehen wir von folgendem einfachen Grundsatz aus: Während des Datenübertragungsprozesses arbeitet gbak in einem Prozess mit 2.5 und in einem anderen mit 3.0, dann beendet 2.5 die Arbeit und 3.0 beginnt mit dem Aufbau der Indizes.

Um die Phase des Indexaufbaus in 3.0 zu beschleunigen, wird empfohlen, die Größe des Parameters TempCacheLimit auf etwa 40% des RAM zu erhöhen (sofern es sich um einen dedizierten Server handelt).

Wenn der Server beispielsweise 16 GB RAM hat, kann man einstellen:

TempCacheLimit=6G

Selbstverständlich kann ein solches Wert nur bei 64-Bit Firebird 3 eingestellt werden, da jeder 32-Bit-Prozess nicht mehr als 2 Gigabyte Speicher allokieren kann.

Bei 2.5 muss dieser Parameter nicht geändert werden – er kann ohnehin nicht mehr als 2 Gigabyte betragen, und bei der Sicherung hat er keinen Einfluss auf die Geschwindigkeit.

Vor der Durchführung der Operation müssen Sie sicherstellen, dass der Seiten-Cache im Datenbank-Header auf 0 gesetzt ist (Befehl gstat -h databasename, prüfen Sie die Zeile Page buffers).

Wenn der Cache eindeutig im DB-Header gesetzt ist, überschreibt er die Werte aus firebird.conf (und databases.conf in 3.0), was bei unangemessen hohen Werten zu übermäßigem Speicherverbrauch und Swapping führen kann.

Danach kopieren Sie die Dateien auf das Zielsystem.

Die Konvertierung erfolgt nach dem Stoppen des 'System'-Dienstes Firebird 2.5 über die Eingabeaufforderung mit erhobenen Rechten als lokaler Administrator (Beispiel):

set ISC_USER=Besitzer
"25/gbak" -z -b -g -v -st t -y 25.log database25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin database30

In diesem Beispiel wird der "schräge Slash" in Anführungszeichen verwendet (erlaubter 'Unix-Stil'), und das 'Caret' (Symbol '^') maskiert das Zeilenumbruchzeichen, was praktisch ist, wenn Sie lange Befehle eingeben. Die Option -st(atus) wurde in Firebird 2.5.8 eingeführt und ermöglicht es, die Protokolldaten zur Laufzeit des gbak-Prozesses aufzuzeichnen (weitere Einzelheiten finden Sie in der Dokumentation).

Linux

Unter Linux hängt Firebird 3 von der Bibliothek tommath ab. In CentOS (RHEL) finden Sie diese Bibliothek im EPEL-Repository; in Ubuntu (Debian) ist sie im System enthalten.

Für CentOS muss zunächst das EPEL-Repository aktiviert werden, bevor Sie fortfahren können.

yum install libtommath

Bei Ubuntu sind keine zusätzlichen Repositories erforderlich, jedoch werden in Ubuntu 16 und Ubuntu 18 unterschiedliche Paketversionen installiert – libtommath0 und libtommath1, jeweils.

Firebird 3.0 sucht nach tommath.so.0 und für Ubuntu 18 ist es zusätzlich erforderlich, einen Link (symlink) von tommath.so.0 auf tommath.so.1 zu erstellen. Dafür muss zunächst tommath.so.1 gefunden werden.

Der gesuchte Pfad in Ubuntu ist /usr/lib/x86_64-linux-gnu/, in anderen Debian-basierten Distributionen kann es jedoch anders sein.

Das zweite Problem besteht darin, dass bis einschließlich Firebird 3.0.1 kein einfacher Weg vorhanden war, zwei verschiedene Serverversionen zu installieren. Die Option „aus den Quellen mit dem gewünschten Präfix kompilieren“ betrachten wir aufgrund des relativ hohen Aufwands nicht.

Für Firebird 3.0.2 und höher wurde eine Erstellung mit –enable-binreloc realisiert und eine separate Option im Installer (-path Pfad).

Vorausgesetzt, die tommath-Bibliothek und, falls erforderlich, der symlink für tommath.so.0 sind im System installiert, können Sie das aktuelle (zum Zeitpunkt der Erstellung dieses Artikels) Firebird 3.0.4-Paket beispielsweise in /opt/fb3 installieren:

./install.sh -path /opt/fb3

Danach können Sie den Systemdienst Firebird stoppen und die laufende Konvertierung starten.

Beim Stoppen von Firebird ist zu beachten, dass die Firebird 2.5 Prozesse im Classic-Modus in der Regel von xinetd gestartet werden – daher muss entweder der Firebird-Dienst für xinetd deaktiviert oder xinetd vollständig gestoppt werden.

In der firebird.conf für 3.0 auf Linux müssen keine MaxUnflushed-Parameter gesetzt werden (diese funktionieren nur unter Windows) und die Einstellungen für Firebird 2.5 sollten nicht geändert werden.

Unter Linux ist der lokale (Dateizugriff) von Firebird 2.5 nicht äquivalent zur Embedded-Variante unter Windows – der Server 2.5 läuft im Prozess gbak (ohne Netzwerkkomponente), aber die Zugriffsrechte werden anhand der Benutzerdatenbank überprüft, was bedeutet, dass nicht nur ein Benutzername, sondern auch ein Passwort erforderlich ist:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … database25 stdout
|/opt/fb3/bin/gbak -c … stdin database30

Nach der erfolgreichen Konvertierung muss zuerst der "zusätzliche" Firebird 3.0 entfernt werden, dann der "hauptsächliche" Firebird 2.5, und erst danach sollte eine saubere Installation von Firebird 2.5 erfolgen – am besten aus dem standardmäßigen tar.gz-Installer und nicht über die Repositories, da die Versionen in den Repositories veraltet sein könnten.

Außerdem muss nach der Datenbankwiederherstellung unter Linux und der Neuinstallation überprüft werden, dass die neue Datenbank dem Benutzer firebird gehört.

Falls dies nicht der Fall ist, muss dies korrigiert werden.

chown firebird.firebird database

Zusammenfassung

Neben der Einsparung von Zeit und Speicherplatz hat die fortlaufende Konvertierung einen weiteren wichtigen Vorteil – die Umwandlung der Datenbank erfolgt ohne die Löschung der vorhandenen Firebird 2.5-Installation, was die Rückkehr bei einer misslungenen Konvertierung erheblich vereinfacht (häufig aufgrund von unzureichendem Speicherplatz oder unerwarteten Neustarts während des Migrationsprozesses).

Die Zeitersparnis ist darauf zurückzuführen, dass die "klassische" Konvertierung "Backup-Zeit" plus "Wiederherstellungszeit" beinhaltet. Die Wiederherstellung besteht aus zwei Teilen: dem Lesen der Daten aus der Backup-Datei und dem Erstellen des Index.

Bei der fortlaufenden Konvertierung ergibt sich die Gesamtzeit als "Backup-Zeit plus fünf bis zehn Prozent" und "Zeit für den Indexaufbau".

Die konkreten Ergebnisse hängen von der Struktur der Datenbank ab, aber im Durchschnitt liegt die Wiederherstellungszeit ungefähr bei der doppelten Backup-Zeit. Daher würde man, wenn man die Backup-Zeit als Einheit nimmt, für die "klassische Konvertierung" drei Zeiteinheiten und für die fortlaufende Konvertierung zwei Zeiteinheiten ansetzen. Zusätzlich kann die Zeit durch Erhöhung des TempCacheLimits weiter reduziert werden.

Insgesamt ermöglicht die fortlaufende Konvertierung in der Praxis eine Einsparung von 30-40% der Zeit im Vergleich zu sequentiellem Backup und Wiederherstellung.

Fragen?

Bitte senden Sie alle Fragen in die Kommentare oder kontaktieren Sie den Autor der Methode und Mitautor dieses Artikels — Vasily Sidorov, leitender Systemingenieur bei „iBase“, unter der E-Mail-Adresse bs at ibase ru.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?