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
