Chaque version de Firebird a sa propre version du format des structures de base de données de disques - O (n) D (isk) S (tructure). Avant la version 2.5 incluse, le moteur Firebird pouvait fonctionner avec les ODS des versions précédentes, c'est-à-dire que les bases de données des anciennes versions étaient ouvertes par la nouvelle version et fonctionnaient en mode de compatibilité, mais le moteur Firebird 3.0 ne fonctionne qu'avec une base de données dans sa propre version ODS 12.0.
Pour passer à 3.0, la base de données de 2.5 doit être convertie dans un nouveau format via sauvegarde / restauration. Bien sûr, nous supposons que la base de données a été préalablement préparée pour la conversion - c.-à-d. les métadonnées et les requêtes ont été testées pour la compatibilité avec Firebird 3.0.
Si vous suivez l'approche standard, cela signifie que vous devez sauvegarder sur la version 2.5, puis installer 3.0 et effectuer une restauration. Cette procédure est acceptable s'il y a suffisamment de temps, mais lors de la migration de grandes bases de données, ou lors de la migration de plusieurs dizaines de bases de données en même temps, lorsque le temps est compté, vous pouvez utiliser la conversion de flux, ce qui est 30 à 40% plus rapide. Comment faire exactement cela (sous Windows et sous Linux), lire sous le chat.
L'idée générale est que pour l'accélération, nous utiliserons le pipeline:
gbak -b … 25 stdout | gbak -c … stdin 30
Gbak à partir de 2.5 génère une sauvegarde au format linéaire et l'envoie à stdout, qui récupère immédiatement gbak à partir de 3.0 via stdin et crée une nouvelle base de données.
Il est nécessaire d'organiser un tel pipeline en utilisant la méthode d'accès local (fichier), car l'accès au réseau (même via localhost) ralentira considérablement le processus.
Ci-dessous, nous examinons les détails pour Windows et Linux.
WindowsDans le cas de Windows, le moyen le plus simple est de créer une version entièrement autonome de Firebird. Pour ce faire, prenez l'
archive intégrée
Firebird 2.5 , renommez fbemded.dll en fbclient.dll, ajoutez les utilitaires gbak.exe à partir de l'archive 2.5 «habituelle» et (éventuellement) isql.exe.
Firebird 3.0 utilise un
seul assemblage et ne nécessite aucune modification.
La plus petite option (qui ne nécessite pas l'installation de bibliothèques d'exécution 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 intl / fbintl.dll et intl / fbintl.conf ne sont pas inclus dans 2.5. C'est vrai, car gbak n'utilise pas de caractère de connexion et ne convertit pas les données entre caractères, 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, Firebird 3.0 recommande d'ajouter:
MaxUnflushedWrites = -1 MaxUnflushedWriteTime = -1
En outre, il est conseillé de définir différentes valeurs IpcName pour 2.5 et 3.0.
Lors du choix des valeurs d'autres paramètres, firebird.conf procède d'une simple considération: au stade du transfert de données, dans un processus, gbak exécute 2.5, et dans l'autre 3.0, puis 2.5 se termine et 3.0 commence à construire des 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 à ~ 40% de RAM (s'il s'agit d'un serveur dédié, bien sûr).
Par exemple, si le serveur dispose de 16 Go de RAM, vous pouvez mettre
TempCacheLimit=6G
Bien sûr, cette valeur ne peut être définie que pour Firebird 3 64 bits, car tout processus 32 bits ne pourra pas allouer plus de 2 gigaoctets de mémoire.À 2,5, ce paramètre n'a pas besoin d'être modifié - il ne peut déjà pas dépasser 2 gigaoctets et il n'affecte pas la vitesse pendant la sauvegarde.
Avant d'effectuer l'opération, vous devez vérifier que le cache de page dans l'en-tête de la base de données est défini sur 0 (commande
gstat -h databasename , voir la ligne Page buffers).
Si le cache est spécifié explicitement dans l'en-tête de la base de données, il remplace les valeurs de firebird.conf (et databases.conf dans 3.0), et en cas de valeurs insuffisamment grandes, il peut entraîner une consommation de mémoire excessive et passer au swap.
Ensuite, copiez les fichiers sur le système cible.
La conversion est effectuée après l'arrêt du service «système» Firebird 2.5, sur la ligne de commande avec des privilèges croissants pour l'administrateur local (exemple):
set ISC_USER= "25/gbak" -z -b -g -v -st t -y 25.log 25 stdout|^ "30/gbak" -z -c -v -st t -y 30.log stdin 30
Cet exemple utilise «rectiligne oblique» entre guillemets («style unix» valide) et «chapeau» (caractère «^») échappe au caractère de saut de ligne, ce qui est pratique lors de la saisie de commandes longues. L'option -st (atus) est apparue dans Firebird 2.5.8 et vous permet d'écrire des données sur la durée de fonctionnement du processus gbak dans le protocole (voir la documentation pour plus de détails).
LinuxSous Linux, Firebird 3 dépend de la bibliothèque tommath. Dans CentOS (RHEL), cette bibliothèque est dans le dépôt epel, dans Ubuntu (Debian) elle est dans le système.
Pour CentOS, vous devez d'abord connecter le référentiel epel et ensuite seulement
yum install libtommath
Ubuntu n'a pas besoin de connecter des référentiels supplémentaires, mais différentes versions des packages sont installées sur Ubuntu 16 et Ubuntu 18 - 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 (lien symbolique) entre tommath.so.0 et tommath.so.1. Pour ce faire, vous devez d'abord trouver tommath.so.1.
Le chemin de recherche dans Ubuntu est
/usr/lib/x86_64-linux-gnu/ , mais dans d'autres distributions basées sur Debian, il peut être différent.
Le deuxième problème est qu'avant Firebird 3.0.1, inclus, il n'y avait pas de moyen facile d'installer deux versions différentes du serveur. Nous ne considérons pas l'option «compiler depuis la source avec le préfixe souhaité» en raison de sa relative complexité.
Pour Firebird 3.0.2 et supérieur, une
version avec –enable-binreloc et une option d'installation distincte (-path path) sont implémentées.
En supposant que la bibliothèque tommath et, si nécessaire, le lien symbolique pour tommath.so.0 ont été ajoutés au système, vous pouvez ajouter la distribution Firebird 3.0.4 réelle (au moment d'écrire ces lignes), par exemple, / opt / fb3:
./install.sh -path /opt/fb3
Après cela, vous pouvez arrêter le service système Firebird et démarrer la conversion en streaming.
Lors de l'arrêt de Firebird, il convient de garder à l'esprit que les processus Firebid 2.5 en mode classique démarrent généralement xinetd - il est donc nécessaire de désactiver le service firebird pour xinetd ou d'arrêter complètement xinetd.Dans firebird.conf for 3.0 sous Linux, vous n'avez pas besoin de définir les paramètres MaxUnflushed (ils ne fonctionnent que sous Windows) et de modifier les paramètres de Firebird 2.5.
Sous Linux, l'accès local (fichier) de Firebird 2.5 n'est pas équivalent à la version intégrée pour Windows - le serveur 2.5 fonctionnera dans le processus gbak (sans la partie réseau), mais les droits d'accès seront vérifiés par rapport à la base d'utilisateurs, ce qui signifie que non seulement une connexion, mais aussi un mot de passe seront nécessaires :
export ISC_USER=username ISC_PASSWORD=password /opt/firebird/bin/gbak -b … 25 stdout\ |/opt/fb3/bin/gbak -c … stdin 30
Après une conversion réussie, vous devez d'abord supprimer Firebird 3.0 "supplémentaire", puis Firebird 2.5 "principal", et seulement après cela, effectuez une nouvelle installation de Firebird 3.0 - le meilleur de tous depuis le programme d'installation tar.gz normal, et non via les référentiels, car la version dans les référentiels peut être en retard.
De plus, après avoir restauré la base de données Linux et l'avoir réinstallée, vous devez vérifier que la nouvelle base de données a le propriétaire de l'utilisateur firebird.
Si ce n'est pas le cas, il sera nécessaire de corriger
chown firebird.firebird database
RésuméEn plus d'économiser du temps et de l'espace disque, la conversion de flux présente un autre avantage important - la conversion de la base de données se fait sans supprimer Firebird 2.5 existant, ce qui simplifie considérablement la restauration si la conversion échoue (le plus souvent en raison d'un manque d'espace ou d'un redémarrage inattendu pendant le processus de migration).
Le gain de temps est dû au fait que la conversion "classique" est "temps de sauvegarde" plus "temps de récupération". La récupération se compose de deux parties: lire les données d'un fichier de sauvegarde et créer un index.
Dans la conversion en streaming, le temps total est obtenu comme «temps de sauvegarde plus cinq à dix pour cent» et «temps de construction d'index».
Les résultats spécifiques dépendent de la structure de la base de données, mais en moyenne, le temps de récupération est approximativement égal au temps de double sauvegarde. Par conséquent, si nous prenons le temps de sauvegarde par unité, alors la «conversion classique» - trois unités de temps, le flux - deux unités de temps. Une augmentation de TempCacheLimit contribue également à réduire le temps.
En général, la conversion de flux dans la pratique vous permet d'économiser 30 à 40% pour cent du temps d'une sauvegarde et d'un restaurant alternatifs.
Des questions?Veuillez écrire toutes les questions dans les commentaires ou envoyer à l'auteur de la méthodologie et co-auteur de cet article - Vasily Sidorov, ingénieur système leader d'iBase, chez bs at ibase ru.