Strømmekonvertering av Firebird 2.5-databaser til ODS12-format (Firebird 3.0)

Hver versjon av Firebird har sin egen versjon av databasediskstrukturformatet, O(n)D(isk)S(struktur). Opp til versjon 2.5 inklusive, kunne Firebird-motoren fungere med ODS fra tidligere versjoner, det vil si at databaser fra gamle versjoner ble åpnet av den nye versjonen og fungerte i kompatibilitetsmodus, men Firebird 3.0-motoren fungerer kun med databaser i sin egen ODS-versjon 12.0.

For å migrere til 3.0 må databasen fra 2.5 konverteres til det nye formatet via backup/gjenoppretting. Vi antar selvsagt at databasen tidligere var forberedt for konvertering – d.v.s. metadata og spørringer har blitt sjekket for kompatibilitet med Firebird 3.0.

Hvis du følger standardmetoden, betyr dette at du må ta en sikkerhetskopi på versjon 2.5, deretter installere 3.0 og foreta en gjenoppretting. En slik prosedyre er akseptabel hvis det er nok tid, men ved migrering av store databaser, eller ved migrering av flere dusin databaser samtidig, når tiden er i ferd med å renne ut, kan du bruke streamingkonvertering, som er 30-40% raskere. Hvordan du nøyaktig gjør dette (under Windows og under Linux), les under kuttet.

Den generelle ideen er at vi skal bruke en pipeline for å få fart på ting:

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

Gbak fra 2.5 genererer en backup i et lineært format og sender den til stdout, som umiddelbart henter gbak fra 3.0 via stdin og lager en ny database.

Det er nødvendig å organisere en slik rørledning med en lokal (fil) tilgangsmetode, siden nettverkstilgang (selv gjennom localhost) vil redusere prosessen betydelig.

Vi går over detaljene for Windows og Linux nedenfor.

Windows

Når det gjelder Windows, er den enkleste måten å lage en helt frittstående versjon av Firebird. For dette tar vi embed-archive Firebird 2.5, gi nytt navn til fbemded.dll til fbclient.dll, legg til gbak.exe og (valgfritt) isql.exe-verktøy fra det "vanlige" 2.5-arkivet.

Firebird 3.0 bruker enkelt sammenstilling og krever ingen modifikasjon.

Den mest minimale versjonen (som ikke krever installasjon av VS2008/VS2010 kjøretidsbiblioteker på målsystemet) inneholder 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.dll

En erfaren administrator kan legge merke til at 2.5 ikke inkluderer filene intl/fbintl.dll og intl/fbintl.conf. Dette er sant, siden gbak ikke bruker et tilkoblingstegnsett og ikke konverterer data mellom tegnsett, men på "mottaker"-siden av Firebird 3.0, er disse filene nødvendige når du lager indekser.

I firebird.conf anbefales Firebird 3.0 å legge til:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Det er også ønskelig å angi forskjellige IpcName-verdier for 2.5 og 3.0.

Når vi velger verdiene til andre parametere for firebird.conf, går vi ut fra en enkel vurdering: på stadiet med dataoverføring kjører gbak 2.5 i en prosess, og 3.0 i en annen, deretter avsluttes 2.5, og 3.0 begynner å bygge indekser.

For å øke hastigheten på indeksbyggingsfasen i 3.0, anbefales det å øke størrelsen på TempCacheLimit-parameteren til ~40 % RAM (hvis det er en dedikert server, selvfølgelig).

For eksempel, hvis serveren har 16 GB RAM, så kan du sette

TempCacheLimit=6G

Selvfølgelig kan denne verdien bare angis for 64-biters Firebird 3, siden enhver 32-bits prosess ikke kan tildele mer enn 2 gigabyte minne.

I 2.5 trenger ikke denne parameteren å endres - den kan uansett ikke være mer enn 2 gigabyte, og den påvirker ikke hastigheten under sikkerhetskopiering.

Før du utfører operasjonen, må du sjekke at sidebufferen i databasehodet er satt til 0 (kommando gstat -h databasename, se sidebuffere-linjen).

Hvis cachen er satt eksplisitt i databasehodet, overstyrer den verdiene fra firebird.conf (og databases.conf i 3.0), og i tilfelle utilstrekkelig store verdier kan det føre til overdreven minneforbruk og bytte.

Deretter kopierer du filene til målsystemet.

Konverteringen utføres etter å ha stoppet "system" Firebird 2.5-tjenesten, på kommandolinjen med forhøyede rettigheter til den lokale administratoren (eksempel):

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

Dette eksemplet bruker en "skråstrek" i anførselstegn (gyldig "unix-stil"), og en "hatt" (tegnet "^") unnslipper nylinjetegnet, noe som er nyttig når du skriver lange kommandoer. Alternativet -st(atus) dukket opp i Firebird 2.5.8 og lar deg logge data om tiden da gbak-prosessen kjørte (for detaljer, se dokumentasjonen).

Linux

På Linux avhenger Firebird 3 av tommath-biblioteket. På CentOS (RHEL) er dette biblioteket plassert i epel-repositoriet, på Ubuntu (Debian) i system-repositoriet.

For CentOS må du først koble til epel-depotet og først deretter gjøre det

yum install libtommath

Ubuntu trenger ikke å inkludere flere repositories, men Ubuntu 16 og Ubuntu 18 installerer forskjellige versjoner av pakkene - henholdsvis libtommath0 og libtommath1.

Firebird 3.0 ser etter tommath.so.0 og for Ubuntu 18 kreves det i tillegg å lage en lenke (symlink) fra tommath.so.0 til tommath.so.1. For å gjøre dette, må du først finne tommath.so.1.

Søkte sti i Ubuntu - /usr/lib/x86_64-linux-gnu/, men andre Debian-baserte distribusjoner kan være annerledes.

Det andre problemet er knyttet til det faktum at til og med Firebird 3.0.1 var det ingen enkel måte å installere to forskjellige serverversjoner på. Vi vurderer ikke alternativet "kompiler fra kilde med det nødvendige prefikset" på grunn av dets relative kompleksitet.

For Firebird 3.0.2 og høyere implementert bygg med --enable-binreloc og et separat installasjonsprogram (-path path).

Forutsatt at tommath-biblioteket og om nødvendig en symbolkobling for tommath.so.0 er lagt til systemet, kan du installere den nåværende (i skrivende stund) Firebird 3.0.4-distribusjonen i for eksempel /opt /fb3:

./install.sh -path /opt/fb3

Etter det kan du stoppe Firebird-systemtjenesten og starte strømmekonvertering.

Når du stopper Firebird, husk at Firebid 2.5-prosesser i klassisk modus vanligvis startes av xinetd - så du må enten deaktivere firebird-tjenesten for xinetd eller stoppe xinetd helt.

I firebird.conf for 3.0 på Linux trenger du ikke sette MaxUnflushed-parametere (de fungerer bare på Windows) og endre Firebird 2.5-innstillinger.

I Linux tilsvarer ikke lokal (fil)tilgang til Firebird 2.5 den innebygde versjonen under Windows - 2.5-serveren vil fungere i gbak-prosessen (uten nettverksdelen), men tilgangsrettigheter vil bli sjekket mot brukerbasen, noe som betyr at ikke bare en pålogging, men også et passord vil være nødvendig:

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

Etter en vellykket konvertering må du først avinstallere "ekstra" Firebird 3.0, deretter "hoved" Firebird 2.5, og deretter utføre en ren installasjon av Firebird 2.5 - og det er best fra det vanlige tar.gz-installasjonsprogrammet, og ikke gjennom depoter, fordi. versjonen i depotene kan henge etter.

Etter å ha gjenopprettet databasen på Linux og installert på nytt, må du også kontrollere at den nye databasen eies av firebird-brukeren.

Hvis dette ikke er tilfelle, må det rettes opp.

chown firebird.firebird database

Total

I tillegg til å spare tid og diskplass, har streamingkonvertering en annen viktig fordel - databasekonvertering gjøres uten å slette eksisterende Firebird 2.5, noe som i stor grad forenkler tilbakerulling i tilfelle mislykket konvertering (oftest på grunn av plassmangel eller uventet omstart under migreringen prosess).

Tidsbesparelsen skyldes at den "klassiske" konverteringen er "backup time" pluss "restore time". Gjenoppretting består av to deler: lesing av data fra en sikkerhetskopifil og bygging av en indeks.

Med streamingkonvertering oppnås den totale tiden som "backup-tid pluss fem til ti prosent" og "indeksbyggetid".

Spesifikke resultater avhenger av strukturen til databasen, men i gjennomsnitt er gjenopprettingstiden omtrent det dobbelte av sikkerhetskopieringstiden. Derfor, hvis vi tar backup-tid som en enhet, så er "klassisk konvertering" tre tidsenheter, streaming er to tidsenheter. Å øke TempCacheLimit bidrar til å redusere tiden ytterligere.

Generelt lar streamingkonvertering deg i praksis spare 30-40 % av tiden med alternativ sikkerhetskopiering og gjenoppretting.

Spørsmål?

Vennligst skriv alle spørsmålene i kommentarene, eller send dem til forfatteren av metodikken og medforfatteren av denne artikkelen - Vasily Sidorov, iBase Leading System Engineer, ved bs at ibase ru.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Hvilken versjon av Firebird bruker du?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 eller 1.0

16 brukere stemte. 1 bruker avsto.

Kilde: www.habr.com