Поточно преобразуване на бази данни Firebird 2.5 във формат ODS12 (Firebird 3.0)

Всяка версия на Firebird има своя собствена версия на формата на дисковата структура на базата данни, O(n)D(isk)S(tructure). До версия 2.5 включително двигателят Firebird можеше да работи с ODS от предишни версии, т.е. бази данни от стари версии бяха отворени от новата версия и работеха в режим на съвместимост, но двигателят Firebird 3.0 работи само с бази данни в собствената си ODS версия 12.0.

За да мигрирате към 3.0, базата данни от 2.5 трябва да бъде преобразувана в новия формат чрез архивиране/възстановяване. Разбира се, предполагаме, че базата данни е предварително подготвена за преобразуване - т.е. метаданните и заявките са проверени за съвместимост с Firebird 3.0.

Ако следвате стандартния подход, това означава, че трябва да направите резервно копие на версия 2.5, след това да инсталирате 3.0 и да направите възстановяване. Такава процедура е приемлива, ако има достатъчно време, но при мигриране на големи бази данни или при мигриране на няколко десетки бази данни едновременно, когато времето изтече, можете да използвате поточно преобразуване, което е с 30-40% по-бързо. Как точно да стане това (под Windows и под Linux), прочетете под разрез.

Общата идея е, че ще използваме тръбопровод, за да ускорим нещата:

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

Gbak от 2.5 генерира резервно копие в линеен формат и го изпраща към stdout, който веднага взима gbak от 3.0 чрез stdin и създава нова база данни.

Необходимо е да се организира такъв конвейер с локален (файлов) метод за достъп, тъй като достъпът до мрежата (дори чрез localhost) значително ще забави процеса.

По-долу разглеждаме подробностите за Windows и Linux.

Windows

В случай на Windows, най-лесният начин е да направите напълно самостоятелна компилация на Firebird. За това вземаме вграждане на архив Firebird 2.5, преименувайте fbemded.dll на fbclient.dll, добавете помощни програми gbak.exe и (по избор) isql.exe от „обикновения“ архив 2.5.

Firebird 3.0 използва единична сглобка и не изисква никаква модификация.

Най-минималната версия (която не изисква инсталиране на библиотеките за изпълнение на VS2008/VS2010 на целевата система) съдържа следните файлове:

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

Опитен администратор може да забележи, че 2.5 не включва файловете intl/fbintl.dll и intl/fbintl.conf. Това е вярно, тъй като gbak не използва набор от знаци за връзка и не преобразува данни между набори от знаци, но от "получаващата" страна на Firebird 3.0 тези файлове са необходими при създаване на индекси.

Във firebird.conf Firebird 3.0 се препоръчва да добавите:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Освен това е желателно да зададете различни стойности на IpcName за 2.5 и 3.0.

Когато избираме стойностите на други параметри на firebird.conf, ние изхождаме от просто съображение: на етапа на предаване на данни, gbak изпълнява 2.5 в един процес и 3.0 в друг, след това 2.5 излиза и 3.0 започва да изгражда индекси.

За да се ускори фазата на изграждане на индекс в 3.0, се препоръчва да се увеличи размерът на параметъра TempCacheLimit до ~40% RAM (ако е специален сървър, разбира се).

Например, ако сървърът има 16 GB RAM, тогава можете да поставите

TempCacheLimit=6G

Разбира се, тази стойност може да бъде зададена само за 64-битов Firebird 3, тъй като всеки 32-битов процес не може да разпредели повече от 2 гигабайта памет.

В 2.5 този параметър не трябва да се променя - така или иначе не може да бъде повече от 2 гигабайта и не влияе на скоростта по време на архивиране.

Преди да извършите операцията, трябва да проверите дали кешът на страницата в заглавката на базата данни е зададен на 0 (команда gstat -h databasename, вижте реда Page buffers).

Ако кешът е зададен изрично в заглавката на базата данни, тогава той замества стойностите от firebird.conf (и databases.conf в 3.0) и в случай на неадекватно големи стойности, това може да доведе до прекомерна консумация на памет и суапинг.

След това копирайте файловете в целевата система.

Преобразуването се извършва след спиране на "системната" услуга Firebird 2.5, на командния ред с повишени права на локалния администратор (пример):

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

Този пример използва "наклонена черта" в кавички (валиден "unix-стил"), а "шапка" (символът "^") избягва знака за нов ред, което е полезно при въвеждане на дълги команди. Опцията -st(atus) се появи във Firebird 2.5.8 и ви позволява да регистрирате данни за времето, когато процесът gbak е изпълняван (за подробности вижте документацията).

Linux

В Linux Firebird 3 зависи от библиотеката tommath. В CentOS (RHEL) тази библиотека се намира в хранилището на epel, в Ubuntu (Debian) в системното хранилище.

За CentOS първо трябва да свържете хранилището на epel и едва тогава да го направите

yum install libtommath

Ubuntu не е необходимо да включва допълнителни хранилища, но Ubuntu 16 и Ubuntu 18 инсталират различни версии на пакетите - съответно libtommath0 и libtommath1.

Firebird 3.0 търси tommath.so.0, а за Ubuntu 18 допълнително се изисква да се създаде връзка (симлинкова връзка) от tommath.so.0 към tommath.so.1. За да направите това, първо трябва да намерите tommath.so.1.

Търсен път в Ubuntu - /usr/lib/x86_64-linux-gnu/, но други базирани на Debian дистрибуции може да са различни.

Вторият проблем е свързан с факта, че до Firebird 3.0.1 включително, нямаше лесен начин за инсталиране на две различни версии на сървъра. Ние не разглеждаме опцията „компилиране от източник с необходимия префикс“ поради относителната й сложност.

За Firebird 3.0.2 и по-нови внедрени изграждане с --enable-binreloc и отделна опция за инсталиране (-path път).

Ако приемем, че библиотеката tommath и, ако е необходимо, символна връзка за tommath.so.0 са добавени към системата, можете да инсталирате текущата (към момента на писане) Firebird 3.0.4 дистрибуция в, например, /opt /fb3:

./install.sh -path /opt/fb3

След това можете да спрете системната услуга Firebird и да започнете поточно преобразуване.

Когато спирате Firebird, имайте предвид, че процесите на Firebid 2.5 в класически режим обикновено се стартират от xinetd - така че трябва или да деактивирате услугата firebird за xinetd, или да спрете напълно xinetd.

В firebird.conf за 3.0 на Linux не е необходимо да задавате параметри MaxUnflushed (те работят само в Windows) и да променяте настройките на Firebird 2.5.

В Linux локалният (файлов) достъп на Firebird 2.5 не е еквивалентен на вградената версия под Windows - сървърът 2.5 ще работи в gbak процеса (без мрежовата част), но правата за достъп ще се проверяват спрямо потребителската база, което означава че ще се изисква не само влизане, но и парола:

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

След успешно преобразуване първо трябва да деинсталирате "допълнителния" Firebird 3.0, след това "основния" Firebird 2.5 и след това да извършите чиста инсталация на Firebird 2.5 - и най-добре от обикновения инсталатор на tar.gz, а не през хранилища, т.к. версията в хранилищата може да изостава.

Освен това, след като възстановите базата данни на Linux и преинсталирате, трябва да проверите дали новата база данни е собственост на потребителя на firebird.

Ако това не е така, тогава ще трябва да се коригира.

chown firebird.firebird database

Общо

В допълнение към спестяването на време и дисково пространство, поточното преобразуване има и друго важно предимство - преобразуването на базата данни се извършва без изтриване на съществуващия Firebird 2.5, което значително улеснява връщането назад в случай на неуспешно преобразуване (най-често поради липса на място или неочаквано рестартиране по време на миграцията процес).

Спестяването на време се дължи на факта, че "класическото" преобразуване е "време за архивиране" плюс "време за възстановяване". Възстановяването се състои от две части: четене на данни от архивен файл и изграждане на индекс.

При поточно преобразуване общото време се получава като „време за резервно копиране плюс пет до десет процента“ и „време за изграждане на индекс“.

Конкретните резултати зависят от структурата на базата данни, но средно времето за възстановяване е приблизително два пъти по-голямо от времето за архивиране. Следователно, ако вземем времето за архивиране като единица, тогава „класическото преобразуване“ е три единици време, стриймингът е две единици време. Увеличаването на TempCacheLimit помага за допълнително намаляване на времето.

Като цяло, поточното преобразуване на практика ви позволява да спестите 30-40% от времето за алтернативно архивиране и възстановяване.

Въпроси?

Моля, напишете всички въпроси в коментарите или ги изпратете на автора на методологията и съавтор на тази статия - Василий Сидоров, водещ системен инженер на iBase, в bs в ibase ru.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Каква версия на Firebird използвате?

• Firebird 3.x

• Жар птица 2.5

• Жар птица 2.1

• Firebird 2.0, 1.5 или 1.0

16 потребители гласуваха. 1 потребител се въздържа.

Източник: www.habr.com