Hver version af Firebird har sin egen version af diskstrukturformatet – O(n)D(isk)S(tructure). Indtil version 2.5 kunne Firebird-motoren arbejde med ODS fra tidligere versioner, hvilket betyder, at databaser fra ældre versioner kunne åbnes af den nye version og arbejde i kompatibilitetsmode. Men Firebird 3.0 fungerer kun med databaser i sin egen ODS version 12.0.
For at opgradere til 3.0 skal databasen fra 2.5 konverteres til det nye format via backup/restaurering. Selvfølgelig forudsætter vi, at databasen er blevet forberedt til konverteringen – det vil sige, at metadata og forespørgsler er blevet testet for kompatibilitet med Firebird 3.0.
Hvis man følger den standard tilgang, betyder det, at man skal lave en backup ved version 2.5, derefter installere 3.0 og foretage en restaurering. Denne procedure er acceptabel, hvis man har tilstrækkeligt med tid, men ved migrering af store databaser, eller ved samtidig migrering af flere dusin databaser, når tiden er knap, kan man anvende streaming konvertering, som er 30-40% hurtigere. Hvordan man gør det (under Windows og Linux), kan du læse om nedenfor.
Den overordnede idé er, at vi vil bruge en pipeline for at accelerere processen:
gbak -b … database25 stdout | gbak -c … stdin database30Gbak fra 2.5 genererer en backup i et lineært format og sender det til stdout, som straks fanges af gbak fra 3.0 via stdin, hvilket skaber en ny database.
Det er nødvendigt at organisere en sådan pipeline med lokal (fil) adgangen, da netværksadgang (selv via localhost) vil sænke hastigheden væsentligt.
Nedenfor diskuterer vi detaljerne for Windows og Linux.
Windows
I tilfælde af Windows er det nemmeste at lave en helt autonom version af Firebird. Til dette tager vi , omdøber fbembedded.dll til fbclient.dll, tilføjer værktøjet gbak.exe fra arkivet af "normal" 2.5 og (valgfrit) – isql.exe.
Firebird 3.0 bruger og kræver ingen tilpasninger.
Den mest minimale version (som ikke kræver installation af runtime-bibliotekerne VS2008/VS2010 på målsystemet) indeholder følgende 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.dllEn erfaren administrator kan bemærke, at intl/fbintl.dll og intl/fbintl.conf ikke er inkluderet i 2.5. Det er faktisk korrekt, da gbak ikke bruger forbindelse charset og ikke konverterer data mellem charsets, men på "modtagelsessiden" kræves disse filer i Firebird 3.0 ved oprettelse af indekser.
Det anbefales at tilføje følgende til firebird.conf for Firebird 3.0:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Det er også ønskeligt at indstille forskellige værdier for IpcName til 2.5 og 3.0.
Når vi vælger værdier for andre parametre i firebird.conf, tager vi udgangspunkt i den enkle betragtning, at i en proces virker gbak i 2.5, mens den i en anden virker i 3.0; derefter afslutter 2.5 sit arbejde, og 3.0 begynder opbygningen af indekser.
For at accelerere indeksopbygningsfasen i 3.0 anbefales det at øge størrelsen på parameteren TempCacheLimit til ca. 40 % RAM (hvis det er en dedikeret server, selvfølgelig).
For eksempel, hvis serveren har 16 GB RAM, kan man sætte
TempCacheLimit=6GSelvfølgelig kan en sådan værdi kun indstilles for 64-bit Firebird 3, da enhver 32-bit proces ikke kan allokere mere end 2 gigabyte hukommelse.
For 2.5 er det ikke nødvendigt at ændre denne parameter – den kan ikke være større end 2 gigabyte, og den påvirker ikke hastigheden under backup.
Før udførelsen af operationen skal du tjekke, at sidecache i databasehovedet er indstillet til 0 (kommandoen gstat -h databasename, se linjen Page buffers).
Hvis cachen er angivet eksplicit i DB-headeren, overskriver den værdierne fra firebird.conf (og databases.conf i 3.0), og i tilfælde af urealistisk store værdier kan det føre til overdreven hukommelsesforbrug og swap.
Dernæst kopierer vi filerne til det ønskede system.
Konverteringen udføres efter stop af "system"-tjenesten Firebird 2.5, i kommandoprompten med hævet rettigheder til lokal administrator (eksempel):
set ISC_USER=ejeren
"25/gbak" -z -b -g -v -st t -y 25.log database25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin database30I dette eksempel bruges "slags" i citationstegn (gældende "unix-style"), mens "caret" (symbolet "^") undgår linjeskift, hvilket er praktisk ved indtastning af lange kommandoer. Muligheden -st(atus) dukkede op i Firebird 2.5.8 og tillader at registrere oplysninger om procesgbaks kørselstid (detaljer – i dokumentationen).
Linux
På Linux afhænger Firebird 3 af tommath-biblioteket. I CentOS (RHEL) findes dette bibliotek i epel-repositoriet, i Ubuntu (Debian) i – systembiblioteket.
For CentOS, you need to first enable the epel repository and only then proceed with
yum install libtommathUbuntu does not require additional repositories, but in Ubuntu 16 and Ubuntu 18, different versions of the packages are installed – libtommath0 and libtommath1, respectively.
Firebird 3.0 looks for tommath.so.0, and for Ubuntu 18, you also need to create a symlink from tommath.so.0 to tommath.so.1. First, you need to find tommath.so.1.
The required path in Ubuntu is /usr/lib/x86_64-linux-gnu/, but it may be different in other Debian-based distributions.
The second issue is that until Firebird 3.0.1, there was no simple way to install two different versions of the server. The option of ‘compiling from source with the desired prefix’ is not considered due to its relative complexity.
For Firebird 3.0.2 and above, a and a separate installer option (-path path) have been implemented.
Assuming that the tommath library and, if necessary, the symlink for tommath.so.0 have been added to the system, you can install the current (as of this writing) distribution of Firebird 3.0.4 in, for example, /opt/fb3:
./install.sh -path /opt/fb3After this, you can stop the Firebird system service and start the streaming conversion.
When stopping Firebird, it should be noted that the Firebird 2.5 processes in Classic mode are usually started by xinetd – so you need to either disable the firebird service for xinetd or stop xinetd completely.
In firebird.conf for 3.0 on Linux, it is not necessary to set MaxUnflushed parameters (they only work on Windows) and to change the settings of Firebird 2.5.
In Linux, local (file) access to Firebird 2.5 is not equivalent to the embedded variant under Windows – server 2.5 will operate in the gbak process (without the network component), but access rights will be checked against the user database, meaning that a username and password will be required:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … database25 stdout
|/opt/fb3/bin/gbak -c … stdin database30After successful conversion, you first need to delete the ‘additional’ Firebird 3.0, then the ‘main’ Firebird 2.5, and only after that perform a clean installation of Firebird 2.5 — and it's best to do this from the standard tar.gz installer, rather than through repositories, since the version in the repositories may be outdated.
Also, after restoring the database on Linux and reinstalling, you need to check that the new database has the firebird user as its owner.
If this is not the case, you will need to fix it
chown firebird.firebird databaseResultat
Udover tids- og pladsbesparelse på disken har den strømmende konvertering endnu en vigtig fordel – databasen konverteres uden at slette den eksisterende Firebird 2.5, hvilket gør det betydeligt lettere at fortryde i tilfælde af en mislykket konvertering (som oftest skyldes utilstrækkelig plads eller en uventet genstart under migrationsprocessen).
Tidsbesparelsen skyldes, at "klassisk" konvertering er lig med "backup-tiden" plus "gengivelsestiden". Gengivelsen består af to dele: læsning af data fra backup-filen og opbygning af indekset.
Ved strømmende konvertering beregnes den samlede tid som "backup-tiden plus fem til ti procent" og "tid til opbygning af indekser".
De specifikke resultater afhænger af databasens struktur, men gennemsnitligt er gengivelsestiden cirka det dobbelte af backup-tiden. Derfor, hvis vi tager backup-tiden som en enhed, så kræver "klassisk konvertering" tre enheder tid, mens den strømmende konvertering kræver to enheder tid. Det hjælper desuden at øge TempCacheLimit for at reducere tiden.
Generelt set tillader strømmende konvertering i praksis en besparelse på 30-40% i tid i forhold til sekventiel backup og gendannelse.
Spørgsmål?
Venligst send alle spørgsmål i kommentarerne, eller kontakt forfatteren af metoden og medforfatteren af denne artikel – Vasily Sidorov, senior systemingeniør hos "iBase", på adressen bs at ibase ru.
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Hvilken version af Firebird bruger du?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 eller 1.0
16 brugere har stemt. 1 bruger har undladt at stemme.
Kilde: habr.com
