Conversion en continu des bases Firebird 2.5 au format ODS12 (Firebird 3.0)

Chaque version de Firebird a sa propre version du format des structures de disque de la base de données – O(n)D(isk)S(tructure). Jusqu'à la version 2.5 incluse, le moteur Firebird pouvait travailler avec des ODS des versions précédentes, ce qui signifie que les bases de données anciennes pouvaient être ouvertes par la nouvelle version tout en fonctionnant en mode de compatibilité, mais le moteur Firebird 3.0 ne fonctionne qu'avec des DB dans sa propre version ODS 12.0.

Pour passer à 3.0, la base de données de 2.5 doit être convertie au nouveau format via backup/restore. Bien sûr, nous supposons que la DB a été préparée pour la conversion, c'est-à-dire que les métadonnées et les requêtes ont été vérifiées pour leur compatibilité avec Firebird 3.0.

Si nous suivons l'approche standard, cela signifie qu'il faut faire une sauvegarde sur la version 2.5, puis installer 3.0 et faire un restore. Cette procédure est acceptable si l'on dispose de suffisamment de temps, mais lors de la migration de grandes bases de données, ou lors de la migration simultanée de plusieurs dizaines de DB, quand le temps presse, il est possible de recourir à la conversion en continu, qui est 30 à 40 % plus rapide. Pour savoir comment faire cela (sous Windows et sous Linux), lisez la suite.

L'idée générale est que nous allons utiliser un pipeline pour accélérer le processus :

gbak -b … base25 stdout | gbak -c … stdin base30

Gbak 2.5 génère une sauvegarde au format linéaire et l'envoie dans stdout, qui est immédiatement récupéré par gbak 3.0 via stdin, créant ainsi une nouvelle DB.

Il est impératif d'organiser ce pipeline avec un accès local (fichiers), car l'accès réseau (même via localhost) ralentira considérablement le processus.

Ci-dessous, nous examinons les détails pour Windows et Linux.

Windows

Dans le cas de Windows, il est plus simple de réaliser une compilation complètement autonome de Firebird. Pour cela, nous prenons l'archive embed de Firebird 2.5, renommant fbemded.dll en fbclient.dll, en ajoutant depuis l'archive « normale » 2.5 les utilitaires gbak.exe et (facultativement) – isql.exe.

Firebird 3.0 utilise une seule compilation et ne requiert aucun ajustement.

La variante minimale (ne nécessitant pas l'installation des bibliothèques runtime VS2008/VS2010 sur le système cible) contient les fichiers suivants :

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

Un administrateur expérimenté peut remarquer que les fichiers intl/fbintl.dll et intl/fbintl.conf ne sont pas inclus dans la version 2.5. C'est en effet le cas, car gbak n'utilise pas le charset de connexion et ne convertit pas les données entre les charsets, mais du côté 'réception' de Firebird 3.0, ces fichiers sont nécessaires lors de la création d'index.

Dans firebird.conf, il est recommandé d'ajouter pour Firebird 3.0 :

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Il est également souhaitable d'installer une valeur différente pour IpcName pour 2.5 et 3.0.

Lors du choix des valeurs d'autres paramètres de firebird.conf, nous partons d'une simple considération : au stade du transfert de données, dans un processus gbak fonctionne en 2.5, et dans un autre – en 3.0, ensuite 2.5 termine son travail, tandis que 3.0 commence à construire les index.

Pour accélérer la phase de construction des index dans 3.0, il est recommandé d'augmenter la taille du paramètre TempCacheLimit à environ 40% de la RAM (si c'est un serveur dédié, bien sûr).

Par exemple, si le serveur a 16 Go de RAM, on peut définir

TempCacheLimit=6G

Bien entendu, une telle valeur ne peut être définie que pour Firebird 3 en 64 bits, car tout processus en 32 bits ne peut pas allouer plus de 2 Go de mémoire.

Pour 2.5, ce paramètre n'a pas besoin d'être modifié – il ne peut pas être supérieur à 2 Go de toute façon, et cela n'affecte pas la vitesse lors de la sauvegarde.

Avant d'exécuter l'opération, il est nécessaire de vérifier que le cache de pages dans l'en-tête de la base de données est réglé à 0 (commande gstat -h databasename, voir la ligne Page buffers).

Si le cache est défini explicitement dans l'en-tête de BD, il écrase les valeurs de firebird.conf (et databases.conf dans 3.0), et en cas de valeurs excessivement élevées, cela peut entraîner une consommation excessive de mémoire et un passage en swap.

Ensuite, copiez les fichiers sur le système cible.

La conversion s'effectue après l'arrêt du service 'système' Firebird 2.5, dans la ligne de commande avec élévation des droits au niveau d'administrateur local (exemple) :

set ISC_USER=propriétaire
"25/gbak" -z -b -g -v -st t -y 25.log base25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin base30

Dans cet exemple, une 'barre oblique directe' entre guillemets est utilisée (style 'unix' valide), et le 'chapeau' (symbole '^') échappe le caractère de retour à la ligne, ce qui est pratique lors de la saisie de longues commandes. L'option -st(atus) est apparue dans Firebird 2.5.8 et permet d'enregistrer dans le journal des données sur la durée d'exécution du processus gbak (détails dans la documentation).

Linux

Sous Linux, Firebird 3 dépend de la bibliothèque tommath. Dans CentOS (RHEL), cette bibliothèque se trouve dans le dépôt epel, dans Ubuntu (Debian) dans le dépôt système.

Pour CentOS, il est nécessaire de connecter d'abord le dépôt epel, puis de faire

yum install libtommath

Pour Ubuntu, il n'est pas nécessaire de connecter des dépôts supplémentaires, mais dans Ubuntu 16 et Ubuntu 18, différentes versions des paquets sont installées – libtommath0 et libtommath1, respectivement.

Firebird 3.0 recherche tommath.so.0 et pour Ubuntu 18, il est également nécessaire de créer un lien (symlink) de tommath.so.0 vers tommath.so.1. Pour cela, il faut d'abord localiser tommath.so.1.

Le chemin recherché dans Ubuntu est /usr/lib/x86_64-linux-gnu/, mais dans d'autres distributions basées sur Debian, cela peut être différent.

Le deuxième problème est que jusqu'à Firebird 3.0.1 inclusivement, il n'y avait pas de moyen simple d'installer deux versions différentes du serveur. Nous ne considérons pas l'option « compiler à partir des sources avec le préfixe approprié » en raison de sa relative complexité.

Pour Firebird 3.0.2 et supérieur, une compilation avec –enable-binreloc et une option séparée dans l'installateur (-path chemin) ont été mises en œuvre.

En supposant que la bibliothèque tommath et, si nécessaire, le symlink pour tommath.so.0 ont été ajoutés au système, on peut procéder à l'installation de la distribution actuelle (au moment de la rédaction de cet article) de Firebird 3.0.4 dans, par exemple, /opt/fb3 :

./install.sh -path /opt/fb3

Après cela, on peut arrêter le service système Firebird et lancer la conversion en continu.

Lors de l'arrêt de Firebird, il faut prendre en compte que les processus Firebird 2.5 en mode Classic sont généralement lancés par xinetd – il est donc nécessaire soit d'interdire le service firebird pour xinetd, soit d'arrêter xinetd complètement.

Dans firebird.conf pour 3.0 sur Linux, il n'est pas nécessaire de définir les paramètres MaxUnflushed (ils ne fonctionnent que sur Windows) et de modifier les réglages de Firebird 2.5.

Sous Linux, l'accès local (fichier) de Firebird 2.5 n'est pas équivalent à une version intégrée sous Windows – le serveur 2.5 fonctionnera dans le processus gbak (sans partie réseau), mais les droits d'accès seront vérifiés selon la base d'utilisateurs, ce qui signifie qu'il faudra non seulement un identifiant, mais aussi un mot de passe :

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

Après une conversion réussie, il faut d'abord supprimer le Firebird 3.0 « supplémentaire », puis le Firebird 2.5 « principal » et enfin effectuer une installation propre de Firebird 2.5 – de préférence depuis l'installateur standard tar.gz, et non via les dépôts, car la version dans les dépôts peut être obsolète.

De plus, après la restauration de la BDD sur Linux et la réinstallation, il faut s'assurer que la nouvelle BDD ait pour propriétaire l'utilisateur firebird.

Si ce n'est pas le cas, il faudra corriger

chown firebird.firebird database

Conclusion

En plus de faire gagner du temps et d'économiser de l'espace disque, la conversion cohérente présente un autre avantage important : la transformation de la base se fait sans supprimer l'existant Firebird 2.5, ce qui facilite considérablement le retour en arrière en cas d'échec de la conversion (généralement dû à un manque d'espace ou à un redémarrage imprévu pendant le processus de migration).

Le gain de temps est lié au fait que la conversion « classique » implique le « temps de sauvegarde » plus le « temps de restauration ». La restauration se compose de deux parties : la lecture des données à partir du fichier de sauvegarde et la construction de l'index.

Avec la conversion cohérente, le temps total est équivalent à « le temps de sauvegarde plus cinq à dix pour cent » et à « le temps de construction des index ».

Les résultats spécifiques dépendent de la structure de la base, mais en moyenne, le temps de restauration est environ le double du temps de sauvegarde. Par conséquent, si l'on considère le temps de sauvegarde comme une unité, la conversion « classique » prend trois unités de temps, tandis que la conversion cohérente n'en prend que deux. Une augmentation de TempCacheLimit peut également aider à réduire le temps.

Dans l'ensemble, la conversion cohérente permet de gagner en pratique 30 à 40 % du temps par rapport à une sauvegarde et une restauration séquentielles.

Des questions ?

Veuillez poser toutes vos questions dans les commentaires ou les adresser à l'auteur de la méthode et co-auteur de cet article — Vasily Sidorov, ingénieur système senior chez « iBase », à l'adresse bs at ibase ru.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Quelle version de Firebird utilisez-vous ?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 ou 1.0

16 utilisateurs ont voté. 1 utilisateur s'est abstenu.

Source : habr.com