Strömmande konvertering av Firebird 2.5-databaser till ODS12-formatet (Firebird 3.0)

Varje version av Firebird har sin egen version av diskstrukturformatet för databasen – O(n)D(isk)S(tructure). Fram till och med version 2.5 kunde Firebird-motorn arbeta med ODS från tidigare versioner, vilket innebar att databaser från gamla versioner öppnades av den nya versionen och kördes i kompatibilitetsläge, men Firebird 3.0 fungerar endast med databaser i sin egen ODS-version 12.0.

För att uppgradera till 3.0 måste databasen från 2.5 omvandlas till det nya formatet genom backup/restore. Självklart förutsätter vi att databasen har förberetts för konvertering – det vill säga att metadata och förfrågningar har kontrollerats för kompatibilitet med Firebird 3.0.

Om man följer den standardmetoden, betyder det att man först säkrar på version 2.5, därefter installerar 3.0 och gör en återställning. En sådan procedur är acceptabel om det finns tillräckligt med tid, men vid migrering av stora databaser, eller vid samtidig migrering av flera dussin databaser, när tiden är knapp, kan man använda strömkonvertering som är 30-40% snabbare. Hur detta görs (på Windows och Linux) kan läsas nedan.

Den allmänna idén är att för att påskynda processen använda en pipeline:

gbak -b … database25 stdout | gbak -c … stdin database30

Gbak från 2.5 genererar en backup i linjärt format och skickar den till stdout, som omedelbart fångas av gbak från 3.0 via stdin och skapar en ny databas.

Det är nödvändigt att organisera en sådan pipeline med lokal (fil)åtkomstmetod, eftersom nätverksåtkomst (även via localhost) avsevärt saktar ner processen.

Nedan behandlar vi detaljerna för Windows och Linux.

Windows

För Windows är det enklast att göra en fullständigt fristående version av Firebird. För detta tar vi embed-archive Firebird 2.5, döp om fbembedded.dll till fbclient.dll, lägg till gbak.exe från "vanlig" 2.5-arkiv och (valfritt) – isql.exe.

Firebird 3.0 använder enhetlig distribution och kräver ingen ytterligare anpassning.

Det mest minimi alternativet (som inte kräver installation av runtime-bibliotek VS2008/VS2010 på målsystemet) innehåller följande filer:

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

En erfaren administratör kan märka att intelfilerna intl/fbintl.dll och intl/fbintl.conf inte ingår i version 2.5. Detta är verkligen fallet, eftersom gbak inte använder anslutningens teckenkodning och inte konverterar data mellan teckenkodningar, men på "mottagarens" sida av Firebird 3.0 är dessa filer nödvändiga vid skapande av index.

Det rekommenderas att lägga till följande i firebird.conf för Firebird 3.0:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Det är också lämpligt att ställa in olika värden för IpcName för version 2.5 och 3.0.

Vid val av värden för andra parametrar i firebird.conf utgår vi från en enkel begrundan: vid överföring av data arbetar gbak i en process med version 2.5, och i en annan med version 3.0, sedan avslutar 2.5 sitt jobb, medan 3.0 börjar bygga index.

För att påskynda indexbyggnadsstadiet i 3.0 rekommenderas det att öka storleken på TempCacheLimit-parametern till ~40% av RAM (om det förstås är en dedikerad server).

Till exempel, om servern har 16 GB RAM kan man ställa in

TempCacheLimit=6G

Självklart kan ett sådant värde endast sättas på 64-bitars Firebird 3, eftersom vilken 32-bitars process som helst inte kan allokera mer än 2 gigabyte minne.

För 2.5 behöver denna parameter inte ändras – den kan ändå inte vara mer än 2 gigabyte och påverkar inte hastigheten vid säkerhetskopiering.

Innan operationen utförs måste det kontrolleras att sidcache i databasens header är inställd på 0 (kommandot gstat -h databasnamn, se raden Page buffers).

Om cachen anges tydligt i DB:s header, så åsidosätter den värdena från firebird.conf (och databases.conf i 3.0), och i fallet med orealistiskt stora värden kan det leda till överdriven minnesanvändning och swapping.

Därefter kopieras filerna till målsystemet.

Konverteringen utförs efter att den "systemmessiga" tjänsten Firebird 2.5 har stoppats, i kommandoraden med lyftning av rättigheter till lokal administratör (exempel):

set ISC_USER=ägare
"25/gbak" -z -b -g -v -st t -y 25.log databas25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin databas30

I detta exempel används "rak sned" inom citat (tillåten "unix-style"), och "hatten" (symbolen "^") skyddar radbytet, vilket är praktiskt vid inmatning av långa kommandon. Alternativet -st(atus) tillkom i Firebird 2.5.8 och gör det möjligt att registrera tidpunkten för processen gbak (detaljer – i dokumentationen).

Linux

På Linux beror Firebird 3 på biblioteket tommath. I CentOS (RHEL) finns detta bibliotek i epel-repositoriet, i Ubuntu (Debian) i – systemet.

För CentOS måste du först aktivera epel-förvaret och sedan köra

yum install libtommath

För Ubuntu behöver du inte aktivera några ytterligare förvar, men i Ubuntu 16 och Ubuntu 18 installeras olika versioner av paketen – libtommath0 och libtommath1, respektive.

Firebird 3.0 söker efter tommath.so.0 och för Ubuntu 18 krävs dessutom att en symbolisk länk (symlink) skapas från tommath.so.0 till tommath.so.1. För detta måste tommath.so.1 först hittas.

Den sökta sökvägen i Ubuntu är /usr/lib/x86_64-linux-gnu/, men i andra Debian-baserade distributioner kan det vara annorlunda.

Det andra problemet är kopplat till det faktum att fram till Firebird 3.0.1 fanns det inget enkelt sätt att installera två olika versioner av servern. Alternativet "kompilera från källkoden med rätt prefix" överväger vi inte på grund av dess relativt stora arbetsinsats.

För Firebird 3.0.2 och senare har en kompilering med –enable-binreloc och en separat installationsval (-path väg) implementerats.

Om vi antar att biblioteket tommath och, om nödvändigt, symboliska länkar för tommath.so.0 har lagts till i systemet, kan den aktuella (vid tidpunkten för denna artikels skrivande) distributionen av Firebird 3.0.4 installeras till exempel i /opt/fb3:

./install.sh -path /opt/fb3

Efter detta kan du stoppa systemtjänsten Firebird och starta den strömmade konverteringen.

Vid stopp av Firebird bör man ta hänsyn till att processerna för Firebird 2.5 i Classic-läget vanligtvis startas av xinetd – så antingen måste Firebird-tjänsten stängas av för xinetd eller så måste xinetd stoppas helt.

I firebird.conf för 3.0 på Linux behöver du inte ange MaxUnflushed-parametrarna (de fungerar endast på Windows) och ändra inställningarna för Firebird 2.5.

I Linux är lokal (fil) åtkomst till Firebird 2.5 inte likvärdig med embedded-versionen på Windows – server 2.5 kommer att arbeta i processen gbak (utan nätverksdel), men åtkomsträttigheterna kommer att kontrolleras av användardatabasen, vilket innebär att både användarnamn och lösenord krävs:

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

Efter en lyckad konvertering behöver du först ta bort "ytterligare" Firebird 3.0, sedan "huvud" Firebird 2.5 och först därefter utföra en ren installation av Firebird 2.5 – helst via den vanliga installationsprogrammet tar.gz, inte genom förvar, eftersom versionen i förvaren kan vara föråldrad.

Dessutom, efter restaurering av databasen på Linux och ominstallation, måste du kontrollera att den nya databasen har användaren firebird som ägare.

Om så inte är fallet måste detta åtgärdas

chown firebird.firebird database

Resultat

Förutom tids- och diskutrymmesbesparingar har den strömmande konverteringen en annan viktig fördel – konverteringen av databasen görs utan att den befintliga Firebird 2.5 tas bort, vilket tydligt förenklar återställningen vid en misslyckad konvertering (oftast på grund av brist på utrymme eller en oväntad omstart under migrationsprocessen).

Tidsbesparingen beror på att "klassisk" konvertering innebär "backup-tid" plus "återställningstid". Återställningen består av två delar: att läsa data från backup-filen och att bygga index.

Vid strömmande konvertering blir den totala tiden "backup-tid plus fem-tio procent" och "indexbyggandet".

De specifika resultaten beror på databasens struktur, men i genomsnitt är återställningstiden ungefär dubbelt så lång som backup-tiden. Så, om vi tar backup-tiden som en enhet, så innebär "klassisk konvertering" tre enheter tid och strömmande konvertering två enheter tid. Att öka TempCacheLimit bidrar också till att förkorta tiden.

Sammanfattningsvis möjliggör strömmande konvertering i praktiken en besparing på 30-40% av tiden för sekventiell backup och restaurering.

Frågor?

Vänligen skriv alla frågor i kommentarsfältet eller skicka dem till metodens författare och medförfattare till denna artikel – Vasily Sidorov, ledande systemingenjör på "iBase", på adressen bs at ibase ru.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Vilken version av Firebird använder du?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 eller 1.0

16 användare har röstat. 1 användare avstod.

Källa: habr.com