Всяка версия на Firebird разполага със собствена версия на формата на дисковите структури на базата данни – O(n)D(isk)S(tructure). До версия 2.5 включително, движението Firebird можеше да работи с ODS от предишни версии, т.е. бази от стари версии можеха да се отварят с новата версия и да работят в режим на съвместимост, но движението Firebird 3.0 работи само с БД в собствената ODS версия 12.0.
За да преминете на 3.0, базата данни от 2.5 трябва да бъде преобразувана в новия формат чрез backup/restore. Разбира се, ние предполагаме, че БД е била предварително подготвена за конверсия – т.е. метаданните и заявките са били проверени за съвместимост с Firebird 3.0.
Ако следвате стандартния подход, това означава, че трябва да направите бекап на версия 2.5, след което да инсталирате 3.0 и да направите рестор. Тази процедура е приемлива, ако имате достатъчно време, но при миграция на големи бази данни или при едновременна миграция на няколко десетки БД, когато времето притиска, можете да използвате потокова конверсия, която е с 30-40% по-бърза. Как точно да го направите (под Windows и Linux), четете по-долу.
Общата идея е, че за да ускорим процеса, ще използваме конвейер:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak от 2.5 генерира бекъп в линейния формат и го насочва към stdout, който веднага се улавя от gbak от 3.0 през stdin и създава нова БД.
Такъв конвейер задължително трябва да бъде организиран с локален (файлов) достъп, тъй като мрежовият достъп (дори и през localhost) значително забавя процеса.
По-долу разглеждаме подробностите за Windows и Linux.
Windows
В случая с Windows, най-лесно е да направите напълно автономна версия на Firebird. За целта взимаме , преименуваме fbemded.dll на fbclient.dll, добавяме от архива на „обикновен“ 2.5 инструментите gbak.exe и (по желание) – isql.exe.
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 не използва charset на свързването и не конвертира данни между charset-ите, но от "приемната" страна 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 Гб 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-style"), а "шляпка" (символ "^") екранира символа за нов ред, което е удобно при писане на дълги команди. Опцията -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 допълнително е необходимо да се създаде символна връзка (symlink) от 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 и по-високи версии е реализирана и отделна опция на инсталатора (-path път).
Предполагайки, че библиотеката tommath и, при необходимост, символната връзка за tommath.so.0 са добавени в системата, можете да инсталирате актуалната (по времето на написване на тази статия) версия на Firebird 3.0.4 в, например, /opt/fb3:
./install.sh -path /opt/fb3След това можете да спрете системната услуга Firebird и да стартирате потоковата конверсия.
При спирането на Firebird е необходимо да се има предвид, че процесите на Firebird 2.5 в режим Classic обикновено стартира xinetd – следователно е необходимо или да забраните услугата firebird за xinetd или напълно да спрете xinetd.
В firebird.conf за 3.0 на Linux не е необходимо да задавате MaxUnflushed параметрите (те работят само в Windows) и да променяте настройките на Firebird 2.5.
В Linux локалният (файлов) достъп до Firebird 2.5 не е еквивалентен на embedded варианта под 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 at ibase ru.
Само регистрирани потребители могат да участват в анкетата. , моля.
Коя версия на Firebird използвате?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 или 1.0
Гласували 16 потребители. Въздържал се 1 потребител.
Източник: habr.com
