Firebird 2.5 տվյալների բազաների հոսքային փոխակերպում ODS12 ձևաչափի (Firebird 3.0)

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 база30

Gbak-ը 2.5-ից ստեղծում է կրկնօրինակում գծային ձևաչափով և ուղարկում այն ​​stdout-ին, որն անմիջապես վերցնում է gbak-ը 3.0-ից stdin-ի միջոցով և ստեղծում նոր տվյալների բազա։

Անհրաժեշտ է նման խողովակաշար կազմակերպել տեղական (ֆայլի) մուտքի մեթոդով, քանի որ ցանցի մուտքը (նույնիսկ localhost-ի միջոցով) զգալիորեն կդանդաղեցնի գործընթացը:

Ստորև ներկայացնում ենք Windows-ի և Linux-ի մանրամասները:

Windows

Windows-ի դեպքում ամենադյուրին ճանապարհը Firebird-ի ամբողջովին ինքնուրույն կառուցվածք պատրաստելն է: Դրա համար մենք վերցնում ենք embed-archive 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 ԳԲ օպերատիվ հիշողություն, ապա կարող եք տեղադրել

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

Linux Firebird 3-ում կախված է տոմատի գրադարանից: 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 և ավելի բարձր տարբերակի համար իրականացվել է կառուցել --enable-binreloc-ով և տեղադրողի առանձին տարբերակ (-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-ը:

Linux-ում firebird.conf-ի համար 3.0-ում, կարիք չկա սահմանել 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 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