Jede Version von Firebird hat ihre eigene Version des Formats der Datenbankstruktur â O(n)D(isk)S(tructure). Bis einschlieĂlich Version 2.5 konnte die Firebird-Engine mit ODS frĂŒherer Versionen arbeiten, das heiĂt, Datenbanken aus Ă€lteren Versionen konnten mit der neuen Version geöffnet und im KompatibilitĂ€tsmodus betrieben werden. Die Firebird-Engine 3.0 arbeitet jedoch nur mit Datenbanken in ihrer eigenen ODS-Version 12.0.
Um auf 3.0 zu wechseln, muss die Datenbank von 2.5 in das neue Format ĂŒber Backup/Restore konvertiert werden. SelbstverstĂ€ndlich gehen wir davon aus, dass die Datenbank zuvor fĂŒr die Konvertierung vorbereitet wurde â d.h. die Metadaten und Abfragen wurden auf die KompatibilitĂ€t mit Firebird 3.0 geprĂŒft.
Folgt man dem Standardansatz, bedeutet dies, dass man ein Backup in Version 2.5 durchfĂŒhren muss, dann 3.0 installieren und ein Restore durchfĂŒhren. Dieses Verfahren ist akzeptabel, wenn genĂŒgend Zeit vorhanden ist, aber bei der Migration groĂer Datenbanken oder der gleichzeitigen Migration mehrerer Dutzend Datenbanken, wenn die Zeit drĂ€ngt, kann man die Streaming-Konvertierung nutzen, die 30-40 % schneller ist. Wie genau das geht (unter Windows und Linux), lesen Sie unten.
Die Grundidee besteht darin, dass wir zur Beschleunigung eine Pipeline verwenden:
gbak -b ⊠database25 stdout | gbak -c ⊠stdin database30Gbak von 2.5 erzeugt ein Backup im linearen Format und leitet es an stdout weiter, das sofort ĂŒber stdin von gbak von 3.0 erfasst wird und eine neue Datenbank erstellt.
Eine solche Pipeline sollte unbedingt mit lokalem (Datei-)Zugriff organisiert werden, da der Netzwerkzugriff (selbst ĂŒber localhost) den Prozess erheblich verlangsamt.
Im Folgenden betrachten wir die Einzelheiten fĂŒr Windows und Linux.
Windows
Im Falle von Windows ist es am einfachsten, eine vollstĂ€ndig eigenstĂ€ndige Version von Firebird zu erstellen. Dazu verwenden wir , benennen die fbembed.dll in fbclient.dll um, fĂŒgen die aus dem Archiv der "normalen" Version 2.5 die Utility gbak.exe und (nicht zwingend) â isql.exe hinzu.
Firebird 3.0 verwendet und erfordert keine weiteren Anpassungen.
Die minimalste Variante (die keine Installation von Runtime-Bibliotheken VS2008/VS2010 auf dem Zielsystem erfordert) 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.dllEin erfahrener Administrator kann 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 Charset der Verbindung nicht nutzt und keine Daten zwischen Charsets konvertiert, jedoch sind diese Dateien auf der 'Empfangsseite' von Firebird 3.0 beim Erstellen von Indizes erforderlich.
In firebird.conf wird empfohlen, Folgendes fĂŒr Firebird 3.0 hinzuzufĂŒgen:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Es ist auch wĂŒnschenswert, einen unterschiedlichen Wert fĂŒr IpcName fĂŒr 2.5 und 3.0 festzulegen.
Bei der Auswahl der Werte anderer Parameter in firebird.conf gehen wir von einer einfachen Ăberlegung aus: In einem Prozess lĂ€uft gbak mit 2.5 und in einem anderen mit 3.0, dann beendet 2.5 seine Arbeit und 3.0 beginnt mit dem Aufbau der Indizes.
Um die Phase des Aufbaus von Indizes in 3.0 zu beschleunigen, wird empfohlen, die GröĂe des Parameters TempCacheLimit auf etwa 40 % RAM zu erhöhen (wenn es sich um einen dedizierten Server handelt, versteht sich).
Wenn der Server 16 GB RAM hat, kann man setzen
TempCacheLimit=6GNatĂŒrlich kann dieser Wert nur bei Firebird 3 mit 64 Bit gesetzt werden, da jeder 32-Bit-Prozess nicht mehr als 2 Gigabyte Speicher zuweisen kann.
Bei 2.5 muss dieser Parameter nicht geĂ€ndert werden â er kann ohnehin nicht gröĂer als 2 Gigabyte sein und hat keinen Einfluss auf die Geschwindigkeit beim Backup.
Vor der DurchfĂŒhrung der Operation muss ĂŒberprĂŒft werden, ob der Seiten-Cache im Header der Datenbank auf 0 gesetzt ist (Befehl gstat -h databasename, siehe Zeile Page buffers).
Wenn der Cache ausdrĂŒcklich im Header der DB festgelegt ist, ĂŒberschreibt er die Werte aus firebird.conf (und databases.conf in 3.0), und bei unangemessen hohen Werten kann dies zu ĂŒbermĂ€Ăigem Speicherverbrauch und Swapping fĂŒhren.
AnschlieĂend kopieren wir die Dateien auf das Zielsystem.
Die Konvertierung erfolgt nach dem Stoppen des 'System'-Dienstes Firebird 2.5 ĂŒber die Eingabeaufforderung mit erhöhten 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 database30In diesem Beispiel wird der 'schrĂ€ge' Slash in AnfĂŒhrungszeichen verwendet (erlaubter 'Unix-Stil'), und der 'Caret' (Symbol '^') maskiert das Zeilenwechselzeichen, was bei der Eingabe von langen Befehlen praktisch ist. Die Option -st(atus) wurde in Firebird 2.5.8 eingefĂŒhrt und ermöglicht es, Protokolldaten ĂŒber die Laufzeit des gbak-Prozesses zu erfassen (Details in der Dokumentation).
Linux
Unter Linux hÀngt Firebird 3 von der Bibliothek tommath ab. In CentOS (RHEL) befindet sich diese Bibliothek im EPEL-Repository, in Ubuntu (Debian) im System.
FĂŒr CentOS muss zuerst das EPEL-Repository aktiviert und erst dann gemacht werden
yum install libtommathFĂŒr Ubuntu mĂŒssen keine zusĂ€tzlichen Repositories hinzugefĂŒgt werden, aber in Ubuntu 16 und Ubuntu 18 werden unterschiedliche Paketversionen installiert â libtommath0 und libtommath1, entsprechend.
Firebird 3.0 sucht nach tommath.so.0 und fĂŒr Ubuntu 18 muss zusĂ€tzlich ein Link (symlink) von tommath.so.0 auf tommath.so.1 erstellt werden. Dazu muss zunĂ€chst tommath.so.1 gefunden werden.
Der gesuchte Pfad in Ubuntu ist /usr/lib/x86_64-linux-gnu/, aber in anderen Debian-basierten Distributionen kann es anders sein.
Das zweite Problem besteht darin, dass es bis Firebird 3.0.1 keinen einfachen Weg gab, zwei verschiedene Serverversionen zu installieren. Die Option âaus dem Quellcode mit dem benötigten PrĂ€fix kompilierenâ betrachten wir aufgrund ihres relativen Aufwands nicht.
FĂŒr Firebird 3.0.2 und höher wurde und eine separate Installationsoption (-path Pfad) implementiert.
Vorausgesetzt, die Bibliothek tommath und, falls nötig, der Symlink fĂŒr tommath.so.0 wurden zum System hinzugefĂŒgt, kann das aktuelle (zum Zeitpunkt der Erstellung dieses Artikels) Paket von Firebird 3.0.4 in beispielsweise /opt/fb3 installiert werden:
./install.sh -path /opt/fb3Danach kann der Systemdienst Firebird gestoppt und die laufende Konvertierung gestartet werden.
Beim Stoppen von Firebird muss beachtet werden, dass Prozesse von Firebird 2.5 im Classic-Modus normalerweise von xinetd gestartet werden â daher ist es erforderlich, entweder den Firebird-Dienst fĂŒr xinetd zu deaktivieren oder xinetd vollstĂ€ndig zu stoppen.
In firebird.conf fĂŒr 3.0 unter Linux mĂŒssen keine MaxUnflushed-Parameter angegeben werden (sie funktionieren nur unter Windows), und die Einstellungen von Firebird 2.5 dĂŒrfen nicht geĂ€ndert werden.
In Linux ist der lokale (Datei-)Zugriff von Firebird 2.5 nicht Ă€quivalent zur embedded-Variante unter Windows â der Server 2.5 wird im gbak-Prozess (ohne Netzwerkkomponente) laufen, aber die Zugriffsrechte werden ĂŒber die Benutzerdatenbank ĂŒberprĂŒft, was bedeutet, dass sowohl ein Login als auch ein Passwort erforderlich sein werden:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b ⊠datenbank25 stdout
|/opt/fb3/bin/gbak -c ⊠stdin datenbank30Nach erfolgreicher Konvertierung muss zuerst der âzusĂ€tzlicheâ Firebird 3.0 entfernt, dann der âhauptsĂ€chlicheâ Firebird 2.5 und erst danach eine Neuinstallation von Firebird 2.5 durchgefĂŒhrt werden â am besten ĂŒber den standardmĂ€Ăigen Installer tar.gz, nicht durch Repositories, da die Version in den Repositories möglicherweise veraltet ist.
AuĂerdem muss nach der Datenbankwiederherstellung auf Linux und der Neuinstallation ĂŒberprĂŒft werden, dass die neue Datenbank dem Benutzer firebird gehört.
Falls dies nicht der Fall ist, muss das geÀndert werden
chown firebird.firebird datenbankFazit
Neben der Zeit- und Platzeinsparung auf der Festplatte hat die kontinuierliche Konvertierung noch einen weiteren wichtigen Vorteil â die Datenbank wird ohne Löschung der vorhandenen Firebird 2.5 umgewandelt, was den Rollback bei einer fehlgeschlagenen Konvertierung (hĂ€ufig verursacht durch Platzmangel oder unerwartetes Neustarten wĂ€hrend des Migrationsprozesses) erheblich erleichtert.
Die Zeiteinsparung hÀngt damit zusammen, dass die "klassische" Konvertierung "Backup-Zeit" plus "Wiederherstellungszeit" umfasst. Die Wiederherstellung besteht aus zwei Teilen: dem Lesen der Daten aus der Backup-Datei und dem Erstellen des Indexes.
Bei der kontinuierlichen 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 betrĂ€gt die Wiederherstellungszeit etwa das Doppelte der Backup-Zeit. Daher, wenn man die Backup-Zeit als Einheit betrachtet, dauert die "klassische Konvertierung" drei Einheiten Zeit, die kontinuierliche Konvertierung â zwei Einheiten. Eine Erhöhung des TempCacheLimits hilft zusĂ€tzlich, die Zeit zu reduzieren.
Insgesamt ermöglicht die kontinuierliche Konvertierung in der Praxis eine Einsparung von 30-40% der Zeit im Vergleich zu nacheinander durchgefĂŒhrten Backups und Restaurierungen.
Fragen?
Bitte alle Fragen in den Kommentaren schreiben oder an den Autor der Methode und Mitautoren dieses Artikels â Wladimir Sidorov, Senior System Engineer bei "iBase", unter der Adresse bs at ibase ru senden.
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Welche Version von Firebird verwenden Sie?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 oder 1.0
16 Benutzer haben abgestimmt. 1 Benutzer hat sich enthalten.
Quelle: habr.com
