Conversia în flux a bazelor de date Firebird 2.5 în format ODS12 (Firebird 3.0)

Fiecare versiune a Firebird are propria versiune a formatului structurilor de date pe disc – O(n)D(isk)S(tructure). Până la versiunea 2.5 inclusiv, motorul Firebird putea funcționa cu ODS-uri din versiunile anterioare, adică bazele de date din versiunile mai vechi erau deschise de noua versiune și funcționau în modul de compatibilitate, dar motorul Firebird 3.0 funcționează doar cu bazele de date în propria versiune ODS 12.0.

Pentru a trece la 3.0, baza de date de la 2.5 trebuie să fie convertită în noul format prin backup/restaurare. Desigur, presupunem că baza de date a fost pregătită anterior pentru conversie – adică metadatele și interogările au fost verificate pentru compatibilitatea cu Firebird 3.0.

Dacă ne conformăm abordării standard, acest lucru înseamnă că trebuie să facem un backup pe versiunea 2.5, apoi să instalăm 3.0 și să facem restaurarea. Această procedură este acceptabilă dacă există suficient timp, dar în migrarea bazelor de date mari, sau în timpul migrării simultane a zeci de baze de date, când timpul este esențial, se poate folosi conversia în flux, care este cu 30-40% mai rapidă. Cum se face asta (pe Windows și pe Linux), citiți mai departe.

Ideea generală este că pentru a accelera, vom utiliza un pipeline:

gbak -b … baza25 stdout | gbak -c … stdin baza30

Gbak de la 2.5 generează un backup în format liniar și îl direcționează în stdout, care imediat prin stdin este preluat de gbak de la 3.0 și creează o nouă bază de date.

Organizarea acestui pipeline trebuie să fie neapărat prin metoda locală (de fișier), deoarece accesul de rețea (chiar și prin localhost) va încetini semnificativ procesul.

Mai jos vom discuta detalii pentru Windows și Linux.

Windows

În cazul Windows, cea mai simplă soluție este de a crea o construcție complet autonomă a Firebird. Pentru aceasta, luăm arhiva embed Firebird 2.5, redenumim fbemded.dll în fbclient.dll, adăugăm din arhiva 'obișnuită' 2.5 utilitarele gbak.exe și (opțional) – isql.exe.

Firebird 3.0 folosește o construcție unificată și nu necesită nicio modificare.

Cea mai minimă variantă (care nu necesită instalarea bibliotecilor de runtime VS2008/VS2010 pe sistemul-țintă) conține următoarele fișiere:

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 administrator experimentat poate observa că în 2.5 nu sunt incluse fișierele intl/fbintl.dll și intl/fbintl.conf. Așa este, deoarece gbak nu utilizează charsetul de conectare și nu convertește datele între charseturi, dar pe partea de „primire” în Firebird 3.0 aceste fișiere sunt necesare pentru crearea indicilor.

În firebird.conf Firebird 3.0 se recomandă adăugarea:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

De asemenea, este de dorit să se stabilească valori diferite pentru IpcName între 2.5 și 3.0.

La alegerea valorilor altor parametri în firebird.conf ne bazăm pe o considerare simplă: în timpul transferului de date, într-un proces funcționează gbak în 2.5, iar în altul – în 3.0, apoi 2.5 finalizează activitatea, iar 3.0 începe construirea indicilor.

Pentru a accelera etapa de construire a indicilor în 3.0, se recomandă creșterea dimensiunii parametrului TempCacheLimit la ~40% din RAM (dacă este un server dedicat, desigur).

De exemplu, dacă serverul are 16 GB RAM, se poate seta

TempCacheLimit=6G

Bineînțeles, o astfel de valoare poate fi stabilită doar pentru Firebird 3 pe 64 de biți, deoarece orice proces pe 32 de biți nu poate aloca mai mult de 2 GB de memorie.

Pentru 2.5 acest parametru nu trebuie schimbat – oricum nu poate depăși 2 GB și nu influențează viteza în timpul backup-ului.

Înainte de a efectua operațiunea, trebuie să verificați că memoria tampon pe pagini din antetul bazei de date este setată la 0 (comanda gstat -h numedenumelabazei, verificați linia Bufferelor de pagină).

Dacă cache-ul este specificat explicit în antetul DB, acesta va suprascrie valorile din firebird.conf (și databases.conf în 3.0), iar în cazul unor valori exagerat de mari, poate duce la consum excesiv de memorie și swap.

Apoi, copiem fișierele pe sistemul țintă.

Conversia se efectuează după oprirea serviciului „sistemic” Firebird 2.5, în linia de comandă, cu privilegii de administrator local (exemplu):

set ISC_USER=proprietar
"25/gbak" -z -b -g -v -st t -y 25.log baza25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin baza30

În acest exemplu se folosește„slash” direct între ghilimele (stil permis „unix-style”), iar „caretul” (simbolul „^”) escamează simbolul de sfârșit de linie, ceea ce este convenabil pentru introducerea comenzilor lungi. Opțiunea -st(atus) a apărut în Firebird 2.5.8 și permite înregistrarea în jurnal a datelor despre durata de execuție a procesului gbak (detalii – în documentație).

Linux

Pe Linux, Firebird 3 depinde de biblioteca tommath. În CentOS (RHEL), această bibliotecă se află în depozitul epel, în Ubuntu (Debian) în – sistem.

Pentru CentOS, trebuie mai întâi să activați depozitul epel și abia apoi să faceți

yum install libtommath

Pe Ubuntu, nu este necesar să activați depozite suplimentare, dar în Ubuntu 16 și Ubuntu 18 se instalează versiuni diferite de pachete – libtommath0 și libtommath1, respectiv.

Firebird 3.0 caută tommath.so.0 și pentru Ubuntu 18 este necesar să creați suplimentar un link (symlink) de la tommath.so.0 la tommath.so.1. Pentru aceasta, mai întâi trebuie să găsiți tommath.so.1.

Calea căutată în Ubuntu este /usr/lib/x86_64-linux-gnu/, dar în alte distribuții bazate pe Debian poate fi diferit.

A doua problemă este legată de faptul că până la Firebird 3.0.1 inclusiv, nu exista o modalitate simplă de a instala două versiuni diferite ale serverului. Opțiunea „compilăm din surse cu prefixul dorit” nu o luăm în considerare din cauza muncii relative intense.

Pentru Firebird 3.0.2 și versiuni ulterioare, a fost implementată construcția cu –enable-binreloc și o opțiune separată a instalatorului (-path cale).

Presupunând că biblioteca tommath și, dacă este necesar, symlink-ul pentru tommath.so.0 au fost adăugate în sistem, puteți instala distribuția actuală (la momentul scrierii acestui articol) Firebird 3.0.4 în, de exemplu, /opt/fb3:

./install.sh -path /opt/fb3

După aceasta, puteți opri serviciul de sistem Firebird și să începeți conversia în flux.

La oprirea Firebird, trebuie să luați în considerare faptul că procesele Firebird 2.5 în modul Classic sunt declanșate de obicei de xinetd – așa că trebuie fie să interziceți serviciul firebird pentru xinetd, fie să opriți complet xinetd.

În firebird.conf pentru 3.0 pe Linux, nu trebuie să specificați parametrii MaxUnflushed (aceștia funcționează doar pe Windows) și să schimbați setările pentru Firebird 2.5.

Pe Linux, accesul local (pe fișier) pentru Firebird 2.5 nu este echivalent cu varianta embeded de pe Windows – serverul 2.5 va funcționa în procesul gbak (fără partea de rețea), dar permisiunile vor fi verificate pe baza utilizatorilor, așa că va fi necesar nu doar loginul, ci și parola:

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

După conversia cu succes, trebuie să eliminați mai întâi „Firebird 3.0 suplimentar”, apoi „Firebird 2.5 principal” și abia după aceea să efectuați o instalare curată a Firebird 2.5 – de preferat din instalatorul standard tar.gz, nu din depozite, deoarece versiunea din depozite poate fi învechită.

De asemenea, după restaurarea Bazei de Date pe Linux și reinstalare, trebuie să verificați că noua bază de date are ca proprietar utilizatorul firebird.

Dacă nu este așa, va trebui să corectați

chown firebird.firebird database

Rezultatul

Pe lângă economisirea timpului și a spațiului pe disc, conversia în flux are un alt avantaj important – transformarea bazei se face fără a elimina Firebird 2.5 existent, ceea ce simplifică semnificativ revenirea în cazul unei conversii eșuate (cel mai adesea din cauza lipsei de spațiu sau a unei reporniri neașteptate în timpul procesului de migrare).

Economisirea timpului este legată de faptul că conversia „clasică” reprezintă „timpul de backup” plus „timpul de restaurare”. Restaurarea constă în două părți: citirea datelor din fișierul de backup și construirea indexului.

În cazul conversiei în flux, timpul total se obține ca „timpul de backup plus cinci-zece procente” și „timpul de construire a indexurilor”.

Rezultatele specifice depind de structura bazei, dar, în medie, timpul de restaurare este aproximativ dublu față de timpul de backup. Prin urmare, dacă luăm ca unitate timpul de backup, atunci „conversia clasică” reprezintă trei unități de timp, iar conversia în flux – două unități de timp. O creștere a TempCacheLimit ajută, de asemenea, la reducerea timpului.

În general, conversia în flux permite economisirea a 30-40% din timpul de backup secvențial și restaurare.

Întrebări?

Vă rugăm să adresați toate întrebările în comentarii sau să le trimiteți autorului metodologiei și co-autorului acestui articol – Vasily Sidorov, inginerul principal de sistem de la compania „iBase”, la adresa bs at ibase ru.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.

Ce versiune de Firebird folosiți?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 sau 1.0

Au votat 16 utilizatori. A votat împotrivă 1 utilizator.

Sursa: habr.com