Conversió en streaming de bases de dades Firebird 2.5 al format ODS12 (Firebird 3.0)

Cada versió de Firebird té la seva pròpia versió del format d'estructura del disc de la base de dades, O(n)D(isk)S(estructura). Fins a la versió 2.5 inclosa, el motor Firebird podia funcionar amb ODS de versions anteriors, és a dir, les bases de dades de versions antigues eren obertes per la nova versió i funcionaven en mode de compatibilitat, però el motor Firebird 3.0 només funciona amb bases de dades en la seva pròpia versió ODS. 12.0.

Per migrar a 3.0, la base de dades de 2.5 s'ha de convertir al nou format mitjançant còpia de seguretat/restauració. Per descomptat, suposem que la base de dades es va preparar prèviament per a la conversió, és a dir. Les metadades i les consultes s'han comprovat per a la compatibilitat amb Firebird 3.0.

Si seguiu l'enfocament estàndard, això vol dir que heu de fer una còpia de seguretat a la versió 2.5, després instal·lar la 3.0 i fer una restauració. Aquest procediment és acceptable si hi ha prou temps, però quan es migren bases de dades grans o quan es migren diverses dotzenes de bases de dades al mateix temps, quan el temps s'acaba, podeu utilitzar la conversió de streaming, que és un 30-40% més ràpida. Com fer-ho exactament (a Windows i a Linux), llegiu sota el tall.

La idea general és que farem servir un pipeline per accelerar les coses:

gbak -b … база25 stdout | gbak -c … stdin база30

Gbak de 2.5 genera una còpia de seguretat en format lineal i l'envia a stdout, que immediatament recull gbak de 3.0 mitjançant stdin i crea una nova base de dades.

Cal organitzar aquest pipeline amb un mètode d'accés local (fitxer), ja que l'accés a la xarxa (fins i tot mitjançant localhost) retardarà significativament el procés.

A continuació repassem els detalls de Windows i Linux.

Windows

En el cas de Windows, la manera més senzilla és fer una compilació completament autònoma de Firebird. Per això agafem incrustar-arxiu Firebird 2.5, canvieu el nom de fbemded.dll a fbclient.dll, afegiu les utilitats gbak.exe i (opcionalment) isql.exe de l'arxiu "normal" 2.5.

Firebird 3.0 utilitza muntatge únic i no requereix cap modificació.

La versió més mínima (que no requereix instal·lació de les biblioteques d'execució VS2008/VS2010 al sistema de destinació) conté els fitxers següents:

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 administrador experimentat pot notar que 2.5 no inclou els fitxers intl/fbintl.dll i intl/fbintl.conf. Això és cert, ja que gbak no utilitza un conjunt de caràcters de connexió i no converteix dades entre conjunts de caràcters, però al costat de "recepció" de Firebird 3.0, aquests fitxers són necessaris quan es creen índexs.

A firebird.conf Firebird 3.0 es recomana afegir:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

A més, és desitjable establir diferents valors IpcName per a 2.5 i 3.0.

Quan escollim els valors d'altres paràmetres de firebird.conf, procedim d'una consideració senzilla: en l'etapa de transfusió de dades, gbak executa 2.5 en un procés i 3.0 en l'altre, després 2.5 sortides i 3.0 comença a construir-se. índexs.

Per accelerar la fase de creació d'índexs a 3.0, es recomana augmentar la mida del paràmetre TempCacheLimit a ~ 40% de RAM (si és un servidor dedicat, és clar).

Per exemple, si el servidor té 16 GB de RAM, llavors vostè pot posar

TempCacheLimit=6G

Per descomptat, aquest valor només es pot establir per a Firebird 64 de 3 bits, ja que qualsevol procés de 32 bits no pot assignar més de 2 gigabytes de memòria.

A la versió 2.5, aquest paràmetre no s'ha de canviar: no pot ser superior a 2 gigabytes de totes maneres i no afecta la velocitat durant la còpia de seguretat.

Abans de realitzar l'operació, heu de comprovar que la memòria cau de la pàgina a la capçalera de la base de dades estigui establerta a 0 (ordre gstat -h databasename, vegeu la línia Buffers de pàgina).

Si la memòria cau s'estableix explícitament a la capçalera de la base de dades, anul·la els valors de firebird.conf (i databases.conf a 3.0), i en cas de valors insuficientment grans, pot provocar un consum excessiu de memòria i un intercanvi.

A continuació, copieu els fitxers al sistema de destinació.

La conversió es realitza després d'aturar el servei Firebird 2.5 del "sistema", a la línia d'ordres amb drets elevats per a l'administrador 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

Aquest exemple utilitza una "barra inclinada" entre cometes (vàlid "estil Unix") i un "barret" (el caràcter "^") escapa del caràcter de nova línia, que és útil quan s'escriuen ordres llargues. L'opció -st(atus) va aparèixer a Firebird 2.5.8 i us permet registrar dades sobre el temps en què s'està executant el procés gbak (per a més detalls, consulteu la documentació).

Linux

A Linux, Firebird 3 depèn de la biblioteca Tommath. A CentOS (RHEL) aquesta biblioteca es troba al repositori epel, a Ubuntu (Debian) al repositori del sistema.

Per a CentOS, primer heu de connectar el repositori epel i només després fer-ho

yum install libtommath

Ubuntu no necessita incloure repositoris addicionals, però Ubuntu 16 i Ubuntu 18 instal·len diferents versions dels paquets: libtommath0 i libtommath1, respectivament.

Firebird 3.0 busca tommath.so.0 i per a Ubuntu 18, a més, cal crear un enllaç (enllaç simbòlic) des de tommath.so.0 a tommath.so.1. Per fer-ho, primer heu de trobar tommath.so.1.

Ruta cercada a Ubuntu - /usr/lib/x86_64-linux-gnu/, però altres distribucions basades en Debian poden ser diferents.

El segon problema està relacionat amb el fet que fins a Firebird 3.0.1 inclòs, no hi havia una manera fàcil d'instal·lar dues versions de servidor diferents. No considerem l'opció "compilar des de la font amb el prefix requerit" a causa de la seva relativa complexitat.

Per a Firebird 3.0.2 i superior implementat construir amb --enable-binreloc i una opció d'instal·lador independent (camí del camí).

Suposant que la biblioteca tommath i, si cal, un enllaç simbòlic per a tommath.so.0 s'han afegit al sistema, podeu instal·lar la distribució actual (en el moment d'escriure aquest article) de Firebird 3.0.4 a, per exemple, /opt /fb3:

./install.sh -path /opt/fb3

Després d'això, podeu aturar el servei del sistema Firebird i iniciar la conversió en temps real.

Quan atureu el Firebird, tingueu en compte que els processos de Firebid 2.5 en mode clàssic solen ser iniciats per xinetd; per tant, heu de desactivar el servei firebird per a xinetd o aturar xinetd completament.

A firebird.conf per a 3.0 a Linux, no cal que configureu els paràmetres MaxUnflushed (només funcionen a Windows) i canvieu la configuració de Firebird 2.5.

A Linux, l'accés local (fitxer) de Firebird 2.5 no és equivalent a la versió incrustada a Windows; el servidor 2.5 funcionarà en el procés gbak (sense la part de xarxa), però els drets d'accés es comprovaran amb la base d'usuaris, el que significa que no només es requerirà un inici de sessió, sinó també una contrasenya:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

Després d'una conversió correcta, primer heu de desinstal·lar el Firebird 3.0 "addicional", després el Firebird 2.5 "principal", i després fer una instal·lació neta de Firebird 2.5 - i és millor des de l'instal·lador tar.gz normal, i no a través del repositoris, perquè. la versió dels repositoris pot quedar enrere.

A més, després de restaurar la base de dades a Linux i reinstal·lar-la, heu de comprovar que la nova base de dades és propietat de l'usuari del firebird.

Si no és així, caldrà corregir-ho.

chown firebird.firebird database

Total

A més d'estalviar temps i espai al disc, la conversió en streaming té un altre avantatge important: la conversió de la base de dades es fa sense eliminar el Firebird 2.5 existent, la qual cosa simplifica enormement la recuperació en cas de conversió no reeixida (la majoria de vegades a causa de la manca d'espai o un reinici inesperat durant la migració). procés).

L'estalvi de temps es deu al fet que la conversió "clàssica" és "temps de còpia de seguretat" més "temps de restauració". La recuperació consta de dues parts: llegir dades d'un fitxer de còpia de seguretat i crear un índex.

Amb la conversió en streaming, el temps total s'obté com a "temps de còpia de seguretat més un cinc a deu per cent" i "temps de creació d'índex".

Els resultats específics depenen de l'estructura de la base de dades, però, de mitjana, el temps de recuperació és aproximadament el doble del temps de còpia de seguretat. Per tant, si prenem el temps de còpia de seguretat com a unitat, llavors la "conversió clàssica" és de tres unitats de temps, la transmissió és de dues unitats de temps. Augmentar TempCacheLimit ajuda a reduir encara més el temps.

En general, la conversió en streaming a la pràctica us permet estalviar un 30-40% del temps de còpia de seguretat i restauració alternatives.

Tens preguntes?

Si us plau, escriviu totes les preguntes als comentaris o envieu-les a l'autor de la metodologia i coautor d'aquest article: Vasily Sidorov, enginyer de sistemes líder d'iBase, a bs at ibase ru.

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.

Quina versió de Firebird fas servir?

• Firebird 3.x

• Ocell de foc 2.5

• Ocell de foc 2.1

• Firebird 2.0, 1.5 o 1.0

Han votat 16 usuaris. 1 usuari es va abstenir.

Font: www.habr.com