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-ի միջոցով և ստեղծում նոր տվյալների բազա։
Անհրաժեշտ է նման խողովակաշար կազմակերպել տեղական (ֆայլի) մուտքի մեթոդով, քանի որ ցանցի մուտքը (նույնիսկ localhost-ի միջոցով) զգալիորեն կդանդաղեցնի գործընթացը:
Ниже мы рассматриваем детали для 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 ԳԲ օպերատիվ հիշողություն, ապա կարող եք տեղադրել
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-style»), իսկ «գլխարկը» («^» նիշը) դուրս է գալիս նոր տողի նիշից, որն օգտակար է երկար հրամաններ մուտքագրելիս։ -st(atus) տարբերակը հայտնվել է Firebird 2.5.8-ում և թույլ է տալիս մուտքագրել տվյալներ gbak գործընթացի գործարկման ժամանակի մասին (մանրամասների համար տե՛ս փաստաթղթերը):
Linux
On 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) c tommath.so.0 на tommath.so.1. Для этого сначала надо найти tommath.so.1.
Искомый путь в Ubuntu - /usr/lib/x86_64-linux-gnu/, но в других Debian-based дистрибутивах может быть иначе.
Երկրորդ խնդիրը կապված է այն փաստի հետ, որ մինչև 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.
В линуксе локальный (файловый) доступ 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 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com
