Eltse ferzje fan Firebird hat syn eigen ferzje fan de databank skiif struktuer opmaak, O (n) D (isk) S (struktuer). Oant ferzje 2.5 ynklusyf koe de Firebird-motor wurkje mei ODS fan eardere ferzjes, dat is, databases fan âlde ferzjes waarden iepene troch de nije ferzje en wurke yn kompatibiliteitsmodus, mar de Firebird 3.0-motor wurket allinich mei databases yn syn eigen ODS-ferzje 12.0.
Om te migrearjen nei 3.0, moat de databank fan 2.5 wurde omboud nei it nije formaat fia reservekopy / weromsette. Fansels geane wy der fan út dat de databank earder taret is foar konverzje - d.w.s. metadata en queries binne kontrolearre op kompatibiliteit mei Firebird 3.0.
As jo de standert oanpak folgje, betsjut dit dat jo in reservekopy moatte meitsje op ferzje 2.5, dan 3.0 ynstallearje en in weromsette meitsje. Sa'n proseduere is akseptabel as d'r genôch tiid is, mar by it migrearjen fan grutte databases, of by it migrearjen fan ferskate tsientallen databases tagelyk, as de tiid rint, kinne jo streamingkonverzje brûke, dy't 30-40% flugger is. Hoe krekt dit te dwaan (ûnder Windows en ûnder Linux), lês ûnder de besuniging.
It algemiene idee is dat wy in pipeline sille brûke om dingen te rapperjen:
gbak -b … база25 stdout | gbak -c … stdin база30
Gbak fan 2.5 genereart in reservekopy yn in lineêre opmaak en stjoert it nei stdout, dy't fuortendaliks gbak fan 3.0 fia stdin oppakt en in nije databank makket.
It is needsaaklik om sa'n pipeline te organisearjen mei in lokale (bestân) tagong metoade, sûnt netwurk tagong (sels fia localhost) sil gâns fertrage it proses.
Wy geane hjirûnder oer de details foar Windows en Linux.
Windows
Yn it gefal fan Windows is de maklikste manier om in folslein standalone build fan Firebird te meitsjen. Foar dit nimme wy
Firebird 3.0 brûkt
De meast minimale ferzje (dy't gjin ynstallaasje fan 'e VS2008/VS2010 runtime-biblioteken op it doelsysteem fereasket) befettet de folgjende bestannen:
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
In betûfte behearder kin merke dat 2.5 de bestannen intl/fbintl.dll en intl/fbintl.conf net omfettet. Dit is wier, om't gbak gjin ferbiningstekenset brûkt en gjin gegevens konvertearret tusken tekensets, mar oan 'e "ûntfangende" kant fan Firebird 3.0 binne dizze bestannen nedich by it meitsjen fan yndeksen.
Yn firebird.conf wurdt Firebird 3.0 oanrikkemandearre om ta te foegjen:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1
Ek is it winsklik om ferskate IpcName-wearden yn te stellen foar 2.5 en 3.0.
By it kiezen fan de wearden fan oare parameters fan firebird.conf geane wy út fan in ienfâldige konsideraasje: yn it stadium fan gegevenstransfúzje rint gbak 2.5 yn ien proses, en 3.0 yn in oar, dan giet 2.5 út, en 3.0 begjint te bouwen yndeksen.
Om de yndeksboufaze yn 3.0 te rapperjen, wurdt it oanrikkemandearre om de grutte fan 'e TempCacheLimit-parameter te fergrutsjen nei ~40% RAM (as it in tawijd server is, fansels).
Bygelyks, as de tsjinner hat 16 GB RAM, dan kinne jo sette
TempCacheLimit=6G
Fansels kin dizze wearde allinich ynsteld wurde foar 64-bit Firebird 3, om't elk 32-bit proses net mear as 2 gigabyte oan ûnthâld kin tawize.
Yn 2.5 hoecht dizze parameter net te wizigjen - it kin yn elk gefal net mear wêze as 2 gigabyte, en it hat gjin ynfloed op de snelheid by reservekopy.
Foardat jo de operaasje útfiere, moatte jo kontrolearje dat de side-cache yn 'e databasekoptekst is ynsteld op 0 (kommando gstat -h databasename
, sjoch de line Sidebuffers).
As de cache eksplisyt ynsteld is yn 'e databasekoptekst, dan oerskriuwt it de wearden fan firebird.conf (en databases.conf yn 3.0), en yn gefal fan net genôch grutte wearden kin it liede ta oermjittich ûnthâldferbrûk en wikseljen.
Kopiearje dan de bestannen nei it doelsysteem.
De konverzje wurdt útfierd nei it stopjen fan de tsjinst "systeem" Firebird 2.5, op 'e kommandorigel mei ferhege rjochten foar de lokale behearder (foarbyld):
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
Dit foarbyld brûkt in "foarút slash" yn oanhalingstekens (jildich "unix-styl"), en in "hoed" (it "^" karakter) ûntkomt it nijeline-karakter, wat nuttich is by it typen fan lange kommando's. De opsje -st(atus) ferskynde yn Firebird 2.5.8 en lit jo gegevens oanmelde oer de tiid dat it gbak-proses rûn (foar details, sjoch de dokumintaasje).
linux
Op Linux Firebird 3 hinget ôf fan de tommath bibleteek. Op CentOS (RHEL) sit dizze bibleteek yn it epel-repository, op Ubuntu (Debian) yn it systeemrepository.
Foar CentOS moatte jo earst de epel-repository ferbine en pas dan dwaan
yum install libtommath
Ubuntu hoecht gjin ekstra repositories op te nimmen, mar Ubuntu 16 en Ubuntu 18 ynstallearje ferskate ferzjes fan 'e pakketten - respektivelik libtommath0 en libtommath1.
Firebird 3.0 siket efter tommath.so.0 en foar Ubuntu 18 is it ek nedich om in keppeling (symlink) te meitsjen fan tommath.so.0 nei tommath.so.1. Om dit te dwaan, moatte jo earst tommath.so.1 fine.
Paad socht yn Ubuntu - /usr/lib/x86_64-linux-gnu/
, mar oare Debian-basearre distribúsjes kinne oars wêze.
It twadde probleem is relatearre oan it feit dat oant en mei Firebird 3.0.1 gjin maklike manier wie om twa ferskillende serverferzjes te ynstallearjen. Wy beskôgje de opsje "kompilearje fan boarne mei it fereaske foarheaksel" net fanwegen de relative kompleksiteit.
Foar Firebird 3.0.2 en heger ymplementearre
Oannommen dat de tommath bibleteek en, as it nedich is, in symlink foar tommath.so.0 oan it systeem tafoege binne, kinne jo de aktuele (op it momint fan dit skriuwen) Firebird 3.0.4-distribúsje yn bygelyks /opt ynstallearje /fb3:
./install.sh -path /opt/fb3
Dêrnei kinne jo stopje de Firebird systeem tsjinst en begjinne streaming konverzje.
As jo Firebird stopje, hâld dan yn gedachten dat Firebid 2.5-prosessen yn Klassike modus normaal wurde begon troch xinetd - dus jo moatte de firebird-tsjinst foar xinetd útskeakelje of xinetd folslein stopje.
Yn firebird.conf foar 3.0 op Linux hoege jo gjin MaxUnflushed-parameters yn te stellen (se wurkje allinich op Windows) en feroarje Firebird 2.5-ynstellingen.
Yn Linux is Firebird 2.5 lokale (bestân) tagong net lykweardich mei de ynbêde ferzje ûnder Windows - de 2.5-tsjinner sil rinne yn it gbak-proses (sûnder it netwurkdiel), mar tagongsrjochten wurde kontrolearre tsjin de brûkersbasis, wat betsjut dat net allinich de oanmelding, mar ek it wachtwurd sil ferplicht wurde:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30
Nei in suksesfolle konverzje moatte jo earst de "oanfoljende" Firebird 3.0 deinstallearje, dan de "haad" Firebird 2.5, en dêrnei in skjinne ynstallaasje fan Firebird 2.5 útfiere - en it is it bêste fan it reguliere tar.gz-ynstallearder, en net troch de repositories, omdat. de ferzje yn 'e repositories kin efterbliuwe.
Ek, nei it weromsetten fan de databank op Linux en opnij ynstallearje, moatte jo kontrolearje dat de nije databank eigendom is fan de firebird-brûker.
As dit net it gefal is, dan sil it korrizjearre wurde moatte.
chown firebird.firebird database
It resultaat
Njonken it besparjen fan tiid en skiifromte hat streamingkonverzje in oar wichtich foardiel - databankkonverzje wurdt dien sûnder de besteande Firebird 2.5 te wiskjen, wat it weromdraaien yn gefal fan mislearre konverzje gâns ferienfâldiget (meastentiids fanwegen gebrek oan romte of ûnferwachte werstart tidens de migraasje proses).
De tiidbesparring komt troch it feit dat de "klassike" konverzje "reservekopytiid" plus "tiid weromsette" is. Herstel bestiet út twa dielen: it lêzen fan gegevens fan in reservekopybestân en it bouwen fan in yndeks.
Mei streaming-konverzje wurdt de totale tiid krigen as "reservekopytiid plus fiif oant tsien prosint" en "yndeksboutiid".
Spesifike resultaten binne ôfhinklik fan 'e struktuer fan' e databank, mar gemiddeld is de hersteltiid sawat twa kear de reservekopytiid. Dêrom, as wy reservekopytiid as ienheid nimme, dan is "klassike konverzje" trije ienheden fan tiid, streaming is twa ienheden fan tiid. It ferheegjen fan TempCacheLimit helpt om de tiid fierder te ferminderjen.
Yn 't algemien kinne streamende konverzje yn' e praktyk jo 30-40% fan 'e tiid besparje fan alternatyf reservekopy en weromsette.
Fragen?
Skriuw asjebleaft alle fragen yn 'e kommentaren, of stjoer se nei de skriuwer fan' e metodyk en mei-auteur fan dit artikel - Vasily Sidorov, iBase Leading System Engineer, by bs at ibase ru.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête.
Hokker ferzje fan Firebird brûke jo?
-
Firebird 3.x
-
Firebird 2.5
-
Firebird 2.1
-
Firebird 2.0, 1.5 of 1.0
16 brûkers stimden. 1 brûker ûnthâlde him.
Boarne: www.habr.com