🥇Online převod databází Firebird 2.5 do formátu ODS12 (Firebird 3.0)

Každá verze Firebirdu má svou vlastní verzi formátu struktury disku databáze, O(n)D(isk)S(struktura). Až do verze 2.5 včetně mohl engine Firebird pracovat s ODS předchozích verzí, to znamená, že databáze ze starých verzí byly otevřeny novou verzí a pracovaly v režimu kompatibility, ale engine Firebird 3.0 pracuje pouze s databázemi ve své vlastní verzi ODS. 12.0.

Pro migraci na 3.0 je nutné databázi z 2.5 převést do nového formátu pomocí zálohy/obnovy. Samozřejmě předpokládáme, že databáze byla dříve připravena na konverzi – tzn. metadata a dotazy byly zkontrolovány na kompatibilitu s Firebird 3.0.

Pokud se budete řídit standardním postupem, znamená to zálohu na verzi 2.5, následnou instalaci 3.0 a obnovení. Tento postup je přijatelný, pokud máte dostatek času, ale při migraci velkých databází nebo při migraci několika desítek databází najednou, kdy je čas klíčový, můžete použít streamovací konverzi, která je o 30–40 % rychlejší. Jak přesně to provést (viz Windows a pod Linux), čtěte pod řezem.

Obecná myšlenka je, že k urychlení použijeme potrubí:

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

Gbak z 2.5 vygeneruje zálohu v lineárním formátu a odešle ji do stdout, který okamžitě vyzvedne gbak z 3.0 přes stdin a vytvoří novou databázi.

Je nutné zorganizovat takový kanál s místní (souborovou) přístupovou metodou, protože síťový přístup (i přes localhost) výrazně zpomalí proces.

Níže se podíváme na podrobnosti o Windows и Linux.

Windows

V případě Windows Nejjednodušší způsob je vytvořit zcela samostatnou sestavu Firebirdu. Chcete-li to provést, vezměte si embed-archive Firebird 2.5, přejmenujte fbemded.dll na fbclient.dll, přidejte nástroje gbak.exe a (volitelně) isql.exe z „běžného“ archivu 2.5.

Používá Firebird 3.0 jediná montáž a nevyžaduje žádnou úpravu.

Nejmenší verze (která nevyžaduje instalaci runtime knihoven VS2008/VS2010 na cílový systém) obsahuje následující soubory:

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

Zkušený administrátor si může všimnout, že verze 2.5 neobsahuje soubory intl/fbintl.dll a intl/fbintl.conf. To je pravda, protože gbak nepoužívá znakovou sadu pro připojení a nepřevádí data mezi sadami znaků, ale na "přijímací" straně Firebirdu 3.0 jsou tyto soubory nutné při vytváření indexů.

V firebird.conf se doporučuje Firebird 3.0 přidat:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Také je žádoucí nastavit různé hodnoty IpcName pro 2.5 a 3.0.

Při volbě hodnot ostatních parametrů firebird.conf vycházíme z jednoduché úvahy: ve fázi datové transfuze běží gbak 2.5 v jednom procesu a 3.0 v jiném, poté 2.5 ukončí a 3.0 se začíná budovat indexy.

Pro urychlení fáze vytváření indexu ve verzi 3.0 se doporučuje zvětšit velikost parametru TempCacheLimit na ~40 % RAM (pokud se samozřejmě jedná o dedikovaný server).

Například, pokud má server 16 GB RAM, můžete dát

TempCacheLimit=6G

Tuto hodnotu lze samozřejmě nastavit pouze pro 64bitový Firebird 3, protože žádný 32bitový proces nemůže alokovat více než 2 gigabajty paměti.

Ve verzi 2.5 není nutné tento parametr měnit - stejně nesmí být více než 2 gigabajty a nemá vliv na rychlost při zálohování.

Před provedením operace musíte zkontrolovat, zda je mezipaměť stránky v záhlaví databáze nastavena na 0 (příkaz gstat -h databasename, viz řádek Vyrovnávací paměti stránek).

Pokud je cache nastavena explicitně v hlavičce databáze, pak přepíše hodnoty z firebird.conf (a databases.conf ve 3.0) a v případě neadekvátně velkých hodnot to může vést k nadměrné spotřebě paměti a swapování.

Dále zkopírujte soubory do cílového systému.

Konverze se provádí po zastavení "systémové" služby Firebird 2.5 na příkazovém řádku se zvýšenými právy na místního správce (příklad):

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

Tento příklad používá "lomítko" v uvozovkách (platný "unix-style") a "klobouk" (znak "^") před znakem nového řádku, což je užitečné při psaní dlouhých příkazů. Volba -st(atus) se objevila ve Firebirdu 2.5.8 a umožňuje zaznamenat data o době, kdy proces gbak běžel (podrobnosti viz dokumentace).

Linux

Na Linux Firebird 3 závisí na knihovně tommath. CentOS (RHEL) tato knihovna se nachází v repozitáři epel, v Ubuntu (Debian) v – systémovém.

pro CentOS Nejprve se musíte připojit k repozitáři epel a teprve potom to udělat.

yum install libtommath

Ubuntu není třeba připojovat další repozitáře, ale v Ubuntu 16 a více Ubuntu Je nainstalováno 18 různých verzí balíčků – libtommath0 a libtommath1.

Firebird 3.0 hledá tommath.so.0 a Ubuntu 18 Kromě toho je třeba vytvořit symbolický odkaz z tommath.so.0 na tommath.so.1. K tomu je nejprve nutné najít tommath.so.1.

Hledaná cesta v Ubuntu - /usr/lib/x86_64-linux-gnu/, ale v jiných DebianDistribuce založené na - se mohou lišit.

Druhý problém souvisí se skutečností, že až do Firebird 3.0.1 včetně, neexistoval žádný snadný způsob instalace dvou různých verzí serveru. Možnost „kompilovat ze zdroje s požadovanou předponou“ neuvažujeme kvůli její relativní složitosti.

Pro Firebird 3.0.2 a vyšší implementováno sestavit pomocí --enable-binreloc a samostatnou volbu instalačního programu (cesta -cesta).

Za předpokladu, že do systému byla přidána knihovna tommath a v případě potřeby i symbolický odkaz pro tommath.so.0, můžete aktuální (v době psaní tohoto článku) distribuci Firebird 3.0.4 nainstalovat například do /opt /fb3:

./install.sh -path /opt/fb3

Poté můžete zastavit systémovou službu Firebird a zahájit konverzi streamování.

Při zastavování Firebirdu mějte na paměti, že procesy Firebid 2.5 v klasickém režimu jsou obvykle spouštěny xinetd – takže musíte buď deaktivovat službu firebird pro xinetd, nebo xinetd úplně zastavit.

V souboru firebird.conf pro verzi 3.0 Linux Není třeba nastavovat parametry MaxUnflushed (fungují pouze na Windows) a změnit nastavení Firebirdu 2.5.

V Linuxu není lokální (souborový) přístup Firebirdu 2.5 ekvivalentní vestavěné verzi pod... Windows – Server 2.5 poběží v procesu gbak (bez síťové části), ale přístupová práva budou kontrolována v databázi uživatelů, což znamená, že bude vyžadováno nejen přihlašovací jméno, ale i heslo:

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

Po úspěšné konverzi musíte nejprve odinstalovat "dodatečný" Firebird 3.0, poté "hlavní" Firebird 2.5 a poté provést čistou instalaci Firebird 2.5 - a nejlépe z běžného instalátoru tar.gz a ne přes úložiště, protože. verze v repozitářích může zaostávat.

Také po restaurování BD dne Linux a přeinstalaci je nutné zkontrolovat, zda novou databázi vlastní uživatel Firebirdu.

Pokud tomu tak není, bude potřeba to napravit.

chown firebird.firebird database

Celkový

Kromě úspory času a místa na disku má streamingová konverze ještě jednu důležitou výhodu – konverze databáze se provádí bez mazání stávajícího Firebird 2.5, což výrazně zjednodušuje rollback v případě neúspěšné konverze (nejčastěji z důvodu nedostatku místa nebo neočekávaného restartu během migrace proces).

Úspora času je způsobena tím, že „klasický“ převod je „čas zálohy“ plus „čas obnovení“. Obnova se skládá ze dvou částí: čtení dat ze záložního souboru a vytváření indexu.

Při streamingové konverzi se celkový čas získá jako „doba zálohování plus pět až deset procent“ a „doba vytváření indexu“.

Konkrétní výsledky závisí na struktuře databáze, ale v průměru je doba obnovy přibližně dvojnásobkem doby zálohování. Pokud tedy vezmeme čas zálohování jako jednotku, pak „klasický převod“ jsou tři jednotky času, streamování jsou dvě jednotky času. Zvýšení TempCacheLimit pomáhá dále zkrátit čas.

Obecně platí, že konverze streamování v praxi umožňuje ušetřit 30–40 % času alternativního zálohování a obnovy.

Otázky?

Veškeré dotazy prosím pište do komentářů, nebo je pošlete autorovi metodiky a spoluautorovi tohoto článku – Vasilij Sidorovovi, iBase Leading System Engineer, at bs at ibase ru.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.