Firebird 2.5 datu-baseen erreprodukzioa ODS12 formatura (Firebird 3.0)

Firebird-en bertsio bakoitzak bere datu-basearen disko egituraren formatuaren bertsioa du, O(n)D(isk)S(egitura). 2.5 bertsiora arte, Firebird motorrak aurreko bertsioen ODSekin lan egin zezakeen, hau da, bertsio zaharretako datu-baseak bertsio berriak ireki eta bateragarritasun moduan funtzionatzen zuen, baina Firebird 3.0 motorrak bere ODS bertsioko datu-baseekin bakarrik funtzionatzen du. 12.0.

3.0ra migratzeko, 2.5etik aurrera datu-basea formatu berrira bihurtu behar da babeskopia/berreskuratu bidez. Jakina, datu-basea aldez aurretik bihurtzeko prestatuta zegoela suposatzen dugu - hau da. metadatuak eta kontsultak Firebird 3.0-rekin bateragarri direla egiaztatu da.

Ikuspegi estandarra jarraitzen baduzu, horrek esan nahi du 2.5 bertsioan babeskopia egin behar duzula, ondoren 3.0 instalatu eta leheneratu. Prozedura hori onargarria da denbora nahikoa badago, baina datu-base handiak migratzerakoan edo aldi berean dozena bat datu-base migratzerakoan, denbora agortzen ari denean, streaming bihurketa erabil dezakezu, hau da, % 30-40 azkarragoa. Nola egin zehatz-mehatz hau (Windows-en eta Linux-en), irakurri ebakiaren azpian.

Ideia orokorra da kanalizazio bat erabiliko dugula gauzak azkartzeko:

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

Gbak 2.5etik aurrera babeskopia bat sortzen du formatu linealean eta stdout-era bidaltzen du, honek berehala jasotzen du gbak 3.0tik stdin bidez eta datu-base berri bat sortzen du.

Beharrezkoa da kanalizazio bat tokiko (fitxategi) sarbide-metodo batekin antolatzea, sarerako sarbideak (nahiz eta localhost bidez) prozesua nabarmen motelduko baitu.

Windows eta Linuxen xehetasunak behean aztertuko ditugu.

Windows

Windows-en kasuan, modurik errazena Firebird-en eraikuntza guztiz autonomoa egitea da. Horretarako hartzen dugu embed-archive Firebird 2.5, aldatu izena fbemded.dll fbclient.dll, gehitu gbak.exe eta (aukeran) isql.exe utilitateak 2.5 "ohiko" artxibotik.

Firebird 3.0 erabilerak muntaia bakarra eta ez du inolako aldaketarik behar.

Bertsio minimoenak (helburuko sisteman VS2008/VS2010 exekuzio-liburutegiak instalatu behar ez dituenak) fitxategi hauek ditu:

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

Esperientziadun administratzaile batek ohartuko da 2.5-ek ez dituela intl/fbintl.dll eta intl/fbintl.conf fitxategiak sartzen. Hau egia da, gbak-ek ez baitu konexio-karaktere-multzorik erabiltzen eta ez baitu karaktere-multzoen arteko datuak bihurtzen, baina Firebird 3.0-ren "jasotzailea" aldean, fitxategi hauek beharrezkoak dira indizeak sortzerakoan.

Firebird.conf-en Firebird 3.0-n gehitzea gomendatzen da:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Gainera, komeni da IpcName balio desberdinak ezartzea 2.5 eta 3.0rako.

Firebird.conf-en beste parametro batzuen balioak aukeratzerakoan, gogoeta sinple batetik abiatuko gara: datuen transfusio-fasean, gbak 2.5 exekutatzen du prozesu batean, eta 3.0 bestean, gero 2.5 irteten da eta 3.0 eraikitzen hasten da. aurkibideak.

3.0-n indizea eraikitzeko fasea bizkortzeko, TempCacheLimit parametroaren tamaina ~% 40 RAMera handitzea gomendatzen da (zerbitzari dedikatu bat bada, noski).

Adibidez, zerbitzariak 16 GB RAM baditu, orduan jarri dezakezu

TempCacheLimit=6G

Noski, balio hau 64 biteko Firebird 3rako bakarrik ezar daiteke, 32 biteko edozein prozesuk ezin baitu 2 gigabyte baino gehiago memoria esleitu.

2.5-en, parametro hau ez da aldatu behar; hala ere, ezin du 2 gigabyte baino gehiago izan, eta ez dio abiadurari eragiten babeskopian zehar.

Eragiketa egin aurretik, datu-basearen goiburuko orrialde-cachea 0-n ezarrita dagoela egiaztatu behar duzu (komandoa gstat -h databasename, ikusi Orrialde buffer lerroa).

Cachea datu-basearen goiburuan esplizituki ezartzen bada, firebird.conf-en balioak gainidazten ditu (eta databases.conf 3.0-n), eta balio handi desegokirik izanez gero, gehiegizko memoria-kontsumoa eta trukatzea ekar dezake.

Ondoren, kopiatu fitxategiak xede-sistemara.

Bihurketa "sistema" Firebird 2.5 zerbitzua gelditu ondoren egiten da, tokiko administratzailearentzat eskubide altuak dituen komando-lerroan (adibidea):

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

Adibide honek "aurrerantzeko barra" erabiltzen du komatxoen artean (baliozkoa "unix-estiloa"), eta "txapelak" ("^" karaktereak) lerro berriko karaktereari ihes egiten dio, eta hori erabilgarria da komando luzeak idaztean. -st(atus) aukera Firebird 2.5.8-n agertu zen eta gbak prozesua exekutatzen ari zen denborari buruzko datuak erregistratzeko aukera ematen du (xehetasunetarako, ikusi dokumentazioa).

Linux

Linux-en Firebird 3 tommath liburutegiaren araberakoa da. CentOS-en (RHEL) liburutegi hau epel biltegian dago, Ubuntun (Debian) sistemaren biltegian.

CentOS-erako, lehenik epel biltegia konektatu behar duzu eta ondoren bakarrik egin

yum install libtommath

Ubuntuk ez du biltegi gehigarririk sartu behar, baina Ubuntu 16 eta Ubuntu 18-ek paketeen bertsio desberdinak instalatzen dituzte - libtommath0 eta libtommath1, hurrenez hurren.

Firebird 3.0-k tommath.so.0 bilatzen du eta Ubuntu 18rako, gainera, tommath.so.0-tik tommath.so.1-era esteka bat (esteka sinbolikoa) sortzea beharrezkoa da. Horretarako, lehenengo tommath.so.1 aurkitu behar duzu.

Ubuntun bilatutako bidea - /usr/lib/x86_64-linux-gnu/, baina Debian oinarritutako beste banaketa batzuk desberdinak izan daitezke.

Bigarren arazoa Firebird 3.0.1-era arte eta barne, bi zerbitzari-bertsio desberdin instalatzeko modu errazik ez zegoelako lotuta dago. Ez dugu kontuan hartzen "iturburutik konpilatu behar den aurrizkiarekin" aukera bere konplexutasun erlatiboa dela eta.

Firebird 3.0.2 eta berriagoa inplementatu da eraiki --enable-binreloc-ekin eta instalatzailearen aukera bereizi bat (-path bidea).

Tommath liburutegia eta, behar izanez gero, tommath.so.0-rako esteka sinboliko bat sisteman gehitu direla suposatuz, uneko (hau idazteko unean) Firebird 3.0.4 banaketa instala dezakezu, adibidez, /opt. /fb3:

./install.sh -path /opt/fb3

Horren ondoren, Firebird sistemaren zerbitzua geldi dezakezu eta erreproduzitzeko bihurketa has dezakezu.

Firebird gelditzean, kontuan izan Firebid 2.5 prozesuak modu klasikoan normalean xinetd-ek abiarazten dituela; beraz, firebird zerbitzua xinetd-erako desgaitu edo xinetd guztiz gelditu behar duzu.

Linux-en firebird.conf 3.0-n, ez duzu MaxUnflushed parametroak ezarri behar (Windows-en bakarrik funtzionatzen dute) eta Firebird 2.5-en ezarpenak aldatu behar.

Linux-en, Firebird 2.5 tokiko (fitxategi) sarbidea ez da Windows-en kapsulatutako bertsioaren baliokidea - 2.5 zerbitzaria gbak prozesuan exekutatuko da (sareko zatirik gabe), baina sarbide-eskubideak erabiltzaile-basearen arabera egiaztatuko dira, hau da, saioa hasteko ez ezik, pasahitza ere eskatuko da:

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

Bihurketa arrakastatsua egin ondoren, lehenik Firebird 3.0 "gehigarria" desinstalatu behar duzu, ondoren Firebird 2.5 "nagusia", eta horren ondoren Firebird 2.5 instalazio garbi bat egin behar duzu - eta hobe da tar.gz instalatzaile arruntetik, eta ez bidez. biltegiak, zeren. biltegietako bertsioa atzean geratu daiteke.

Gainera, Linux-en datu-basea leheneratu eta berriro instalatu ondoren, datu-base berria firebird erabiltzailearen jabetzakoa dela egiaztatu behar duzu.

Hori horrela ez bada, zuzendu egin beharko da.

chown firebird.firebird database

Guztira

Denbora eta diskoko espazioa aurrezteaz gain, streaming-en bihurketak beste abantaila garrantzitsu bat du - datu-basearen bihurketa lehendik dagoen Firebird 2.5 ezabatu gabe egiten da, eta horrek asko errazten du atzerapena arrakastarik gabeko bihurketa gertatzen bada (gehienetan leku faltagatik edo migrazioan ustekabeko berrabiarazteagatik). prozesua).

Denbora aurreztea "klasikoa" bihurketa "backup denbora" gehi "berreskuratze denbora" delako da. Berreskuratzeak bi zati ditu: babeskopia fitxategi bateko datuak irakurtzea eta indize bat sortzea.

Streaming bihurketarekin, denbora osoa "backup denbora gehi ehuneko bost-hamar" eta "indizea eraikitzeko denbora" gisa lortzen da.

Emaitza zehatzak datu-basearen egituraren araberakoak dira, baina, batez beste, berreskuratzeko denbora babeskopia denboraren bikoitza da gutxi gorabehera. Hori dela eta, babeskopia-denbora unitate gisa hartzen badugu, "bihurketa klasikoa" hiru denbora-unitate da, streaming-a bi denbora-unitate da. TempCacheLimit handitzeak denbora gehiago murrizten laguntzen du.

Oro har, streaming bihurketak praktikan aukera ematen du ordezko babeskopien eta leheneratzeko denboraren % 30-40 aurrezteko.

Galderarik?

Mesedez, idatzi galdera guztiak iruzkinetan, edo bidali metodologiaren egileari eta artikulu honen egilekideari - Vasily Sidorov, iBase Leading System Engineer, bs at ibase ru.

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Firebird-en zein bertsio erabiltzen ari zara?

• Firebird 3.x

• Suzko txoria 2.5

• Suzko txoria 2.1

• Firebird 2.0, 1.5 edo 1.0

16 erabiltzailek eman dute botoa. Erabiltzaile 1 abstenitu egin zen.

Iturria: www.habr.com