Fiecare versiune de Firebird are propria sa versiune a formatului structurii discului bazei de date, O(n)D(isk)S(structure). Până la versiunea 2.5 inclusiv, motorul Firebird putea funcționa cu ODS din versiunile anterioare, adică bazele de date din versiunile vechi erau deschise de noua versiune și funcționau în modul de compatibilitate, dar motorul Firebird 3.0 funcționează doar cu baze de date în propria sa versiune ODS 12.0.
Pentru a migra la 3.0, baza de date de la 2.5 trebuie 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 compatibilitate cu Firebird 3.0.
Если следовать стандартному подходу, это означает, что нужно произвести бэкап на версии 2.5, затем установить 3.0 и сделать рестор. Такая процедура приемлема, если есть достаточно времени, но при миграции больших баз данных, или при одновременной миграции нескольких десятков БД, когда время поджимает, можно воспользоваться поточной конвертацией, которая на 30-40% быстрее. Как именно это сделать (под Windows si sub Linux), читайте под катом.
Ideea generală este că vom folosi o conductă pentru a accelera lucrurile:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak de la 2.5 generează o copie de rezervă într-un format liniar și o trimite la stdout, care preia imediat gbak de la 3.0 prin stdin și creează o nouă bază de date.
Este necesar să se organizeze o astfel de conductă cu o metodă de acces local (fișier), deoarece accesul la rețea (chiar și prin localhost) va încetini semnificativ procesul.
Ниже мы рассматриваем детали для Windows и Linux.
Windows
În cazul Windows проще всего сделать полностью автономную сборку Firebird. Для этого берём , redenumiți fbemded.dll în fbclient.dll, adăugați utilitare gbak.exe și (opțional) isql.exe din arhiva „obișnuită” 2.5.
Firebird 3.0 folosește și nu necesită nicio modificare.
Versiunea cea mai minimă (care nu necesită instalarea bibliotecilor de rulare 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.dllUn administrator cu experiență poate observa că 2.5 nu include fișierele intl/fbintl.dll și intl/fbintl.conf. Acest lucru este adevărat, deoarece gbak nu folosește un set de caractere de conexiune și nu convertește datele între seturi de caractere, dar pe partea de „recepție” a Firebird 3.0, aceste fișiere sunt necesare atunci când se creează indexuri.
În firebird.conf Firebird 3.0 este recomandat să adăugați:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1De asemenea, este de dorit să setați diferite valori IpcName pentru 2.5 și 3.0.
Atunci când alegem valorile altor parametri ai firebird.conf, pornim de la o considerație simplă: în etapa de transfuzie de date, gbak rulează 2.5 într-un proces și 3.0 în celălalt, apoi 2.5 iese și 3.0 începe construirea indici.
Pentru a accelera faza de construire a indexului în 3.0, este recomandat să măriți dimensiunea parametrului TempCacheLimit la ~40% RAM (dacă este un server dedicat, desigur).
De exemplu, dacă serverul are 16 GB de RAM, atunci puteți pune
TempCacheLimit=6GDesigur, această valoare poate fi setată numai pentru Firebird 64 pe 3 de biți, deoarece orice proces pe 32 de biți nu poate aloca mai mult de 2 gigaocteți de memorie.
În 2.5, acest parametru nu trebuie modificat - oricum nu poate fi mai mare de 2 gigaocteți și nu afectează viteza în timpul copiei de rezervă.
Înainte de a efectua operația, trebuie să verificați dacă memoria cache a paginii din antetul bazei de date este setată la 0 (comandă gstat -h databasename, vezi linia Page buffers).
Dacă memoria cache este setată în mod explicit în antetul bazei de date, atunci acesta înlocuiește valorile de la firebird.conf (și databases.conf în 3.0), iar în cazul unor valori neadecvate mari, poate duce la un consum excesiv de memorie și la schimburi.
Apoi, copiați fișierele în sistemul țintă.
Conversia se efectuează după oprirea serviciului „sistem” Firebird 2.5, pe linia de comandă cu drepturi ridicate pentru administratorul local (exemplu):
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 база30Acest exemplu folosește o „bară oblică” între ghilimele („stil unix” valid), iar o „pălărie” (caracterul „^”) scapă caracterul de linie nouă, ceea ce este util atunci când tastați comenzi lungi. Opțiunea -st(atus) a apărut în Firebird 2.5.8 și vă permite să înregistrați date despre timpul în care a rulat procesul gbak (pentru detalii, consultați documentația).
Linux
Pe Linux Firebird 3 зависит от библиотеки tommath. В CentOS (RHEL) эта библиотека находится в epel-репозитории, в Ubuntu (Debian) в – системном.
Pentru CentOS требуется сначала подключить epel-репозиторий и только потом делать
yum install libtommathUbuntu не нужно подключать дополнительные репозитории, но в Ubuntu 16 și în Ubuntu 18 устанавливаются разные версии пакетов – libtommath0 и libtommath1, соответственно.
Firebird 3.0 ищет tommath.so.0 и для Ubuntu 18 дополнительно требуется создать ссылку (symlink) c tommath.so.0 на tommath.so.1. Для этого сначала надо найти tommath.so.1.
Искомый путь в Ubuntu - /usr/lib/x86_64-linux-gnu/, но в других Debian-based дистрибутивах может быть иначе.
A doua problemă este legată de faptul că până la Firebird 3.0.1 inclusiv, nu a existat o modalitate ușoară de a instala două versiuni diferite de server. Nu luăm în considerare opțiunea „compilați din sursă cu prefixul necesar” din cauza complexității sale relative.
Pentru Firebird 3.0.2 și o versiune ulterioară implementată și o opțiune separată de instalare (-cale cale).
Presupunând că biblioteca tommath și, dacă este necesar, un link simbolic pentru tommath.so.0 au fost adăugate la sistem, puteți instala distribuția curentă (la momentul scrierii acestui articol) Firebird 3.0.4 în, de exemplu, /opt. /fb3:
./install.sh -path /opt/fb3După aceea, puteți opri serviciul de sistem Firebird și puteți începe conversia în flux.
Când opriți Firebird, rețineți că procesele Firebid 2.5 în modul clasic sunt de obicei pornite de xinetd - așa că trebuie fie să dezactivați serviciul firebird pentru xinetd, fie să opriți complet xinetd.
В firebird.conf для 3.0 на Linux не нужно задавать MaxUnflushed-параметры (они работают только на Windows) и менять настройки Firebird 2.5.
В линуксе локальный (файловый) доступ Firebird 2.5 не эквивалентен embeded-варианту под Windows – сервер 2.5 будет работать в процессе gbak (без сетевой части), но права доступа будут проверяться по базе пользователей, а значит, потребуется не только логин, но и пароль:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30După o conversie reușită, trebuie mai întâi să dezinstalați Firebird 3.0 „suplimentar”, apoi Firebird „principal” 2.5 și, după aceea, efectuați o instalare curată a Firebird 2.5 - și este cel mai bine din programul de instalare standard tar.gz, și nu prin intermediul depozite, deoarece. versiunea din depozite poate rămâne în urmă.
Также, после рестора БД на Linux и переустановки надо проверить, чтобы новая БД имела владельцем пользователя firebird.
Dacă nu este cazul, atunci va trebui corectat.
chown firebird.firebird databaseTotal
Pe lângă economisirea de timp și spațiu pe disc, conversia în flux are un alt avantaj important - conversia bazei de date se face fără ștergerea Firebird 2.5 existent, ceea ce simplifică foarte mult rollback-ul în cazul conversiei nereușite (cel mai adesea din cauza lipsei de spațiu sau a repornirii neașteptate în timpul migrării). proces).
Economisirea de timp se datorează faptului că conversia „clasică” este „timp de rezervă” plus „timp de restaurare”. Recuperarea constă din două părți: citirea datelor dintr-un fișier de rezervă și construirea unui index.
Cu conversia în flux, timpul total este obținut ca „timp de rezervă plus cinci până la zece procente” și „timp de construire a indexului”.
Rezultatele specifice depind de structura bazei de date, dar, în medie, timpul de recuperare este de aproximativ dublu față de timpul de rezervă. Prin urmare, dacă luăm timpul de rezervă ca unitate, atunci „conversia clasică” este de trei unități de timp, streaming este de două unități de timp. Creșterea TempCacheLimit ajută la reducerea și mai mult timp.
În general, conversia în flux în practică vă permite să economisiți 30-40% din timpul de backup și restaurare alternativ.
Întrebări?
Vă rugăm să scrieți toate întrebările în comentarii sau să le trimiteți autorului metodologiei și co-autorului acestui articol - Vasily Sidorov, iBase Leading System Engineer, la bs at ibase ru.
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Ce versiune de Firebird folosești?
Firebird 3.x
Firebird xnumx
Firebird xnumx
Firebird 2.0, 1.5 sau 1.0
Au votat 16 utilizatori. 1 utilizator s-a abținut.
Sursa: www.habr.com
