Firebird 2.5 andmete voogedastamine ODS12 (Firebird 3.0) formaati

Iga Firebird versioonil on oma andmebaasi diskistruktuuride vormingu versioon – O(n)D(isk)S(tructure). Kuni versioonini 2.5 võis Firebird kasutada varasemate versioonide ODS-sid, see tähendab, et vanade versioonide andmebaasid avati uue versiooniga ja töötasid ühilduvuses, kuid Firebird 3.0 töötab ainult andmebaasidega enda ODS versioonis 12.0.

3.0-le ülemiseks tuleb 2.5 andmebaas vormindada uueks formaadiks backup/restore abil. Loomulikult eeldame, et andmebaas on eelnevalt konverteerimiseks ette valmistatud – st metaandmed ja päringud on kontrollitud Firebird 3.0 ühilduvuse suhtes.

Kui järgida standardset lähenemist, tähendab see, et tuleb teha varukoopia versioonist 2.5, seejärel paigaldada 3.0 ja teha taastamine. See menetlus on vastuvõetav, kui on piisavalt aega, kuid suurte andmebaaside migreerimisel või korraga mitme kümne andmebaasi migreerimisel, kui aeg on õhus, võib kasutada vooluhulgakonversiooni, mis on 30-40% kiirem. Kuidas täpselt seda teha (Windowsi ja Linuxi all), loe allpool.

Üldine idee on see, et kiirus kasuks tulemiseks kasutame torujuhet:

gbak -b … andmebaas25 stdout | gbak -c … stdin andmebaas30

Gbak versioonilt 2.5 genereerib varukoopia jooneformaadis ja suunab selle stdout'isse, mille gbak versioon 3.0 haarab kohe stdin'ist ja loob uue andmebaasi.

Sellise torujuhtme korraldamine tuleb kindlasti teha kohalikult (faili) meetodil, kuna võrguühendus (isegi localhost'i kaudu) aeglustab märgatavalt protsessi.

Allpool käsitleme üksikasju Windowsi ja Linuxi kohta.

Windows

Windowsi puhul on kõige lihtsam teha täielikku iseseisvat Firebird kogumit. Selleks võtame Firebird 2.5 embed-arhiivi, muudame fbemded.dll nime fbclient.dll-iks, lisame arhiivist „tavalise” 2.5 utiliidi gbak.exe ja (valikuline) – isql.exe.

Firebird 3.0 kasutab ühtset kogumit ja ei vaja mingit täiendavat seadistamist.

Kõige minimaalne variant (mis ei vaja VS2008/VS2010 jooksutegurite raamatukogusid sihtsüsteemis) sisaldab järgmisi faile:

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

Kogen administrator suudab märgata, et 2.5 versioonis ei ole faile intl/fbintl.dll ja intl/fbintl.conf. See on tõepoolest nii, kuna gbak ei kasuta ühenduse karakteristikku ja ei konverteeri andmeid erinevate karakteristikute vahel, kuid Firebird 3.0 "vastuvõtul" on need failid vajalikud indeksite loomisel.

Firebird 3.0 seadistustes firebird.conf soovitatakse lisada:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Samuti on soovitatav määrata erinevad IpcName väärtused versioonidele 2.5 ja 3.0.

Muud mõõtmete valides firebird.conf lähtume lihtsast põhimõttest: andmete muutmisprotsessis töötab ühes protsessis gbak 2.5, teises – 3.0, seejärel lõpetab 2.5 töö ja 3.0 alustab indeksite loomist.

Indeksite loomise etapi kiirendamiseks 3.0 soovitatakse suurendada TempCacheLimiti väärtust ~40% RAM-ist (kui see on dedikeeritud server, loomulikult).

Näiteks, kui serveril on 16 GB RAM-i, võib seada

TempCacheLimit=6G

Loomulikult võib sellist väärtust kasutada alles 64-bitise Firebird 3 korral, kuna ükski 32-bitine protsess ei saa eraldada enam kui 2 gigabaiti mälu.

Versioonis 2.5 seda parameetrit muuta ei ole vaja - see ei saa niikuinii olla suurem kui 2 gigabaiti ning backup'i kiirus sellele ei mõju.

Enne toimingu sooritamist tuleb kontrollida, et andmebaasi pealkirjas on lehekülje vahemälu seadistatud väärtusele 0 (käsk gstat -h andmebaasinimi, vaata rida Page buffers).

Kui vahemälu on andmebaasi pealkirjas selgelt määratud, siis see ületab väärtusi firebird.conf-s (ja databases.conf-s versioonis 3.0) ning ebanormaalselt suurte väärtuste korral võib see põhjustada liigset mälu kasutamist ja swap'isse minekut.

Seejärel kopeerime failid sihtsüsteemi.

Konversioon toimub pärast "süsteemi" teenuse Firebird 2.5 seiskamist, käsureal, tõstes õigusi kohalikuks administreerijaks (näide):

set ISC_USER=omanik
"25/gbak" -z -b -g -v -st t -y 25.log andmebaas25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin andmebaas30

Selles näites kasutatakse "otsest kaldkirja" ülakomade sees (lubatud "unix-style"), ja "kübar" (sümbol "^") varjab reavahetuse sümbolit, mis on mugav pikkade käskude sisestamisel. Valik -st(atus) ilmus Firebird 2.5.8-s ja võimaldab protokollida andmeid gbak'i protsessi aja kohta (detailsed andmed - dokumentatsioonis).

Linux

Linuxis sõltub Firebird 3 tommath raamatukogust. CentOS (RHEL) puhul asub see raamatukogu epel-repositooriumis, Ubuntu (Debian) süsteemis.

CentOS-i jaoks tuleb esmalt aktiveerida epel-reposiit ja alles seejärel tegeleda

yum install libtommath

Ubuntu jaoks ei ole vaja aktiveerida täiendavaid reposiite, kuid Ubuntu 16 ja Ubuntu 18 jaoks installitakse erinevad pakettide versioonid – libtommath0 ja libtommath1, vastavalt.

Firebird 3.0 otsib tommath.so.0 ja Ubuntu 18 jaoks on lisaks vajalik luua lingi (symlink) tommath.so.0 tommath.so.1. Selleks tuleb esmalt leida tommath.so.1.

Otsitav tee Ubuntu-s on /usr/lib/x86_64-linux-gnu/, kuid teistes Debian-põhistes distributsioonides võib see olla erinev.

Teine probleem on seotud sellega, et enne Firebird 3.0.1 ei olnud lihtsat viisi paigaldada kahte erinevat versiooni serverist. Valikut „koostame allikast vajaliku prefiksiga“ me ei aruta, kuna see on suhteliselt töömahukas.

Firebird 3.0.2 ja uuemate versioonide jaoks on välja töötatud kogumine –enable-binreloc ja eraldi paigaldusvalik (-path tee).

Eeldades, et tommath teek ja vajadusel lingid tommath.so.0 on süsteemi lisatud, saab paigaldada asjakohase (artikli kirjutamise ajal) Firebird 3.0.4 distributsiooni, näiteks /opt/fb3:

./install.sh -path /opt/fb3

Pärast seda saab peatada Firebirdi süsteemiteenuse ja alustada voolava konverteerimisega.

Firebirdi peatamisel tuleb arvestada, et Firebid 2.5 töötab Classic-režiimis tavaliselt xinetd kaudu – seega tuleb kas keelata firebird teenus xinetd jaoks või peatada xinetd täielikult.

firebird.conf-is 3.0 Linuxis ei ole vaja määrata MaxUnflushed parameetreid (need töötavad ainult Windowsis) ega muuta Firebird 2.5 seadeid.

Linuxis ei ole Firebird 2.5 kohaliku (faili) juurdepääsu ekvivalent embeded-versioonile Windowsis – server 2.5 töötab protsessis gbak (ilma võrguta), kuid juurdepääsuõigusi kontrollitakse kasutajate baasi järgi, mis tähendab, et on vajalik mitte ainult kasutajanimi, vaid ka parool:

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

Pärast eduka konverteerimise lõpetamist tuleb esmalt eemaldada „lisakuline“ Firebird 3.0, seejärel „põhiline“ Firebird 2.5 ja alles pärast seda teostada puhas Firebird 2.5 installatsioon – kõige parem oleks kasutada standardset paigaldajat tar.gz, mitte reposiitide kaudu, kuna reposiitides olev versioon võib olla aeguv.

Samuti tuleb pärast andmebaasi taastamist Linuxis ja uuesti paigaldamist kontrollida, et uus andmebaas omaks omanikuks kasutajat firebird.

Kui see nii ei ole, tuleb see parandada

chown firebird.firebird database

Kokkuvõte

Lisaks ajas ja ketta ruumi kokkuhoidmisele on voolava teisendamise teine oluline eelis see, et andmebaasi teisendamine toimub ilma olemasoleva Firebird 2.5 eemaldamiseta, mis lihtsustab oluliselt tagasipöördumist ebaõnnestumise korral (enamasti seoses ketasruumi puudumise või ootamatu taaskäivitamisega migratsiooni ajal).

Aja kokkuhoid tuleneb sellest, et «klassikaline» teisendamine on «varundamise aeg» pluss «taastamise aeg». Taastamine koosneb kahest osast: andmete lugemine varundusfailist ja indeksi koostamine.

Voolava teisendamise korral on kokkuvõttes aeg «varundamise aeg pluss viis-kümme protsenti» ja «indeksite koostamise aeg».

Konkreetne tulemus sõltub andmebaasi struktuurist, kuid keskmiselt on taastamisaeg umbes kaks korda suurem kui varundamise aeg. Seega, kui võtta varundamise aeg ühe ühikuna, on «klassikaline teisendamine» kolm ühikut aega, voolav teisendamine aga kaks ühikut aega. Aega aitab täiendavalt vähendada TempCacheLimit'i suurendamine.

Üldiselt võimaldab voolav teisendamine praktikaliselt säästa 30-40% järjestikkuse varundamise ja taastamise ajast.

Küsimusi?

Palun esitage kõik küsimused kommentaarides või saatke autorile ja selle artikli kaasautorile – Vasili Sidorovile, ettevõtte «iBase» peamisele süsteemitehnikule, aadressil bs at ibase ru.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Millist versiooni Firebirdi kasutate?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 või 1.0

Hääletanud 16 kasutajat. 1 kasutaja jäi erapooletuks.

Allikas: habr.com