Firebird 2.5 adatbázisok streamelése ODS12 formátumba (Firebird 3.0)

A Firebird minden verziója rendelkezik az adatbázis lemezszerkezet formátumának saját verziójával, az O(n)D(isk)S(struktúra). A Firebird motor a 2.5-ös verzióig (beleértve a 3.0-ös verziót is) működhetett a korábbi verziók ODS-jével, vagyis a régi verziók adatbázisait az új verzió nyitotta meg és kompatibilitási módban működött, de a Firebird 12.0 motor csak a saját ODS-verziójában működik. XNUMX.

A 3.0-s verzióra való átálláshoz a 2.5-ös adatbázist át kell alakítani az új formátumba biztonsági mentés/visszaállítás segítségével. Természetesen feltételezzük, hogy az adatbázist előzőleg előkészítették az átalakításra - pl. A metaadatok és a lekérdezések Firebird 3.0-val való kompatibilitását ellenőriztük.

Ha a szabványos megközelítést követi, ez azt jelenti, hogy biztonsági másolatot kell készítenie a 2.5-ös verzióról, majd telepítenie kell a 3.0-t, és vissza kell állítania. Egy ilyen eljárás akkor elfogadható, ha van elegendő idő, de nagy adatbázisok migrálásakor, vagy több tucat adatbázis egyidejű migrálásakor, amikor az idő lejár, 30-40%-kal gyorsabb streaming konverziót használhatunk. Hogyan kell ezt pontosan megtenni (Windows és Linux alatt), olvassa el a vágás alatt.

Az általános elképzelés az, hogy egy csővezetéket fogunk használni a dolgok felgyorsítására:

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

A 2.5-ös Gbak biztonsági másolatot készít lineáris formátumban, és elküldi az stdout-nak, amely azonnal felveszi a gbak-ot a 3.0-tól az stdin-en keresztül, és létrehoz egy új adatbázist.

Egy ilyen csővezetéket helyi (fájl) hozzáférési módszerrel kell megszervezni, mivel a hálózati hozzáférés (akár localhost-on keresztül is) jelentősen lelassítja a folyamatot.

Az alábbiakban a Windows és a Linux részleteit tekintjük át.

Windows

Windows esetén a legegyszerűbb módja a Firebird teljesen önálló buildjének elkészítése. Ehhez vesszük beágyazás-archívum Firebird 2.5, nevezze át az fbemded.dll fájlt fbclient.dll-re, adja hozzá a gbak.exe és (opcionálisan) isql.exe segédprogramokat a „szokásos” 2.5-ös archívumból.

Firebird 3.0 használata egyetlen szerelvény és nem igényel semmilyen módosítást.

A legminimálisabb verzió (amely nem igényli a VS2008/VS2010 futásidejű könyvtárak telepítését a célrendszeren) a következő fájlokat tartalmazza:

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

Egy tapasztalt rendszergazda észreveheti, hogy a 2.5 nem tartalmazza az intl/fbintl.dll és intl/fbintl.conf fájlokat. Ez igaz, mivel a gbak nem használ kapcsolati karakterkészletet, és nem konvertálja az adatokat a karakterkészletek között, de a Firebird 3.0 "fogadó" oldalán ezek a fájlok szükségesek az indexek létrehozásakor.

A firebird.conf fájlban a Firebird 3.0 ajánlott hozzáadni:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Ezenkívül kívánatos különböző IpcName értékeket beállítani a 2.5 és 3.0 számára.

A firebird.conf egyéb paramétereinek értékeinek kiválasztásakor egy egyszerű megfontolásból indulunk ki: az adatátvitel szakaszában a gbak az egyik folyamatban 2.5-öt, a másikban a 3.0-t lefuttat, majd 2.5-öt kilép, és a 3.0 elkezd építeni. indexek.

Az indexépítési fázis felgyorsítása érdekében a 3.0-ban javasolt a TempCacheLimit paraméter méretét ~40% RAM-ra növelni (természetesen ha dedikált szerverről van szó).

Például, ha a szervernek 16 GB RAM-ja van, akkor tegye

TempCacheLimit=6G

Természetesen ez az érték csak a 64 bites Firebird 3-nál állítható be, mivel egyetlen 32 bites folyamat sem tud 2 gigabájtnál több memóriát lefoglalni.

A 2.5-ben ezt a paramétert nem kell módosítani - amúgy sem lehet több 2 gigabájtnál, és a mentési sebességet nem befolyásolja.

A művelet végrehajtása előtt ellenőriznie kell, hogy az adatbázis fejlécében az oldal gyorsítótár 0-ra van állítva (parancs gstat -h databasenamelásd az Oldalpufferek sort).

Ha a gyorsítótár kifejezetten be van állítva az adatbázis fejlécében, akkor az felülírja a firebird.conf (és 3.0-ban az databases.conf) értékeit, és nem megfelelően nagy értékek esetén túlzott memóriafelhasználáshoz és cseréhez vezethet.

Ezután másolja a fájlokat a célrendszerre.

Az átalakítás a "rendszer" Firebird 2.5 szolgáltatás leállítása után történik, a parancssorban a helyi rendszergazda emelt szintű jogaival (példa):

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

Ez a példa "előre perjelet" használ az idézőjelekben (érvényes "unix-stílus"), a "hat" (a "^" karakter) pedig kihagyja az újsor karaktert, ami hasznos hosszú parancsok beírásakor. A -st(atus) opció megjelent a Firebird 2.5.8-ban, és lehetővé teszi a gbak folyamat futási idejére vonatkozó adatok naplózását (a részleteket lásd a dokumentációban).

Linux

Linuxon a Firebird 3 a tommath könyvtártól függ. CentOS (RHEL) rendszeren ez a könyvtár az epel lerakatban, Ubuntu (Debian) esetén a rendszer lerakatában található.

CentOS esetén először csatlakoztatnia kell az epel adattárat, és csak ezután kell megtennie

yum install libtommath

Az Ubuntunak nem kell további tárolókat tartalmaznia, de az Ubuntu 16 és Ubuntu 18 a csomagok különböző verzióit telepíti - a libtommath0 és a libtommath1 csomagokat.

A Firebird 3.0 a tommath.so.0-t keresi, az Ubuntu 18-hoz pedig további hivatkozást (symlink) kell létrehozni a tommath.so.0-tól a tommath.so.1-ig. Ehhez először meg kell találni a tommath.so.1-et.

Ubuntuban keresett útvonal - /usr/lib/x86_64-linux-gnu/, de más Debian-alapú disztribúciók eltérőek lehetnek.

A második probléma azzal kapcsolatos, hogy a Firebird 3.0.1-ig bezárólag nem volt egyszerű módja két különböző szerververzió telepítésének. A „fordítás forrásból a szükséges előtaggal” opciót annak viszonylagos összetettsége miatt nem vesszük figyelembe.

A Firebird 3.0.2 és újabb verzióihoz van implementálva építsd az --enable-binreloc segítségével és egy külön telepítő opció (-path path).

Feltéve, hogy a tommath könyvtár és szükség esetén a tommath.so.0 szimbolikus hivatkozása hozzáadásra került a rendszerhez, telepítheti a jelenlegi (az írás idején) Firebird 3.0.4 disztribúcióját például a /opt fájlba. /fb3:

./install.sh -path /opt/fb3

Ezt követően leállíthatja a Firebird rendszerszolgáltatást, és megkezdheti a streaming konvertálását.

A Firebird leállításakor ne feledje, hogy a klasszikus módú Firebid 2.5-folyamatokat általában az xinetd indítja el – tehát vagy le kell tiltania a firebird szolgáltatást a xinetd számára, vagy teljesen le kell állítania a xinetd-t.

A firebird.conf for 3.0 fájlban Linuxon nem kell beállítania a MaxUnflushed paramétereket (csak Windowson működnek), és nem kell módosítania a Firebird 2.5 beállításait.

Linux alatt a Firebird 2.5 helyi (fájl) elérése nem ekvivalens a Windows alatti beágyazott verzióval - a 2.5-ös szerver a gbak folyamatban fog futni (a hálózati rész nélkül), de a hozzáférési jogosultságokat a felhasználói bázissal ellenőrzik, ami azt jelenti, hogy nem csak a bejelentkezés, hanem a jelszó is szükséges:

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

A sikeres átalakítás után először el kell távolítania a "kiegészítő" Firebird 3.0-t, majd a "fő" Firebird 2.5-öt, és ezt követően végre kell hajtania a Firebird 2.5 tiszta telepítését - és ez a legjobb a szokásos tar.gz telepítőből, és nem a adattárak, mert. a tárolókban található verzió lemaradhat.

Ezenkívül az adatbázis Linux rendszeren való visszaállítása és újratelepítése után ellenőriznie kell, hogy az új adatbázis a firebird felhasználó tulajdona-e.

Ha ez nem így van, akkor ki kell javítani.

chown firebird.firebird database

Teljes

Az idő- és lemezterület-megtakarítás mellett a streaming konvertálásnak van egy másik fontos előnye is - az adatbázis-konverzió a meglévő Firebird 2.5 törlése nélkül történik, ami nagyban leegyszerűsíti a visszaállítást sikertelen átalakítás esetén (leggyakrabban helyhiány vagy váratlan újraindítás miatt a migráció során folyamat).

Az időmegtakarítás annak köszönhető, hogy a "klasszikus" konverzió a "mentési idő" plusz a "helyreállítási idő". A helyreállítás két részből áll: adatok beolvasása egy biztonsági mentési fájlból és index létrehozása.

A streaming konverzióval a teljes időt a „biztonsági mentési idő plusz öt-tíz százalék” és „indexkészítési idő” formában kapjuk meg.

A konkrét eredmények az adatbázis szerkezetétől függenek, de átlagosan a helyreállítási idő körülbelül kétszerese a biztonsági mentési időnek. Ezért, ha a mentési időt egységnek vesszük, akkor a „klasszikus konverzió” három időegység, a streaming pedig két időegység. A TempCacheLimit növelése segít tovább csökkenteni az időt.

Általánosságban elmondható, hogy a streaming konverzió a gyakorlatban lehetővé teszi az alternatív biztonsági mentés és visszaállítás idejének 30-40%-át.

Kérdések?

Kérjük, írja meg az összes kérdést a megjegyzésekben, vagy küldje el a módszertan szerzőjének és a cikk társszerzőjének - Vaszilij Sidorovnak, az iBase vezető rendszermérnökének, a bs at ibase ru címen.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

A Firebird melyik verzióját használod?

• Firebird 3.x

• Firebird xnumx

• Firebird xnumx

• Firebird 2.0, 1.5 vagy 1.0

16 felhasználó szavazott. 1 felhasználó tartózkodott.

Forrás: will.com