Секоја верзија на Firebird има своја верзија на форматот на структурата на дискот на базата на податоци, O(n)D(isk)S(структура). До верзијата 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 база30Gbak од 2.5 генерира резервна копија во линеарен формат и ја испраќа до stdout, кој веднаш го зема gbak од 3.0 преку stdin и создава нова база на податоци.
Неопходно е да се организира таков гасовод со метод на локален (датотека) пристап, бидејќи пристапот до мрежата (дури и преку локалниот домаќин) значително ќе го забави процесот.
Подолу ги разгледуваме деталите за Windows и Linux.
Windows
Во случајот со Windows, најлесниот начин е да се направи целосно самостојна конструкција на Firebird. За ова земаме , преименувајте го 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, видете ја линијата за бафери на страници).
Ако кешот е експлицитно поставен во заглавието на базата на податоци, тогаш ги отфрла вредностите од 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 libtommathUbuntu не треба да вклучува дополнителни складишта, но 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 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
-
Firebird 2.5 година
-
Firebird 2.1 година
-
Firebird 2.0, 1.5 или 1.0
Гласаа 16 корисници. 1 корисник се воздржа.
Извор: www.habr.com