За всяка версия на 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. За това взимаме , преименуваме fbembed.dll на fbclient.dll, добавяме от архива на „обикновения“ 2.5 утилитите gbak.exe и (по желание) – isql.exe.
Firebird 3.0 използва и не изисква никаква допълнителна работа.
Най-малкият вариант (не изискващ инсталиране на runtime библиотеки 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 Гб 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 не е еквивалентен на embeded-варианта под 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
