Transflua konvertiĝo de Firebird 2.5-datumbazoj al ODS12-formato (Firebird 3.0)

Ĉiu versio de Firebird havas sian propran version de la datumbaza diskstrukturformato, O(n)D(isk)S(strukturo). Ĝis la versio 2.5 inkluzive, la Firebird-motoro povis funkcii kun ODS de antaŭaj versioj, tio estas, datumbazoj de malnovaj versioj estis malfermitaj per la nova versio kaj funkciis en kongrueco, sed la Firebird 3.0-motoro funkcias nur kun datumbazoj en sia propra ODS-versio. 12.0.

Por migri al 3.0, la datumbazo de 2.5 devas esti konvertita al la nova formato per sekurkopio/restarigo. Kompreneble, ni supozas, ke la datumbazo antaŭe estis preta por konvertiĝo - t.e. metadatenoj kaj demandoj estis kontrolitaj por kongruo kun Firebird 3.0.

Se vi sekvas la norman aliron, tio signifas, ke vi devas fari sekurkopion en la versio 2.5, poste instali 3.0 kaj restarigi. Tia proceduro estas akceptebla se estas sufiĉe da tempo, sed dum migrado de grandaj datumbazoj, aŭ dum migrado de pluraj dekoj da datumbazoj samtempe, kiam tempo finiĝas, vi povas uzi streaming-konverton, kiu estas 30-40% pli rapida. Kiel ĝuste fari tion (sub Vindozo kaj sub Linukso), legu sub la tranĉo.

La ĝenerala ideo estas, ke ni uzos dukton por akceli aferojn:

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

Gbak de 2.5 generas sekurkopion en lineara formato kaj sendas ĝin al stdout, kiu tuj prenas gbak de 3.0 per stdin kaj kreas novan datumbazon.

Estas necese organizi tian dukton per loka (dosiera) alirmetodo, ĉar retaliro (eĉ per localhost) signife malrapidigos la procezon.

Ni ekzamenas la detalojn por Vindozo kaj Linukso sube.

fenestroj

En la kazo de Vindozo, la plej facila maniero estas fari tute memstaran konstruon de Firebird. Por ĉi tio ni prenas embed-archive Firebird 2.5, renomu fbemded.dll al fbclient.dll, aldonu gbak.exe kaj (laŭvole) isql.exe ilojn el la "regula" 2.5-arkivo.

Firebird 3.0 uzas ununura asembleo kaj ne postulas ajnan modifon.

La plej minimuma versio (kiu ne postulas instaladon de la rultempaj bibliotekoj VS2008/VS2010 sur la celsistemo) enhavas la jenajn dosierojn:

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

Sperta administranto povas rimarki, ke 2.5 ne inkluzivas la dosierojn intl/fbintl.dll kaj intl/fbintl.conf. Ĉi tio estas vera, ĉar gbak ne uzas konektan signaron kaj ne konvertas datumojn inter signaro, sed ĉe la "ricevanta" flanko de Firebird 3.0, ĉi tiuj dosieroj estas necesaj dum kreado de indeksoj.

En firebird.conf Firebird 3.0 rekomendas aldoni:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Ankaŭ, estas dezirinde agordi malsamajn IpcName-valorojn por 2.5 kaj 3.0.

Elektante la valorojn de aliaj parametroj de firebird.conf, ni procedas de simpla konsidero: en la transfuzo de datumoj, gbak funkcias 2.5 en unu procezo, kaj 3.0 en la alia, tiam 2.5 eliroj, kaj 3.0 komencas konstrui. indeksoj.

Por akceli la indekskonstruan fazon en 3.0, oni rekomendas pliigi la grandecon de la parametro TempCacheLimit al ~40% RAM (se ĝi estas dediĉita servilo, kompreneble).

Ekzemple, se la servilo havas 16 GB de RAM, tiam vi povas meti

TempCacheLimit=6G

Kompreneble, ĉi tiu valoro povas esti agordita nur por 64-bita Firebird 3, ĉar ajna 32-bita procezo ne povas asigni pli ol 2 gigabajtojn da memoro.

En 2.5, ĉi tiu parametro ne bezonas esti ŝanĝita - ĝi ne povas esti pli ol 2 gigabajtoj ĉiukaze, kaj ĝi ne influas la rapidecon dum sekurkopio.

Antaŭ ol fari la operacion, vi devas kontroli, ke la paĝa kaŝmemoro en la datumbaza kaplinio estas agordita al 0 (komando gstat -h databasename, vidu la linion de Paĝaj bufroj).

Se la kaŝmemoro estas fiksita eksplicite en la datumbaza kaplinio, tiam ĝi superas la valorojn de firebird.conf (kaj databases.conf en 3.0), kaj en kazo de neadekvate grandaj valoroj, ĝi povas konduki al troa memorkonsumo kaj interŝanĝado.

Poste kopiu la dosierojn al la cela sistemo.

La konvertiĝo estas efektivigita post ĉesigo de la "sistema" Firebird 2.5-servo, sur la komandlinio kun altigitaj rajtoj al la loka administranto (ekzemplo):

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

Ĉi tiu ekzemplo uzas "antaŭan oblikvon" inter citiloj (valida "unikso-stila"), kaj "ĉapelo" (la "^" signo) eskapas la novlinian signon, kiu estas utila dum tajpado de longaj komandoj. La opcio -st(atus) aperis en Firebird 2.5.8 kaj permesas vin ensaluti datumojn pri la tempo kiam la gbak-procezo funkciis (por detaloj, vidu la dokumentaron).

linux

En Linukso Firebird 3 dependas de la tommath biblioteko. Ĉe CentOS (RHEL) ĉi tiu biblioteko troviĝas en la deponejo epel, ĉe Ubuntu (Debian) en la sistemdeponejo.

Por CentOS, vi unue devas konekti la epel-deponejon kaj nur tiam fari

yum install libtommath

Ubuntu ne bezonas inkluzivi pliajn deponejojn, sed Ubuntu 16 kaj Ubuntu 18 instalas malsamajn versiojn de la pakaĵoj - libtommath0 kaj libtommath1, respektive.

Firebird 3.0 serĉas tommath.so.0 kaj por Ubuntu 18 aldone necesas krei ligon (simbolligo) de tommath.so.0 al tommath.so.1. Por fari tion, vi unue devas trovi tommath.so.1.

Serĉita vojo en Ubuntu - /usr/lib/x86_64-linux-gnu/, sed aliaj Debian-bazitaj distribuoj povas esti malsamaj.

La dua problemo rilatas al tio, ke ĝis kaj inkluzive de Firebird 3.0.1, ne estis facila maniero instali du malsamajn servilversiojn. Ni ne konsideras la opcion "kompili el fonto kun la bezonata prefikso" pro ĝia relativa komplekseco.

Por Firebird 3.0.2 kaj pli alte efektivigita konstrui kun --enable-binreloc kaj aparta instalila opcio (-voja vojo).

Supozante ke la tommath-biblioteko kaj, se necese, simbolligo por tommath.so.0 estis aldonitaj al la sistemo, vi povas instali la nunan (en la momento de ĉi tiu skribado) Firebird 3.0.4 distribuo en, ekzemple, /opt. /fb3:

./install.sh -path /opt/fb3

Post tio, vi povas ĉesigi la Firebird-sisteman servon kaj komenci streaming-konverton.

Ĉesigante Firebird, memoru, ke Firebid 2.5-procezoj en Klasika reĝimo estas kutime komencitaj de xinetd - do vi devas aŭ malŝalti la firebird-servon por xinetd aŭ tute haltigi xinetd.

En firebird.conf por 3.0 en Linukso, vi ne bezonas agordi MaxUnflushed-parametrojn (ili funkcias nur en Vindozo) kaj ŝanĝi Firebird 2.5-agordojn.

En Linukso, Firebird 2.5 loka (dosiera) aliro ne estas ekvivalenta al la enigita versio sub Vindozo - la 2.5-servilo funkcios en la gbak-procezo (sen la retoparto), sed alirrajtoj estos kontrolitaj kontraŭ la uzantbazo, kio signifas ke ne nur la ensaluto, sed ankaŭ la pasvorto estos postulata:

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

Post sukcesa konvertiĝo, vi devas unue malinstali la "aldonan" Firebird 3.0, poste la "ĉefan" Firebird 2.5, kaj post tio fari puran instaladon de Firebird 2.5 - kaj ĝi estas plej bone de la regula instalilo tar.gz, kaj ne per la instalilo. deponejoj, ĉar. la versio en la deponejoj eble postrestis.

Ankaŭ, post restarigo de la datumbazo en Linukso kaj reinstalado, vi devas kontroli, ke la nova datumbazo estas posedata de la uzanto de Firebird.

Se ĉi tio ne estas la kazo, tiam ĝi devos esti korektita.

chown firebird.firebird database

La rezulto

Krom ŝparado de tempo kaj diskospaco, streaming-konverto havas alian gravan avantaĝon - datumbaza konvertiĝo estas farata sen forigo de la ekzistanta Firebird 2.5, kiu multe simpligas retrovon en kazo de malsukcesa konvertiĝo (plej ofte pro manko de spaco aŭ neatendita rekomenco dum la migrado). procezo).

La tempoŝparo estas pro la fakto, ke la "klasika" konvertiĝo estas "rezerva tempo" plus "restartempo". Reakiro konsistas el du partoj: legado de datumoj de rezerva dosiero kaj konstruado de indekso.

Kun streaming-konverto, la tuta tempo akiriĝas kiel "rezerva tempo plus kvin ĝis dek procentoj" kaj "indeksa konstrua tempo".

Specifaj rezultoj dependas de la strukturo de la datumbazo, sed averaĝe, la reakiro estas proksimume duoble la rezerva tempo. Tial, se ni prenas rezervan tempon kiel unuon, tiam "klasika konvertiĝo" estas tri tempounuoj, streaming estas du tempounuoj. Pliigi TempCacheLimit helpas plu redukti la tempon.

Ĝenerale, streaming-konverto praktike permesas vin ŝpari 30-40% de la tempo de alterna sekurkopio kaj restarigo.

Ĉu demandoj?

Bonvolu skribi ĉiujn demandojn en la komentoj, aŭ sendi ilin al la aŭtoro de la metodiko kaj kunaŭtoro de ĉi tiu artikolo - Vasily Sidorov, iBase Leading System Engineer, ĉe bs ĉe ibase ru.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Kiun version de Firebird vi uzas?

• Fajrobirdo 3.x

• Fajrobirdo 2.5

• Fajrobirdo 2.1

• Firebird 2.0, 1.5 aŭ 1.0

Voĉdonis 16 uzantoj. 1 uzanto sindetenis.

fonto: www.habr.com