ProHoster > Ubadilishaji wa mtiririko wa hifadhidata za Firebird 2.5 hadi umbizo la ODS12 (Firebird 3.0)

Ubadilishaji wa mtiririko wa hifadhidata za Firebird 2.5 hadi umbizo la ODS12 (Firebird 3.0)

Kila toleo la Firebird lina toleo lake la umbizo la muundo wa diski ya hifadhidata, O(n)D(isk)S(muundo). Hadi toleo la 2.5 linajumuisha, injini ya Firebird inaweza kufanya kazi na ODS ya matoleo ya awali, yaani, hifadhidata kutoka kwa matoleo ya zamani zilifunguliwa na toleo jipya na kufanya kazi katika hali ya utangamano, lakini injini ya Firebird 3.0 inafanya kazi tu na hifadhidata katika toleo lake la ODS. 12.0.

Ili kuhamia 3.0, hifadhidata kutoka 2.5 lazima ibadilishwe hadi umbizo jipya kupitia chelezo/rejesha. Bila shaka, tunadhani kwamba database ilikuwa imeandaliwa hapo awali kwa uongofu - i.e. metadata na hoja zimekaguliwa ili kuona uoanifu na Firebird 3.0.

Ikiwa unafuata mbinu ya kawaida, hii ina maana kwamba unahitaji kufanya nakala kwenye toleo la 2.5, kisha usakinishe 3.0 na urejeshe. Utaratibu kama huo unakubalika ikiwa kuna wakati wa kutosha, lakini wakati wa kuhamisha hifadhidata kubwa, au wakati wa kuhamisha hifadhidata kadhaa kwa wakati mmoja, wakati unapokwisha, unaweza kutumia ubadilishaji wa utiririshaji, ambao ni 30-40% haraka. Jinsi ya kufanya hivyo (chini ya Windows na chini ya Linux), soma chini ya kata.

Wazo la jumla ni kwamba tutatumia bomba kuharakisha mambo:

gbak -b … Π±Π°Π·Π°25 stdout | gbak -c … stdin Π±Π°Π·Π°30

Gbak kutoka 2.5 hutengeneza chelezo katika umbizo la mstari na kuituma kwa stdout, ambayo mara moja huchukua gbak kutoka 3.0 kupitia stdin na kuunda hifadhidata mpya.

Inahitajika kuandaa bomba kama hilo na njia ya ufikiaji ya ndani (faili), kwani ufikiaji wa mtandao (hata kupitia localhost) utapunguza sana mchakato.

Tunapitia maelezo ya Windows na Linux hapa chini.

Windows

Kwa upande wa Windows, njia rahisi ni kufanya ujenzi wa kujitegemea kabisa wa Firebird. Kwa hili tunachukua kupachika-kumbukumbu Firebird 2.5, ipe jina fbemded.dll kuwa fbclient.dll, ongeza gbak.exe na (hiari) huduma za isql.exe kutoka kwenye kumbukumbu ya "kawaida" 2.5.

Firebird 3.0 hutumia mkusanyiko mmoja na hauhitaji marekebisho yoyote.

Toleo la chini zaidi (ambalo halihitaji usakinishaji wa maktaba za wakati wa utekelezaji za VS2008/VS2010 kwenye mfumo lengwa) lina faili zifuatazo:

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

Msimamizi mwenye uzoefu anaweza kutambua kwamba 2.5 haijumuishi faili za intl/fbintl.dll na intl/fbintl.conf. Hii ni kweli, kwa kuwa gbak haitumii charset ya uunganisho na haibadilishi data kati ya charset, lakini kwa upande wa "kupokea" wa Firebird 3.0, faili hizi ni muhimu wakati wa kuunda indexes.

Katika firebird.conf Firebird 3.0 inapendekezwa kuongeza:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Pia, inahitajika kuweka maadili tofauti ya IpcName kwa 2.5 na 3.0.

Wakati wa kuchagua maadili ya vigezo vingine vya firebird.conf, tunaendelea kutoka kwa kuzingatia rahisi: katika hatua ya uongezaji data, gbak inaendesha 2.5 katika mchakato mmoja, na 3.0 kwa mwingine, kisha 2.5 kutoka, na 3.0 huanza kujenga. fahirisi.

Ili kuharakisha awamu ya kujenga index katika 3.0, inashauriwa kuongeza ukubwa wa parameter ya TempCacheLimit hadi ~ 40% RAM (ikiwa ni seva iliyojitolea, bila shaka).

Kwa mfano, ikiwa seva ina 16 GB ya RAM, basi unaweza kuweka 

TempCacheLimit=6G

Bila shaka, thamani hii inaweza kuweka tu kwa 64-bit Firebird 3, kwani mchakato wowote wa 32-bit hauwezi kutenga zaidi ya gigabytes 2 za kumbukumbu.

Katika 2.5, parameter hii haihitaji kubadilishwa - haiwezi kuwa zaidi ya gigabytes 2 hata hivyo, na haiathiri kasi wakati wa kuhifadhi.

Kabla ya kufanya operesheni, unahitaji kuangalia ikiwa kashe ya ukurasa kwenye kichwa cha hifadhidata imewekwa 0 (amri). gstat -h databasename, angalia mstari wa bafa za Ukurasa).

Ikiwa kache imewekwa kwa uwazi katika kichwa cha hifadhidata, basi inabatilisha maadili kutoka firebird.conf (na hifadhidata.conf katika 3.0), na katika kesi ya maadili makubwa yasiyotosheleza, inaweza kusababisha utumiaji mwingi wa kumbukumbu na ubadilishaji.

Ifuatayo, nakili faili kwenye mfumo unaolengwa.

Uongofu unafanywa baada ya kusimamisha huduma ya "mfumo" Firebird 2.5, kwenye mstari wa amri na haki zilizoinuliwa kwa msimamizi wa eneo (mfano):

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

Mfano huu hutumia "kufyeka mbele" katika nukuu ("mtindo-halisi" halali), na "kofia" (herufi "^") huepuka herufi mpya, ambayo ni muhimu wakati wa kuandika amri ndefu. Chaguo la -st(atus) lilionekana katika Firebird 2.5.8 na hukuruhusu kuweka data kuhusu wakati mchakato wa gbak ulipokuwa ukiendelea (kwa maelezo, angalia hati).

Linux

Kwenye Linux Firebird 3 inategemea maktaba ya tommath. Kwenye CentOS (RHEL) maktaba hii iko kwenye hazina ya epel, kwenye Ubuntu (Debian) kwenye hazina ya mfumo.

Kwa CentOS, lazima kwanza uunganishe hazina ya epel na kisha tu ufanye 

yum install libtommath

Ubuntu hauitaji kujumuisha hazina za ziada, lakini Ubuntu 16 na Ubuntu 18 husakinisha matoleo tofauti ya vifurushi - libtommath0 na libtommath1, mtawaliwa.

Firebird 3.0 hutafuta tommath.so.0 na kwa Ubuntu 18 inahitajika pia kuunda kiungo (symlink) kutoka tommath.so.0 hadi tommath.so.1. Ili kufanya hivyo, kwanza unahitaji kupata tommath.so.1.

Njia iliyotafutwa katika Ubuntu - /usr/lib/x86_64-linux-gnu/, lakini usambazaji mwingine wa msingi wa Debian unaweza kuwa tofauti.

Tatizo la pili linahusiana na ukweli kwamba hadi na ikiwa ni pamoja na Firebird 3.0.1, hapakuwa na njia rahisi ya kufunga matoleo mawili tofauti ya seva. Hatuzingatii chaguo "kukusanya kutoka kwa chanzo na kiambishi awali kinachohitajika" kwa sababu ya utata wake.

Kwa Firebird 3.0.2 na matoleo mapya zaidi yametekelezwa jenga na --enable-binreloc na chaguo tofauti la kisakinishi (-njia ya njia).

Kwa kudhani kuwa maktaba ya tommath na, ikiwa ni lazima, ulinganifu wa tommath.so.0 umeongezwa kwenye mfumo, unaweza kusakinisha ya sasa (wakati wa kuandika haya) usambazaji wa Firebird 3.0.4, kwa mfano, /opt. /fb3:

./install.sh -path /opt/fb3

Baada ya hapo, unaweza kusimamisha huduma ya mfumo wa Firebird na uanze kugeuza utiririshaji.

Unaposimamisha Firebird, kumbuka kuwa michakato ya Firebid 2.5 katika hali ya Kawaida kwa kawaida huanzishwa na xinetd - kwa hivyo unahitaji ama kuzima huduma ya firebird kwa xinetd au kuacha xinetd kabisa.

Katika firebird.conf kwa 3.0 kwenye Linux, huna haja ya kuweka vigezo vya MaxUnflushed (zinafanya kazi tu kwenye Windows) na kubadilisha mipangilio ya Firebird 2.5.

Katika Linux, ufikiaji wa Firebird 2.5 wa ndani (faili) sio sawa na toleo lililopachikwa chini ya Windows - seva ya 2.5 itaendesha mchakato wa gbak (bila sehemu ya mtandao), lakini haki za ufikiaji zitaangaliwa dhidi ya msingi wa mtumiaji, ambayo inamaanisha kuwa sio tu kuingia, lakini pia nenosiri litahitajika: 

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … Π±Π°Π·Π°25 stdout
|/opt/fb3/bin/gbak -c … stdin Π±Π°Π·Π°30

Baada ya uongofu uliofanikiwa, lazima kwanza uondoe "ziada" Firebird 3.0, kisha "kuu" Firebird 2.5, na baada ya hayo ufanye ufungaji safi wa Firebird 2.5 - na ni bora kutoka kwa kisakinishi cha kawaida cha tar.gz, na si kupitia hazina, kwa sababu. toleo katika hazina inaweza kubaki nyuma.

Pia, baada ya kurejesha hifadhidata kwenye Linux na kusakinisha upya, unahitaji kuangalia kwamba hifadhidata mpya inamilikiwa na mtumiaji wa firebird.

Ikiwa hii sio hivyo, basi itahitaji kusahihishwa.

chown firebird.firebird database

Jumla ya

Mbali na kuokoa muda na nafasi ya diski, ubadilishaji wa utiririshaji una faida nyingine muhimu - ubadilishaji wa hifadhidata unafanywa bila kufuta Firebird 2.5 iliyopo, ambayo hurahisisha sana kurudi nyuma ikiwa ubadilishaji usiofanikiwa (mara nyingi kwa sababu ya ukosefu wa nafasi au kuwasha upya bila kutarajiwa wakati wa uhamiaji. mchakato).

Uokoaji wa wakati unatokana na ukweli kwamba ubadilishaji wa "classic" ni "wakati wa chelezo" pamoja na "wakati wa kurejesha". Urejeshaji una sehemu mbili: kusoma data kutoka kwa faili ya chelezo na kuunda faharisi.

Kwa ubadilishaji wa utiririshaji, muda wote unapatikana kama "muda wa kuhifadhi nakala pamoja na asilimia tano hadi kumi" na "muda wa kuunda faharasa".

Matokeo mahususi hutegemea muundo wa hifadhidata, lakini kwa wastani, muda wa kurejesha ni takriban mara mbili ya muda wa kuhifadhi. Kwa hivyo, ikiwa tutachukua muda wa kuhifadhi kama kitengo, basi "ubadilishaji wa kawaida" ni vitengo vitatu vya wakati, utiririshaji ni vitengo viwili vya wakati. Kuongeza TempCacheLimit husaidia kupunguza zaidi wakati.

Kwa ujumla, ubadilishaji wa utiririshaji katika mazoezi hukuruhusu kuokoa 30-40% ya wakati wa chelezo mbadala na urejeshaji.

Maswali?

Tafadhali andika maswali yote kwenye maoni, au uwatume kwa mwandishi wa mbinu na mwandishi mwenza wa nakala hii - Vasily Sidorov, Mhandisi wa Mfumo wa Uongozi wa iBase, kwenye bs at ibase ru.

Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. Weka sahihitafadhali.

Unatumia toleo gani la Firebird?

  • Firebird 3.x

  • Firebird 2.5

  • Firebird 2.1

  • Firebird 2.0, 1.5 au 1.0

Watumiaji 16 walipiga kura. Mtumiaji 1 alijizuia.

Chanzo: mapenzi.com

Kuongeza maoni