Minden Firebird verziónak megvan a saját adatbázis-struktúra formátuma – O(n)D(isk)S(tructure). A 2.5-ös verzióig a Firebird motor képes volt korábbi verziójú ODS-ekkel dolgozni, azaz a régi verziójú adatbázisok megnyithatóak voltak az új verzióban és működtek a kompatibilitás módjában, de a Firebird 3.0 motor csak a saját 12.0 ODS verzióval rendelkező adatbázisokkal működik.
A 3.0-ra való áttéréshez a 2.5-ös adatbázist az új formátumba szükséges átkonvertálni a backup/restoration folyamaton keresztül. Természetesen feltételezzük, hogy az adatbázis előkészítése az átkonvertálásra megtörtént – azaz a metaadatokat és a lekérdezéseket a Firebird 3.0 kompatibilitásának ellenőrizték.
Ha a standard megközelítést követjük, akkor bővítést kell végezni a 2.5-ös verzión, majd telepíteni a 3.0-t, és végrehajtani a helyreállítást. Ez a folyamat elfogadható, ha elegendő idő áll rendelkezésre, de nagy adatbázisok migrálása vagy több tucat adatbázis egyidejű migrálása esetén, amikor az idő szoros, lehetőség van a folyamatos átkonvertálásra, ami 30-40%-kal gyorsabb. Hogyan lehet ezt megtenni (Windows és Linux alatt), arról a továbbiakban olvashat.
Az alapvető ötlet az, hogy a sebesség növelése érdekében egy csővezetéket használunk:
gbak -b … adatbázis25 stdout | gbak -c … stdin adatbázis30A 2.5-ös verziójú gbak lineáris formátumban generálja a biztonsági mentést és az stdout-ra irányítja, amelyet azonnal átvéve a 3.0-s gbak a stdin-en keresztül létrehozza az új adatbázist.
Ezt a csővezetéket feltétlenül helyi (fájlszintű) módszerrel kell megvalósítani, mivel a hálózati hozzáférés (még localhoston keresztül is) jelentősen lelassítja a folyamatot.
Az alábbiakban a Windows és Linux részleteit tárgyaljuk.
Windows
Windows esetén a legkönnyebb teljesen önálló Firebird buildet készíteni. Ehhez az alábbiakat vesszük: , átnevezzük a fbembedded.dll-t fbclient.dll-re, hozzáadjuk a "szokásos" 2.5-ös archívumból a gbak.exe segédprogramot és (nem kötelező) – az isql.exe-t.
A Firebird 3.0 egy és nem igényel semmiféle utómunkát.
A legminimálisabb változat (amely nem igényel VS2008/VS2010 futási könyvtárakat 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.dllEgy tapasztalt adminisztrátor észreveheti, hogy a 2.5-ös verzióban nincs benne az intl/fbintl.dll és az intl/fbintl.conf fájl. Ez valóban így van, mivel a gbak nem használja a kapcsolati karakterkészletet, és nem konvertál 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 ajánlott a Firebird 3.0-nál hozzáadni:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Ezen kívül célszerű megadni a különböző IpcName értékeket a 2.5 és 3.0 számára is.
A firebird.conf többi paraméterének értékeinek meghatározásakor arra a egyszerű megfontolásra alapozunk, hogy az adatmásolási folyamat során az egyik folyamat a gbak 2.5-ös verzióját, a másik pedig a 3.0-ás verziót futtatja, majd a 2.5 befejezi a munkáját, és a 3.0 elkezdi az indexek építését.
Az indexépítési folyamat felgyorsítása érdekében a 3.0-ban ajánlott a TempCacheLimit paraméter méretének növelése körülbelül a RAM ~40%-ára (ha ez dedikált szerver, természetesen).
Például, ha a szerver 16 GB RAM-mal rendelkezik, akkor beállítható
TempCacheLimit=6GTermészetesen ez az érték csak 64 bites Firebird 3 esetén állítható be, mivel bármely 32 bites folyamat nem tud több mint 2 gigabyte memóriát lefoglalni.
A 2.5-ös verziónál ezt a paramétert nem kell módosítani – az amúgy sem lehet több 2 gigabyte-nál, és a mentés sebességére sem gyakorol hatást.
Az operáció végrehajtása előtt ellenőrizni kell, hogy az adatbázis fejlécében a lapkészlet 0-ra van-e állítva (parancs: gstat -h adatbazisnev, nézze meg az Oldal pufferek sorát).
Ha a gyorsítótár egyértelműen meg van adva az adatbázis fejlécében, akkor felülírja a firebird.conf (és a databases.conf a 3.0-ban) értékeit, és a nem megfelelően nagy értékek esetén túlzott memóriafelhasználáshoz és swap-ra lépéshez vezethet.
Ezután másoljuk a fájlokat a célrendszerre.
A konverziót a Firebird 2.5-ös verzió "rendszerszolgáltatás" leállítása után hajtjuk végre, a parancssorban helyi adminisztrátori jogosultságokkal (példa):
set ISC_USER=tulajdonos
"25/gbak" -z -b -g -v -st t -y 25.log baza25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin baza30Ebben a példában a "közvetlen ferde" idézőjelek között van (megengedett "unix-style"), és a "kalap" (karakter "^") a sortörés jelét escaping keresi, ami kényelmes a hosszú parancsok beírásakor. A -st (atus) opció a Firebird 2.5.8-ban jelent meg, és lehetővé teszi, hogy a gbak folyamat idejéről adatokat rögzítsünk a protokollban (részletek a dokumentációban).
Linux
A Linux Firebird 3 függ a tommath könyvtártól. A CentOS (RHEL) esetében ez a könyvtár az epel-repozitóriumban található, az Ubuntu (Debian) rendszeren pedig a rendszerben.
A CentOS system requires first connecting to the EPEL repository and then proceeding to
yum install libtommathOn Ubuntu, no additional repositories need to be connected, but Ubuntu 16 and Ubuntu 18 install different versions of the packages – libtommath0 and libtommath1, respectively.
Firebird 3.0 looks for tommath.so.0 and additionally, for Ubuntu 18, it is necessary to create a symlink from tommath.so.0 to tommath.so.1. To do this, you first need to find tommath.so.1.
The sought 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 server versions. The option of 'compiling from sources with the needed prefix' is not considered due to its relative labor intensity.
For Firebird 3.0.2 and above, there is a and a separate installer option (-path path).
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 article's writing) Firebird 3.0.4 distribution to, for example, /opt/fb3:
./install.sh -path /opt/fb3After this, you can stop the Firebird system service and initiate the streaming conversion.
When stopping Firebird, it must be noted that Firebird 2.5 processes in Classic mode are typically launched by xinetd – therefore, either the firebird service for xinetd must be disabled, or xinetd must be completely stopped.
In firebird.conf for 3.0 on Linux, there is no need to set MaxUnflushed parameters (they only work on Windows) or to change settings for Firebird 2.5.
In Linux, local (file) access for Firebird 2.5 is not equivalent to the embedded version under Windows – server 2.5 will run in the gbak process (without the network part), but access rights will be checked against the user database, meaning that not only a login is required but also a password:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … database25 stdout
|/opt/fb3/bin/gbak -c … stdin database30After a successful conversion, you must first remove the 'additional' Firebird 3.0, then the 'main' Firebird 2.5, and only after that perform a clean installation of Firebird 2.5 — it is best to do this from the standard tar.gz installer rather than through repositories, as the version in repositories may be outdated.
Also, after restoring the database on Linux and reinstalling, check that the new database has firebird as its user owner.
If this is not the case, it will need to be corrected
chown firebird.firebird databaseResult
A folytonos konvertálásnak nemcsak az az előnye, hogy időt és lemezhelyet takarít meg, hanem az is, hogy az alapadatok átalakítása a meglévő Firebird 2.5 eltávolítása nélkül történik, ami jelentősen megkönnyíti a visszaállítást sikertelen konverzió esetén (többnyire a helyhiány vagy a váratlan újraindítás miatt a migrációs folyamat során).
Az időmegtakarítás azzal van összefüggésben, hogy a „klasszikus” konverzió a „biztonsági mentés ideje” plusz a „helyreállítási idő”. A helyreállítás két részből áll: az adatok olvasásából a biztonsági mentés fájlból és az indexek felépítéséből.
A folytonos konvertálásnál az összesített idő „biztonsági mentés ideje plusz öt-tíz százalék” és „indexek építési ideje” összegeként alakul.
A konkrét eredmények az adatbázis felépítésétől függenek, de átlagosan a helyreállítási idő körülbelül duplája a biztonsági mentés idejének. Ezért, ha a biztonsági mentés idejét egységnek tekintjük, akkor a „klasszikus konverzió” három egységnyi időt vesz igénybe, a folytonos konverzió pedig két egységet. A TempCacheLimit növelése további időmegtakarítást segíthet elérni.
Összességében a folytonos konvertálás a gyakorlatban 30-40%-os időmegtakarítást eredményez a soros biztonsági mentés és helyreállítás során.
Kérdése van?
Kérjük, minden kérdést írjon a megjegyzésekbe, vagy küldje el a módszer szerzőjének és a cikk társszerzőjének, Szergej Szidirovnak, aki az „iBase” vállalat vezető rendszermérnöke, a következő címre: bs at ibase ru.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Melyik Firebird verziót használja?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 vagy 1.0
16 felhasználó szavazott. 1 felhasználó nem szavazott.
Forrás: habr.com
