Elke weergawe van Firebird het sy eie weergawe van die databasisskyfstruktuurformaat - O(n)D(isk)S(tructure). Tot en met weergawe 2.5, kon die Firebird-enjin met ODS van vorige weergawes werk, dit wil sê, databasisse van ou weergawes is deur die nuwe weergawe oopgemaak en in versoenbaarheidsmodus gewerk, maar die Firebird 3.0-enjin werk net met databasisse in sy eie ODS-weergawe 12.0.
Om na 3.0 oor te skakel, moet die databasis vanaf 2.5 omgeskakel word na die nuwe formaat via rugsteun/herstel. Natuurlik neem ons aan dat die databasis voorheen voorberei is vir omskakeling - m.a.w. metadata en navrae is nagegaan vir versoenbaarheid met Firebird 3.0.
As jy die standaardbenadering volg, beteken dit dat jy 'n rugsteun op weergawe 2.5 moet maak, dan 3.0 moet installeer en 'n herstel moet maak. Hierdie prosedure is aanvaarbaar as jy genoeg tyd het, maar wanneer jy groot databasisse migreer, of wanneer jy gelyktydig etlike dosyn databasisse migreer, wanneer die tyd min raak, kan jy stroomomskakeling gebruik, wat 30-40% vinniger is. Hoe presies om dit te doen (onder Windows en Linux), lees onder die snit.
Die algemene idee is dat ons 'n pyplyn sal gebruik om dinge te bespoedig:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak vanaf 2.5 genereer 'n rugsteun in lineêre formaat en stuur dit na stdout, wat dadelik gbak vanaf 3.0 via stdin optel en 'n nuwe databasis skep.
Dit is noodsaaklik om so 'n pyplyn te organiseer deur 'n plaaslike (lêer) toegangsmetode te gebruik, aangesien netwerktoegang (selfs deur localhost) die proses aansienlik sal vertraag.
Hieronder kyk ons na die besonderhede vir Windows en Linux.
Windows
In die geval van Windows is die maklikste manier om 'n heeltemal selfstandige bou van Firebird te maak. Hiervoor neem ons , hernoem fbemded.dll na fbclient.dll, voeg die "gewone" 2.5-nutsprogram gbak.exe en (opsioneel) isql.exe uit die argief by.
Firebird 3.0 gebruik en vereis geen wysiging nie.
Die mees minimale opsie (wat nie die installering van die VS2008/VS2010-looptydbiblioteke op die teikenstelsel vereis nie) bevat die volgende lêers:
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'n Ervare administrateur sal dalk agterkom dat 2.5 nie die intl/fbintl.dll- en intl/fbintl.conf-lêers insluit nie. Dit is waar omdat gbak nie die konneksie-karakterset gebruik nie en nie data tussen karakterstelle omskakel nie, maar aan die "ontvangende" kant van Firebird 3.0 is hierdie lêers nodig wanneer indekse geskep word.
In Firebird 3.0 firebird.conf word dit aanbeveel om by te voeg:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Dit is ook raadsaam om verskillende IpcName-waardes vir 2.5 en 3.0 in te stel.
Wanneer ons die waardes van ander firebird.conf-parameters kies, gaan ons uit van 'n eenvoudige oorweging: by die data-oordragstadium loop gbak 2.5 in een proses, en 3.0 loop in 'n ander, dan voltooi 2.5 sy werk, en 3.0 begin indekse te bou.
Om die indeksboufase in 3.0 te bespoedig, word dit aanbeveel om die grootte van die TempCacheLimit-parameter tot ~40% RAM te verhoog (as dit natuurlik 'n toegewyde bediener is).
Byvoorbeeld, as die bediener 16 GB RAM het, kan jy dit stel
TempCacheLimit=6GNatuurlik kan hierdie waarde slegs vir 64-bis Firebird 3 gestel word, aangesien enige 32-bis proses nie meer as 2 gigagrepe geheue sal kan toeken nie.
Vir 2.5 hoef hierdie parameter nie verander te word nie - dit kan in elk geval nie meer as 2 gigagrepe wees nie, en selfs tydens rugsteun beïnvloed dit nie die spoed nie.
Voordat u die bewerking uitvoer, moet u seker maak dat die bladsykas in die databasisopskrif op 0 gestel is (opdrag gstat -h databasename, sien die bladsybuffersreël).
As die kas eksplisiet in die databasisopskrif gestel is, ignoreer dit die waardes van firebird.conf (en databases.conf in 3.0), en in die geval van onvanpas groot waardes, kan dit lei tot onnodige geheueverbruik en stoor in ruil.
Kopieer dan die lêers na die teikenstelsel.
Die omskakeling word uitgevoer nadat die Firebird 2.5-“stelsel”-diens gestop is, in die opdragreël met regte verhef tot plaaslike administrateur (voorbeeld):
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 база30Hierdie voorbeeld gebruik 'n "voorwaartse skuinsstreep" in aanhalingstekens (geldige "unix-styl"), en 'n "hoed" (die "^" karakter) ontsnap die lynvoerkarakter, wat gerieflik is wanneer lang opdragte tik. Die -st(atus)-opsie het in Firebird 2.5.8 verskyn en laat jou toe om data oor die looptyd van die gbak-proses aan te teken (besonderhede in die dokumentasie).
Linux
Op Linux hang Firebird 3 af van die tommath-biblioteek. In CentOS (RHEL) is hierdie biblioteek in die epel-bewaarplek geleë, in Ubuntu (Debian) in die stelselbewaarplek.
Vir CentOS moet jy eers die epel-bewaarplek koppel en dan eers doen
yum install libtommathUbuntu hoef nie bykomende bewaarplekke te koppel nie, maar Ubuntu 16 en Ubuntu 18 installeer verskillende weergawes van die pakkette - onderskeidelik libtommath0 en libtommath1.
Firebird 3.0 soek tommath.so.0 en vir Ubuntu 18 word dit ook vereis om 'n simboliek van tommath.so.0 na tommath.so.1 te skep. Om dit te doen, moet jy eers tommath.so.1 vind.
Die pad waarna jy soek in Ubuntu is - /usr/lib/x86_64-linux-gnu/, maar dit kan anders wees in ander Debian-gebaseerde verspreidings.
Die tweede probleem spruit uit die feit dat daar tot Firebird 3.0.1, ingesluit, geen maklike manier was om twee verskillende weergawes van die bediener te installeer nie. Ons oorweeg nie die opsie "samestel uit bronne met die vereiste voorvoegsel" nie weens die relatiewe arbeidsintensiteit daarvan.
Geïmplementeer vir Firebird 3.0.2 en hoër en 'n aparte installeerder opsie (-pad pad).
Met die veronderstelling dat die tommath-biblioteek en, indien nodig, 'n simlink vir tommath.so.0 by die stelsel gevoeg is, kan jy die huidige (ten tyde van die skryf van hierdie artikel) Firebird 3.0.4-verspreiding in byvoorbeeld / installeer opt/fb3:
./install.sh -path /opt/fb3Hierna kan u die Firebird-stelseldiens stop en begin omskakeling te stroom.
Wanneer jy Firebird stop, moet jy in ag neem dat Firebid 2.5-prosesse in Classic-modus gewoonlik deur xinetd geloods word - daarom moet jy óf die firebird-diens vir xinetd deaktiveer óf xinetd heeltemal stop.
In firebird.conf vir 3.0 op Linux hoef jy nie MaxUnflushed-parameters in te stel nie (hulle werk net op Windows) en Firebird 2.5-instellings te verander.
Op Linux is plaaslike (lêer) toegang van Firebird 2.5 nie gelykstaande aan die ingebedde weergawe onder Windows nie - bediener 2.5 sal in die gbak-proses loop (sonder die netwerkdeel), maar toegangsregte sal teen die gebruikersbasis gekontroleer word, wat beteken dat jy sal nie net 'n aanmelding nodig hê nie, maar ook 'n wagwoord:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30Na suksesvolle omskakeling moet jy eers die “addisionele” Firebird 3.0 verwyder, dan die “hoof” Firebird 2.5, en daarna 'n skoon installasie van Firebird 2.5 uitvoer - die beste van alles vanaf die standaard tar.gz installeerder, en nie deur bewaarplekke nie, want Die weergawe in die bewaarplekke kan agterbly.
Ook, nadat jy die databasis op Linux herstel en dit weer geïnstalleer het, moet jy seker maak dat die nuwe databasis deur die firebird-gebruiker besit word.
As dit nie die geval is nie, sal dit reggestel moet word
chown firebird.firebird databaseTotale
Benewens die besparing van tyd en skyfspasie, het stroomomskakeling nog 'n belangrike voordeel - die databasisomskakeling word gedoen sonder om die bestaande Firebird 2.5 te verwyder, wat dit baie makliker maak om terug te rol as die omskakeling misluk (meestal as gevolg van 'n gebrek aan spasie of 'n onverwagte herlaai tydens die migrasieproses).
Die tydbesparing is te danke aan die feit dat die "klassieke" omskakeling "rugsteuntyd" plus "hersteltyd" is. Herstel bestaan uit twee dele: die lees van data vanaf die rugsteunlêer en die bou van 'n indeks.
Met deurlopende omskakeling word die totale tyd verkry as "rugsteuntyd plus vyf tot tien persent" en "indekskonstruksietyd."
Spesifieke resultate hang af van die struktuur van die databasis, maar gemiddeld is die hersteltyd ongeveer gelyk aan dubbel die rugsteuntyd. Daarom, as ons rugsteuntyd as 'n eenheid neem, dan is "klassieke omskakeling" drie eenhede tyd, en deurlopende omskakeling is twee tydeenhede. Die verhoging van TempCacheLimit help om tyd verder te verminder.
Oor die algemeen laat inlyn-omskakeling jou in die praktyk toe om 30-40% van die tyd wat nodig is vir alternatiewe rugsteun en herstel te bespaar.
Vrae?
Skryf asseblief alle vrae in die kommentaar, of stuur dit aan die skrywer van die metodologie en mede-outeur van hierdie artikel - Vasily Sidorov, toonaangewende stelselingenieur by iBase, by bs at ibase ru.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Watter weergawe van Firebird gebruik jy?
-
Firebird 3.x
-
Vuurvoël 2.5
-
Vuurvoël 2.1
-
Firebird 2.0, 1.5 of 1.0
16 gebruikers het gestem. 1 gebruiker het buite stemming gebly.
Bron: will.com