{"id":30280,"date":"2019-10-31T21:34:38","date_gmt":"2019-10-31T18:34:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0\/"},"modified":"2019-10-31T21:34:38","modified_gmt":"2019-10-31T18:34:38","slug":"potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","title":{"rendered":"Conversion en continu des bases Firebird 2.5 au format ODS12 (Firebird 3.0)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Chaque version de Firebird a sa propre version du format des structures de disque de la base de donn\u00e9es \u2013 O(n)D(isk)S(tructure). Jusqu'\u00e0 la version 2.5 incluse, le moteur Firebird pouvait travailler avec des ODS des versions pr\u00e9c\u00e9dentes, ce qui signifie que les bases de donn\u00e9es anciennes pouvaient \u00eatre ouvertes par la nouvelle version tout en fonctionnant en mode de compatibilit\u00e9, mais le moteur Firebird 3.0 ne fonctionne qu'avec des DB dans sa propre version ODS 12.0.<\/p>\n

Pour passer \u00e0 3.0, la base de donn\u00e9es de 2.5 doit \u00eatre convertie au nouveau format via backup\/restore. Bien s\u00fbr, nous supposons que la DB a \u00e9t\u00e9 pr\u00e9par\u00e9e pour la conversion, c'est-\u00e0-dire que les m\u00e9tadonn\u00e9es et les requ\u00eates ont \u00e9t\u00e9 v\u00e9rifi\u00e9es pour leur compatibilit\u00e9 avec Firebird 3.0.<\/p>\n

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\u00e9dure est acceptable si l'on dispose de suffisamment de temps, mais lors de la migration de grandes bases de donn\u00e9es, ou lors de la migration simultan\u00e9e de plusieurs dizaines de DB, quand le temps presse, il est possible de recourir \u00e0 la conversion en continu, qui est 30 \u00e0 40 % plus rapide. Pour savoir comment faire cela (sous Windows et sous Linux), lisez la suite.
\n<\/a><\/noindex>
\nL'id\u00e9e g\u00e9n\u00e9rale est que nous allons utiliser un pipeline pour acc\u00e9l\u00e9rer le processus :<\/p>\n

gbak -b \u2026 base25 stdout | gbak -c \u2026 stdin base30<\/code><\/pre>\n
\nGbak 2.5 g\u00e9n\u00e8re une sauvegarde au format lin\u00e9aire et l'envoie dans stdout, qui est imm\u00e9diatement r\u00e9cup\u00e9r\u00e9 par gbak 3.0 via stdin, cr\u00e9ant ainsi une nouvelle DB.<\/p>\n
Il est imp\u00e9ratif d'organiser ce pipeline avec un acc\u00e8s local (fichiers), car l'acc\u00e8s r\u00e9seau (m\u00eame via localhost) ralentira consid\u00e9rablement le processus.<\/p>\n
Ci-dessous, nous examinons les d\u00e9tails pour Windows et Linux.<\/p>\n
Windows<\/b><\/p>\n
Dans le cas de Windows, il est plus simple de r\u00e9aliser une compilation compl\u00e8tement autonome de Firebird. Pour cela, nous prenons l'archive embed de Firebird 2.5<\/a><\/noindex>, renommant fbemded.dll en fbclient.dll, en ajoutant depuis l'archive \u00ab normale \u00bb 2.5 les utilitaires gbak.exe et (facultativement) \u2013 isql.exe. <\/p>\n
Firebird 3.0 utilise une seule compilation<\/a><\/noindex> et ne requiert aucun ajustement.<\/p>\n
La variante minimale (ne n\u00e9cessitant pas l'installation des biblioth\u00e8ques runtime VS2008\/VS2010 sur le syst\u00e8me cible) contient les fichiers suivants :<\/p>\n
25\/gbak.exe\n25\/fbclient.dll\n25\/firebird.conf\n25\/firebird.log\n25\/firebird.msg\n25\/ib_util.dll\n25\/icudt30.dll\n25\/icuin30.dll\n25\/icuuc30.dll\n25\/Microsoft.VC80.CRT.manifest\n25\/msvcp80.dll\n25\/msvcr80.dll\n\n30\/fbclient.dll\n30\/firebird.conf\n30\/firebird.msg\n30\/gbak.exe\n30\/ib_util.dll\n30\/icudt52.dll\n30\/icudt52l.dat\n30\/icuin52.dll\n30\/icuuc52.dll\n30\/msvcp100.dll\n30\/msvcr100.dll\n30\/intl\/fbintl.conf\n30\/intl\/fbintl.dll\n30\/plugins\/engine12.dll<\/code><\/pre>\n
\nUn administrateur exp\u00e9riment\u00e9 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\u00e9es entre les charsets, mais du c\u00f4t\u00e9 'r\u00e9ception' de Firebird 3.0, ces fichiers sont n\u00e9cessaires lors de la cr\u00e9ation d'index.<\/p>\n
Dans firebird.conf, il est recommand\u00e9 d'ajouter pour Firebird 3.0 :<\/p>\n
MaxUnflushedWrites = -1\nMaxUnflushedWriteTime = -1<\/code><\/pre>\n
\nIl est \u00e9galement souhaitable d'installer une valeur diff\u00e9rente pour IpcName pour 2.5 et 3.0. <\/p>\n
Lors du choix des valeurs d'autres param\u00e8tres de firebird.conf, nous partons d'une simple consid\u00e9ration : au stade du transfert de donn\u00e9es, dans un processus gbak fonctionne en 2.5, et dans un autre \u2013 en 3.0, ensuite 2.5 termine son travail, tandis que 3.0 commence \u00e0 construire les index.<\/p>\n
Pour acc\u00e9l\u00e9rer la phase de construction des index dans 3.0, il est recommand\u00e9 d'augmenter la taille du param\u00e8tre TempCacheLimit \u00e0 environ 40% de la RAM (si c'est un serveur d\u00e9di\u00e9, bien s\u00fbr).<\/p>\n
Par exemple, si le serveur a 16 Go de RAM, on peut d\u00e9finir <\/p>\n
TempCacheLimit=6G<\/code><\/pre>\n
\nBien entendu, une telle valeur ne peut \u00eatre d\u00e9finie que pour Firebird 3 en 64 bits, car tout processus en 32 bits ne peut pas allouer plus de 2 Go de m\u00e9moire.<\/i><\/p>\n
Pour 2.5, ce param\u00e8tre n'a pas besoin d'\u00eatre modifi\u00e9 \u2013 il ne peut pas \u00eatre sup\u00e9rieur \u00e0 2 Go de toute fa\u00e7on, et cela n'affecte pas la vitesse lors de la sauvegarde.<\/p>\n
Avant d'ex\u00e9cuter l'op\u00e9ration, il est n\u00e9cessaire de v\u00e9rifier que le cache de pages dans l'en-t\u00eate de la base de donn\u00e9es est r\u00e9gl\u00e9 \u00e0 0 (commande gstat -h databasename<\/code>, voir la ligne Page buffers). <\/p>\n
Si le cache est d\u00e9fini explicitement dans l'en-t\u00eate de BD, il \u00e9crase les valeurs de firebird.conf (et databases.conf dans 3.0), et en cas de valeurs excessivement \u00e9lev\u00e9es, cela peut entra\u00eener une consommation excessive de m\u00e9moire et un passage en swap.<\/p>\n
Ensuite, copiez les fichiers sur le syst\u00e8me cible. <\/p>\n
La conversion s'effectue apr\u00e8s l'arr\u00eat du service 'syst\u00e8me' Firebird 2.5, dans la ligne de commande avec \u00e9l\u00e9vation des droits au niveau d'administrateur local (exemple) :<\/p>\n
set ISC_USER=propri\u00e9taire\n\"25\/gbak\" -z -b -g -v -st t -y 25.log base25 stdout|^\n\"30\/gbak\" -z -c -v -st t -y 30.log stdin base30<\/code><\/pre>\n
\nDans cet exemple, une 'barre oblique directe' entre guillemets est utilis\u00e9e (style 'unix' valide), et le 'chapeau' (symbole '^') \u00e9chappe le caract\u00e8re de retour \u00e0 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\u00e9es sur la dur\u00e9e d'ex\u00e9cution du processus gbak (d\u00e9tails dans la documentation).<\/p>\n
Linux<\/b><\/p>\n
Sous Linux, Firebird 3 d\u00e9pend de la biblioth\u00e8que tommath. Dans CentOS (RHEL), cette biblioth\u00e8que se trouve dans le d\u00e9p\u00f4t epel, dans Ubuntu (Debian) dans le d\u00e9p\u00f4t syst\u00e8me.<\/p>\n
Pour CentOS, il est n\u00e9cessaire de connecter d'abord le d\u00e9p\u00f4t epel, puis de faire <\/p>\n
yum install libtommath<\/code><\/pre>\n
\nPour Ubuntu, il n'est pas n\u00e9cessaire de connecter des d\u00e9p\u00f4ts suppl\u00e9mentaires, mais dans Ubuntu 16 et Ubuntu 18, diff\u00e9rentes versions des paquets sont install\u00e9es \u2013 libtommath0 et libtommath1, respectivement.<\/p>\n
Firebird 3.0 recherche tommath.so.0 et pour Ubuntu 18, il est \u00e9galement n\u00e9cessaire de cr\u00e9er un lien (symlink) de tommath.so.0 vers tommath.so.1. Pour cela, il faut d'abord localiser tommath.so.1. <\/p>\n
Le chemin recherch\u00e9 dans Ubuntu est \/usr\/lib\/x86_64-linux-gnu\/<\/code>, mais dans d'autres distributions bas\u00e9es sur Debian, cela peut \u00eatre diff\u00e9rent.<\/p>\n
Le deuxi\u00e8me probl\u00e8me est que jusqu'\u00e0 Firebird 3.0.1 inclusivement, il n'y avait pas de moyen simple d'installer deux versions diff\u00e9rentes du serveur. Nous ne consid\u00e9rons pas l'option \u00ab compiler \u00e0 partir des sources avec le pr\u00e9fixe appropri\u00e9 \u00bb en raison de sa relative complexit\u00e9.<\/p>\n
Pour Firebird 3.0.2 et sup\u00e9rieur, une compilation avec \u2013enable-binreloc<\/a><\/noindex> et une option s\u00e9par\u00e9e dans l'installateur (-path chemin) ont \u00e9t\u00e9 mises en \u0153uvre.<\/p>\n
En supposant que la biblioth\u00e8que tommath et, si n\u00e9cessaire, le symlink pour tommath.so.0 ont \u00e9t\u00e9 ajout\u00e9s au syst\u00e8me, on peut proc\u00e9der \u00e0 l'installation de la distribution actuelle (au moment de la r\u00e9daction de cet article) de Firebird 3.0.4 dans, par exemple, \/opt\/fb3 :<\/p>\n
.\/install.sh -path \/opt\/fb3<\/code><\/pre>\n
\nApr\u00e8s cela, on peut arr\u00eater le service syst\u00e8me Firebird et lancer la conversion en continu. <\/p>\n
Lors de l'arr\u00eat de Firebird, il faut prendre en compte que les processus Firebird 2.5 en mode Classic sont g\u00e9n\u00e9ralement lanc\u00e9s par xinetd \u2013 il est donc n\u00e9cessaire soit d'interdire le service firebird pour xinetd, soit d'arr\u00eater xinetd compl\u00e8tement.<\/i><\/p>\n
Dans firebird.conf pour 3.0 sur Linux, il n'est pas n\u00e9cessaire de d\u00e9finir les param\u00e8tres MaxUnflushed (ils ne fonctionnent que sur Windows) et de modifier les r\u00e9glages de Firebird 2.5. <\/p>\n
Sous Linux, l'acc\u00e8s local (fichier) de Firebird 2.5 n'est pas \u00e9quivalent \u00e0 une version int\u00e9gr\u00e9e sous Windows \u2013 le serveur 2.5 fonctionnera dans le processus gbak (sans partie r\u00e9seau), mais les droits d'acc\u00e8s seront v\u00e9rifi\u00e9s selon la base d'utilisateurs, ce qui signifie qu'il faudra non seulement un identifiant, mais aussi un mot de passe : <\/p>\n
export ISC_USER=username ISC_PASSWORD=password\n\/opt\/firebird\/bin\/gbak -b \u2026 base25 stdout\n|\/opt\/fb3\/bin\/gbak -c \u2026 stdin base30<\/code><\/pre>\n
\nApr\u00e8s une conversion r\u00e9ussie, il faut d'abord supprimer le Firebird 3.0 \u00ab suppl\u00e9mentaire \u00bb, puis le Firebird 2.5 \u00ab principal \u00bb et enfin effectuer une installation propre de Firebird 2.5 \u2013 de pr\u00e9f\u00e9rence depuis l'installateur standard tar.gz, et non via les d\u00e9p\u00f4ts, car la version dans les d\u00e9p\u00f4ts peut \u00eatre obsol\u00e8te.<\/p>\n
De plus, apr\u00e8s la restauration de la BDD sur Linux et la r\u00e9installation, il faut s'assurer que la nouvelle BDD ait pour propri\u00e9taire l'utilisateur firebird.<\/p>\n
Si ce n'est pas le cas, il faudra corriger<\/p>\n
chown firebird.firebird database<\/code><\/pre>\n
\nConclusion<\/b><\/p>\n
En plus de faire gagner du temps et d'\u00e9conomiser de l'espace disque, la conversion coh\u00e9rente pr\u00e9sente un autre avantage important : la transformation de la base se fait sans supprimer l'existant Firebird 2.5, ce qui facilite consid\u00e9rablement le retour en arri\u00e8re en cas d'\u00e9chec de la conversion (g\u00e9n\u00e9ralement d\u00fb \u00e0 un manque d'espace ou \u00e0 un red\u00e9marrage impr\u00e9vu pendant le processus de migration).<\/p>\n
Le gain de temps est li\u00e9 au fait que la conversion \u00ab classique \u00bb implique le \u00ab temps de sauvegarde \u00bb plus le \u00ab temps de restauration \u00bb. La restauration se compose de deux parties : la lecture des donn\u00e9es \u00e0 partir du fichier de sauvegarde et la construction de l'index.<\/p>\n
Avec la conversion coh\u00e9rente, le temps total est \u00e9quivalent \u00e0 \u00ab le temps de sauvegarde plus cinq \u00e0 dix pour cent \u00bb et \u00e0 \u00ab le temps de construction des index \u00bb.<\/p>\n
Les r\u00e9sultats sp\u00e9cifiques d\u00e9pendent de la structure de la base, mais en moyenne, le temps de restauration est environ le double du temps de sauvegarde. Par cons\u00e9quent, si l'on consid\u00e8re le temps de sauvegarde comme une unit\u00e9, la conversion \u00ab classique \u00bb prend trois unit\u00e9s de temps, tandis que la conversion coh\u00e9rente n'en prend que deux. Une augmentation de TempCacheLimit peut \u00e9galement aider \u00e0 r\u00e9duire le temps.<\/p>\n
Dans l'ensemble, la conversion coh\u00e9rente permet de gagner en pratique 30 \u00e0 40 % du temps par rapport \u00e0 une sauvegarde et une restauration s\u00e9quentielles.<\/p>\n
Des questions ?<\/b><\/p>\n
Veuillez poser toutes vos questions dans les commentaires ou les adresser \u00e0 l'auteur de la m\u00e9thode et co-auteur de cet article \u2014 Vasily Sidorov, ing\u00e9nieur syst\u00e8me senior chez \u00ab iBase \u00bb, \u00e0 l'adresse bs at ibase ru.<\/p>\n
Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n
Quelle version de Firebird utilisez-vous ?<\/h2>\n