Ninapendekeza usome nakala ya ripoti kutoka mwanzoni mwa 2019 na Andrey Borodin "Hifadhi nakala na WAL-G. Kuna nini katika 2019?"
Salaam wote! Jina langu ni Andrey Borodin. Mimi ni msanidi programu katika Yandex. Nimekuwa na nia ya PostgreSQL tangu 2016, baada ya kuzungumza na watengenezaji na walisema kwamba kila kitu ni rahisi - unachukua msimbo wa chanzo na kuijenga, na kila kitu kitafanya kazi. Na tangu wakati huo siwezi kuacha - ninaandika kila aina ya mambo tofauti.
Moja ya mambo ninayofanyia kazi ni mfumo wa chelezo. . Kwa ujumla, katika Yandex tumekuwa tukifanya kazi kwenye mifumo ya chelezo katika PostgreSQL kwa muda mrefu sana. Na unaweza kupata kwenye Mtandao mfululizo wa ripoti sita kuhusu jinsi tunavyotengeneza mifumo ya kuhifadhi nakala. Na kila mwaka hubadilika kidogo, hukua kidogo, na kuwa wa kuaminika zaidi.
Lakini leo ripoti sio tu kuhusu kile tulichofanya, lakini pia kuhusu jinsi ilivyo rahisi na ni nini. Je, ni wangapi kati yenu ambao tayari mmetazama ripoti zangu kuhusu WAL-G? Ni vizuri kwamba watu wachache hawakutazama, kwa sababu nitaanza na jambo rahisi zaidi.
Ikiwa ghafla una kikundi cha PostgreSQL, na nadhani kila mtu ana michache yao, na ghafla hakuna mfumo wa chelezo bado, basi unahitaji kupata hifadhi yoyote ya S3 au hifadhi inayoendana na Wingu la Google.
Kwa mfano, unaweza kuja kwenye msimamo wetu na kuchukua msimbo wa utangazaji wa Hifadhi ya Kitu cha Yandex, ambayo inaendana na S3.
Kisha unda Bucket. Ni chombo cha habari tu.
Unda mtumiaji wa huduma.
Unda ufunguo wa ufikiaji wa mtumiaji wa huduma: aws-s3-key.
Pakua toleo la hivi punde thabiti la WAL-G.
Je, matoleo yetu ya awali yana tofauti gani na matoleo? Mara nyingi mimi huulizwa kutolewa mapema. Na ikiwa hakuna mdudu katika toleo kwa muda wa kutosha, kwa mfano, mwezi, basi ninaifungua. Hili hapa toleo la Novemba. Na hii ina maana kwamba kila mwezi tulipata aina fulani ya mdudu, kwa kawaida katika utendaji usio muhimu, lakini bado hatujatoa toleo. Toleo la awali ni Novemba tu. Hakuna hitilafu zinazojulikana kwetu, yaani, mende ziliongezwa mradi ukiendelea.
Mara baada ya kupakua WAL-G, unaweza kuendesha amri rahisi ya "orodha ya chelezo", kupita katika vigezo vya mazingira. Na itaunganishwa na Hifadhi ya Kitu na kukuambia ni chelezo gani unazo. Mara ya kwanza, bila shaka, hupaswi kuwa na chelezo. Hoja ya slaidi hii ni kuonyesha kuwa kila kitu ni rahisi sana. Hii ni amri ya koni ambayo inakubali anuwai za mazingira na kutekeleza amri ndogo.
Baada ya hayo, unaweza kufanya chelezo yako ya kwanza. Sema "chelezo-push" katika WAL-G na ubainishe katika WAL-G eneo la pgdata la nguzo yako. Na uwezekano mkubwa, PostgreSQL itakuambia, ikiwa huna mfumo wa chelezo, kwamba unahitaji kuwezesha "archive-mode".
Hii ina maana kwamba unahitaji kwenda kwa mipangilio na kuwasha "archive_mode = on" na kuongeza "archive_command", ambayo pia ni amri ndogo katika WAL-G. Lakini kwa sababu fulani watu mara nyingi hutumia maandishi ya upau kwenye mada hii na kuifunika WAL-G. Tafadhali usifanye hivi. Tumia utendakazi unaopatikana katika WAL-G. Ikiwa unakosa kitu, andika kwa . WAL-G inadhania kuwa ni programu pekee inayoendeshwa katika archive_command.
Tunatumia WAL-G hasa kuunda kikundi cha Upatikanaji wa Juu katika usimamizi wa Hifadhidata ya Yandex.
Na kwa kawaida hutumiwa katika topolojia ya Mwalimu mmoja na marudio kadhaa. Wakati huo huo, hufanya nakala ya chelezo katika Hifadhi ya Kitu cha Yandex.
Matukio ya kawaida ni kuunda nakala za nguzo kwa kutumia Point katika uokoaji wa wakati. Lakini katika kesi hii, utendaji wa mfumo wa chelezo sio muhimu sana kwetu. Tunahitaji tu kupakia kikundi kipya kutoka kwa hifadhi rudufu.
Kwa kawaida, tunahitaji utendakazi wa mfumo wa chelezo wakati wa kuongeza nodi mpya. Kwa nini ni muhimu? Kwa kawaida watu huongeza nodi mpya kwenye nguzo kwa sababu nguzo iliyopo haiwezi kushughulikia mzigo uliosomwa. Wanahitaji kuongeza nakala mpya. Ikiwa tunaongeza mzigo kutoka pg_basebackup kwa Mwalimu, basi Mwalimu anaweza kuanguka. Kwa hivyo, ilikuwa muhimu sana kwetu kwamba tunaweza kupakia haraka nodi mpya kutoka kwa kumbukumbu, na kuunda mzigo mdogo kwa Mwalimu.
Na hali nyingine kama hiyo. Hili ni hitaji la kuanzisha tena Mwalimu wa zamani baada ya kubadili Mwalimu wa Nguzo kutoka Kituo cha Data ambacho muunganisho ulipotea.
- Kwa hivyo, wakati wa kuunda mahitaji ya mfumo wa nakala, tuligundua kuwa pg_basebackup haifai kwetu wakati wa kufanya kazi katika wingu.
- Tulitaka kuweza kubana data yetu. Lakini karibu mfumo wowote wa chelezo isipokuwa kile kinachokuja kwenye kisanduku utatoa mgandamizo wa data.
- Tulitaka kusawazisha kila kitu kwa sababu mtumiaji katika wingu hununua idadi kubwa ya cores za kichakataji. Lakini ikiwa hatuna usawa katika operesheni fulani, basi idadi kubwa ya cores inakuwa haina maana.
- Tunahitaji usimbaji fiche kwa sababu mara nyingi data si yetu na haiwezi kuhifadhiwa katika maandishi wazi. Kwa njia, mchango wetu kwa WAL-G ulianza na usimbaji fiche. Tulikamilisha usimbaji fiche katika WAL-G, kisha tukaulizwa: "Labda mmoja wetu ataendeleza mradi?" Na tangu wakati huo nimekuwa nikifanya kazi na WAL-G kwa zaidi ya mwaka mmoja.
- Pia tulihitaji kusukuma rasilimali, kwa sababu baada ya muda kutumia wingu, tuligundua kwamba wakati mwingine watu wana mzigo muhimu wa mboga usiku na mzigo huu hauwezi kuingiliwa. Ndio maana tuliongeza uboreshaji wa rasilimali.
- Pamoja na kuorodhesha na usimamizi.
- Na uthibitisho.
Tuliangalia zana nyingi tofauti. Kwa bahati nzuri, tunayo chaguo kubwa katika PostgreSQL. Na kila mahali tulikuwa tunakosa kitu, kazi fulani ndogo, kipengele kimoja kidogo.
Na baada ya kuchunguza mifumo iliyopo, tulifikia hitimisho kwamba tutakuza WAL-G. Ilikuwa mradi mpya wakati huo. Ilikuwa rahisi sana kushawishi maendeleo kuelekea miundombinu ya wingu ya mfumo wa chelezo.
Itikadi kuu tunayozingatia ni kwamba WAL-G inapaswa kuwa rahisi kama balalaika.
WAL-G ina amri 4. Hii:
WAL-PUSH - weka shimoni kwenye kumbukumbu.
WAL-FETCH - pata shimoni.
BACKUP-PUSH - tengeneza nakala.
BACKUP-FETCH - pata nakala kutoka kwa mfumo wa chelezo.
Kwa kweli, WAL-G pia ina usimamizi wa chelezo hizi, yaani kuorodhesha na kufuta rekodi na chelezo katika historia ambazo hazihitajiki tena kwa sasa.
Moja ya kazi muhimu kwetu ni kazi ya kuunda nakala za delta.
Nakala za Delta inamaanisha kuwa hatuunda nakala kamili ya nguzo nzima, lakini tu kurasa zilizobadilishwa za faili zilizobadilishwa kwenye nguzo. Inaweza kuonekana kuwa kiutendaji hii ni sawa na uwezo wa kupona kwa kutumia WAL. Lakini tunaweza kukunja nakala rudufu ya delta yenye nyuzi moja ya WAL sambamba. Ipasavyo, tunapokuwa na chelezo ya msingi iliyofanywa Jumamosi, chelezo za delta kila siku, na Alhamisi tukashindwa, basi tunahitaji kukunja nakala 4 za delta na saa 10 za WAL. Itachukua muda huo huo kwa sababu chelezo za delta zinaendelea sambamba.
Delta za msingi wa LSN - hii inamaanisha kuwa wakati wa kuunda nakala rudufu, tutahitaji kuchanganya kila ukurasa na kuangalia LSN yake na LSN ya chelezo ya awali ili kuelewa kuwa imebadilika. Ukurasa wowote ambao unaweza kuwa na data iliyobadilishwa unapaswa kuwepo kwenye hifadhi rudufu ya delta.
Kama nilivyosema, umakini mkubwa ulilipwa kwa usawa.
Lakini API ya kumbukumbu katika PostgreSQL ni thabiti. PostgreSQL huhifadhi faili moja ya WAL na inaporejesha inaomba faili moja ya WAL. Lakini hifadhidata inapoomba faili moja ya WAL kwa kutumia amri ya "WAL-FETCH", tunaita amri ya "WAL-PREFETCH", ambayo huandaa faili 8 zinazofuata ili kuchukua data kutoka kwa hifadhi ya kitu sambamba.
Na wakati hifadhidata inapotuuliza kuweka faili moja kwenye kumbukumbu, tunaangalia archive_status na kuona ikiwa kuna faili zingine za WAL. Na pia tunajaribu kupakua WAL sambamba. Hii hutoa faida kubwa ya utendaji na hupunguza kwa kiasi kikubwa umbali katika idadi ya WAL ambazo hazijahifadhiwa. Wasanidi wengi wa mfumo wa chelezo wanaamini kuwa huu ni mfumo hatari sana kwa sababu tunategemea ujuzi wetu wa mfumo wa ndani wa msimbo ambao si API ya PostgreSQL. PostgreSQL haitoi hakikisho la kuwepo kwa folda ya archive_status kwa ajili yetu na haitoi dhamana ya semantiki, uwepo wa ishara za utayari wa faili za WAL huko. Walakini, tunasoma msimbo wa chanzo, tunaona kuwa hii ni hivyo na tunajaribu kuitumia vibaya. Na tunadhibiti mwelekeo ambao PostgreSQL inakua; ikiwa utaratibu huu umevunjwa ghafla, tutaacha kuitumia.
Katika hali yake safi, delta ya WAL yenye msingi wa LSN inahitaji kusoma faili yoyote ya nguzo ambayo muda wake katika mfumo wa faili umebadilika tangu hifadhi rudufu ya awali. Tuliishi na hii kwa muda mrefu, karibu mwaka. Na mwishowe tulifikia hitimisho kwamba tuna delta za WAL.
Hii ina maana kwamba kila wakati tunapoweka WAL kwenye kumbukumbu kwenye Mwalimu, hatuikandamiza tu, kuisimba kwa njia fiche na kuituma kwa mtandao, lakini pia tunaisoma kwa wakati mmoja. Tunachambua na kusoma rekodi ndani yake. Tunaelewa ni vizuizi gani vimebadilika na kukusanya faili za delta.
Faili ya delta inaelezea safu fulani ya faili za WAL, inaelezea habari kuhusu ni vizuizi vipi vilibadilishwa katika safu hii ya WAL. Na kisha faili hizi za delta pia zimewekwa kwenye kumbukumbu.
Hapa tunakabiliwa na ukweli kwamba tulilinganisha kila kitu haraka sana, lakini hatuwezi kusoma historia ya mlolongo kwa sambamba, kwa sababu katika sehemu fulani tunaweza kukutana na mwisho wa rekodi ya WAL iliyopita, ambayo hatuna chochote cha kuunganisha bado, kwa sababu. usomaji sambamba ulipelekea kwamba kwanza tuchambue siku zijazo, ambazo bado hazina wakati uliopita.
Kama matokeo, tulilazimika kuweka vipande visivyoeleweka kwenye faili za _delta_partial. Matokeo yake, tunaporudi zamani, tutaunganisha vipande vya rekodi ya WAL kwenye moja, baada ya hapo tutaichanganua na kuelewa kilichobadilika ndani yake.
Ikiwa katika historia ya uchanganuzi wa shimoni yetu kuna angalau hatua moja ambapo hatuelewi kinachotokea, basi, ipasavyo, wakati wa chelezo inayofuata tutalazimika kusoma nguzo nzima tena, kama tulivyofanya na LSN ya kawaida. - delta ya msingi.
Kama matokeo, mateso yetu yote yalisababisha ukweli kwamba tulifungua maktaba ya uchanganuzi ya WAL-G. Nijuavyo, hakuna anayeitumia bado, lakini ikiwa kuna mtu anataka, kuiandika na kuitumia, iko kwenye kikoa cha umma. (Kiungo kilichosasishwa )
Matokeo yake, mtiririko wote wa habari unaonekana kuwa ngumu sana. Mwalimu wetu huhifadhi shimoni na kuhifadhi faili za delta kwenye kumbukumbu. Na nakala inayounda nakala rudufu lazima ipokee faili za delta wakati ambao umepita kati ya nakala rudufu. Katika kesi hii, sehemu za historia zitahitajika kuongezwa kwa wingi na kuchanganuliwa, kwa sababu sio historia nzima inafaa katika sehemu kubwa. Na tu baada ya hii nakala inaweza kuhifadhi nakala kamili ya delta.
Kwenye grafu kila kitu kinaonekana rahisi zaidi. Hiki ni kipakuliwa kutoka kwa mojawapo ya makundi yetu halisi. Tuna LSN-msingi, iliyoundwa kwa siku moja. Na tunaona kwamba hifadhi rudufu ya delta inayotegemea LSN ilikuwa ikifanya kazi kuanzia saa tatu asubuhi hadi saa tano asubuhi. Hii ni mzigo katika idadi ya cores processor. WAL-delta ilituchukua kama dakika 20. Hiyo ni, ikawa kwa kasi zaidi, lakini wakati huo huo kulikuwa na kubadilishana kwa nguvu zaidi kwenye mtandao.
Kwa kuwa tuna habari kuhusu ni vizuizi vipi vilibadilika na ni wakati gani katika historia ya hifadhidata, tulienda mbali zaidi na tukaamua kujumuisha utendakazi - kiendelezi cha PostgreSQL kinachoitwa "pg_prefaulter"
Hii ina maana kwamba wakati msingi wa kusimama unatekeleza amri ya kurejesha, inawaambia WAL-G kuleta faili ya WAL inayofuata. Tunaelewa takriban data ambayo inazuia mchakato wa kurejesha WAL itafikia katika siku za usoni na kuanzisha operesheni ya kusoma kwenye vizuizi hivi. Hii ilifanyika ili kuongeza utendaji wa vidhibiti vya SSD. Kwa sababu safu ya WAL itafikia ukurasa unaohitaji kubadilishwa. Ukurasa huu uko kwenye diski na hauko kwenye akiba ya ukurasa. Na atasubiri kwa usawa kwa ukurasa huu kufika. Lakini karibu ni WAL-G, ambayo inajua kwamba katika megabytes mia chache ijayo ya WAL tutahitaji kurasa fulani na wakati huo huo huanza kuwasha moto. Huanzisha ufikiaji wa diski nyingi ili zitekelezwe kwa usawa. Hii inafanya kazi vizuri kwenye anatoa za SSD, lakini, kwa bahati mbaya, haitumiki kabisa kwa gari ngumu, kwa sababu tunaingilia tu na vidokezo vyetu.
Hiki ndicho kilicho kwenye kanuni sasa.
Kuna vipengele ambavyo tungependa kuongeza.
Picha hii inaonyesha kuwa WAL-delta inachukua muda mfupi kiasi. Na hii ni kusoma mabadiliko yaliyotokea katika hifadhidata wakati wa mchana. Tunaweza kufanya WAL-delta sio tu usiku, kwa sababu sio chanzo kikubwa cha mzigo. Tunaweza kusoma WAL-delta kila dakika kwa sababu ni nafuu. Kwa dakika moja tunaweza kuchambua mabadiliko yote ambayo yametokea kwenye nguzo. Na hii inaweza kuitwa "papo hapo WAL-delta".
Jambo ni kwamba tunaporejesha nguzo, tunapunguza idadi ya hadithi ambazo tunapaswa kukunja kwa mfuatano. Hiyo ni, kiasi cha WAL ambacho PostgreSQL rolls inapaswa kupunguzwa, kwa sababu inachukua muda muhimu.
Lakini sio hivyo tu. Ikiwa tunajua kuwa kizuizi fulani kitabadilishwa hadi kiwango cha uthabiti wa chelezo, hatuwezi kuibadilisha hapo awali. Hiyo ni, sasa tuna uboreshaji wa faili-kwa-faili ya usambazaji wa WAL-delta. Hii inamaanisha kwamba ikiwa, kwa mfano, Jumanne jedwali lilifutwa kabisa au faili zingine zilifutwa kabisa kutoka kwa jedwali, basi wakati delta inaendelea Jumatatu na Jumamosi pg_basebackup itarejeshwa, hatutaunda data hii.
Tunataka kupanua teknolojia hii hadi kiwango cha ukurasa. Hiyo ni, ikiwa sehemu fulani ya faili itabadilika Jumatatu, lakini itaandikwa tena Jumatano, basi wakati wa kurejesha kwa uhakika Alhamisi, hatuhitaji kuandika matoleo machache ya kwanza ya kurasa kwenye diski.
Lakini hili bado ni wazo ambalo linajadiliwa kikamilifu ndani yetu, lakini bado halijafikia kanuni.
Tunataka kutengeneza kipengele kimoja zaidi katika WAL-G. Tunataka kuifanya iweze kupanuliwa kwa sababu tunahitaji kutumia hifadhidata tofauti na tungependa kuwa na uwezo wa kushughulikia usimamizi wa chelezo kwa njia sawa. Lakini shida ni kwamba API za MySQL ni tofauti sana. Katika MySQL, PITR haitegemei logi ya WAL halisi, lakini kwenye binlog. Na hatuna mfumo wa kuhifadhi katika MySQL ambao ungeambia baadhi ya mfumo wa nje kwamba binlog hii imekamilika na inahitaji kuhifadhiwa kwenye kumbukumbu. Tunahitaji kusimama mahali fulani kwenye cron na hifadhidata na angalia ikiwa kuna kitu tayari?
Na kwa njia hiyo hiyo, wakati wa kurejesha MySQL, hakuna amri ya kurejesha ambayo inaweza kuwaambia mfumo kwamba ninahitaji faili hizo na vile. Kabla ya kuanza kuunda upya nguzo yako, unahitaji kujua ni faili gani utahitaji. Wewe mwenyewe unahitaji nadhani ni faili gani utahitaji. Lakini shida hizi zinaweza kuepukwa kwa njia fulani. (Ufafanuzi: MySQL tayari inatumika)
Katika ripoti hiyo, nilitaka pia kuzungumzia visa hivyo wakati WAL-G haikufaa.
Ikiwa huna nakala inayosawazishwa, WAL-G haihakikishii kuwa sehemu ya mwisho itahifadhiwa. Na ikiwa uhifadhi unabaki nyuma ya sehemu chache za mwisho za historia, hiyo ni hatari. Ikiwa hakuna nakala inayolingana, singependekeza kutumia WAL-G. Bado, imeundwa kwa usakinishaji wa wingu, ambayo inamaanisha suluhisho la Upatikanaji wa Juu na nakala inayolingana, ambayo inawajibika kwa usalama wa baiti za mwisho zilizofanywa.
Mara nyingi mimi huona watu wakijaribu kuendesha WAL-G na WAL-E kwa wakati mmoja. Tunakubali uoanifu wa nyuma kwa maana kwamba WAL-G inaweza kurejesha faili kutoka kwa WAL-E na inaweza kurejesha nakala iliyofanywa katika WAL-E. Lakini kwa kuwa mifumo yote miwili hutumia wal-push sambamba, huanza kuiba faili kutoka kwa kila mmoja. Tukiirekebisha katika WAL-G, bado itasalia katika WAL-E. Katika WAL-E, inaangalia hali ya kumbukumbu, huona faili zilizokamilishwa na kuziweka kwenye kumbukumbu, wakati mifumo mingine haitajua kuwa faili hii ya WAL ilikuwepo, kwa sababu PostgreSQL haitajaribu kuiweka kwenye kumbukumbu mara ya pili.
Tutarekebisha nini hapa kwa upande wa WAL-G? Hatutaarifu PostgreSQL kwamba faili hii ilihamishwa sambamba, na PostgreSQL inapotuuliza tuiweke kwenye kumbukumbu, tutajua tayari kwamba faili kama hii iliyo na hali hii ya wakati na md5 hii tayari imehifadhiwa kwenye kumbukumbu na tutasema tu PostgreSQL - Sawa, kila kitu kiko tayari bila kufanya chochote.
Lakini shida hii haiwezekani kusuluhishwa kwa upande wa WAL-E, kwa hivyo kwa sasa haiwezekani kuunda amri ya kumbukumbu ambayo itahifadhi faili katika WAL-G na WAL-E.
Kwa kuongeza, kuna matukio ambapo WAL-G haifai kwako sasa, lakini hakika tutairekebisha.
Kwanza, kwa sasa hatuna uthibitishaji wa chelezo uliojumuishwa. Hatuna uthibitishaji wakati wa kuhifadhi au kurejesha. Bila shaka, hii inatekelezwa katika wingu. Lakini hii inatekelezwa tu kwa kukagua mapema, kwa kurejesha nguzo. Ningependa kutoa utendakazi huu kwa watumiaji. Lakini kwa uthibitishaji, nadhani kuwa katika WAL-G itawezekana kurejesha nguzo na kuianzisha, na kuendesha vipimo vya moshi: pg_dumpall kwa /dev/null na uthibitishaji wa index ya amcheck.
Hivi sasa katika WAL-G hakuna njia ya kuahirisha nakala moja kutoka kwa WAL. Hiyo ni, tunaunga mkono dirisha fulani. Kwa mfano, kuhifadhi siku saba zilizopita, kuhifadhi nakala kumi za mwisho, kuhifadhi nakala tatu za mwisho kamili. Mara nyingi watu huja na kusema: "Tunahitaji nakala rudufu ya kile kilichotokea kwenye Mwaka Mpya na tunataka kuuhifadhi milele." WAL-G haiwezi kufanya hivi bado. (Kumbuka - Hili tayari limerekebishwa. Soma zaidi - Chaguo la chelezo-alama ndani )
Na hatuna ukaguzi wa kurasa na ukaguzi wa uadilifu kwa sehemu zote za shimoni wakati wa kuhalalisha PITR.
Kutokana na haya yote niliweka pamoja mradi wa Majira ya Msimbo ya Google. Ikiwa unajua wanafunzi mahiri ambao wangependa kuandika kitu katika Go na kupata dola elfu kadhaa kutoka kwa kampuni moja yenye herufi "G", basi wapendekeze mradi wetu. Nitafanya kama mshauri wa mradi huu, wanaweza kuifanya. Ikiwa hakuna wanafunzi, basi nitaichukua na kuifanya mwenyewe katika msimu wa joto.
Na tuna matatizo mengine mengi madogo ambayo hatua kwa hatua tunayafanyia kazi. Na mambo ya ajabu ajabu kutokea.
Kwa mfano, ikiwa utaipa WAL-G nakala tupu, itaanguka tu. Kwa mfano, ukimwambia kwamba anahitaji kuhifadhi folda tupu. pg_control faili haitakuwa hapo. Na atafikiri kwamba haelewi kitu. Kwa nadharia, katika kesi hii unahitaji kuandika ujumbe wa kawaida kwa mtumiaji kuelezea jinsi ya kutumia chombo. Lakini hii sio hata kipengele cha programu, lakini kipengele cha lugha nzuri, inayoeleweka.
Hatujui jinsi ya kuhifadhi nakala nje ya mtandao. Ikiwa hifadhidata ni ya uwongo, hatuwezi kuihifadhi. Lakini kila kitu ni rahisi sana hapa. Tunaita chelezo na LSN ilipoanza. LSN ya msingi wa msingi lazima isomwe kutoka kwa faili ya udhibiti. Na hii ni sifa isiyoweza kufikiwa. Mifumo mingi ya chelezo inaweza kuhifadhi hifadhidata ya msingi. Na ni rahisi.
Kwa sasa hatuwezi kushughulikia ukosefu wa nafasi ya kuhifadhi ipasavyo. Kwa sababu huwa tunafanya kazi na chelezo kubwa nyumbani. Na hawakufikia karibu nayo. Lakini ikiwa mtu anataka kupanga katika Go sasa hivi, ongeza kushughulikia makosa ya nje ya nafasi kwenye ndoo. Hakika nitaangalia ombi la kuvuta.
Na jambo kuu ambalo linatutia wasiwasi ni kwamba tunataka vipimo vingi vya ujumuishaji wa docker iwezekanavyo ili kuangalia hali tofauti. Hivi sasa tunajaribu hali za kimsingi pekee. Kwa kila ahadi, lakini tunataka kuangalia kujitolea-kwa-kutekeleza utendakazi wote tunaounga mkono. Hasa, kwa mfano, tutakuwa na usaidizi wa kutosha kwa PostgreSQL 9.4-9.5. Tunaziunga mkono kwa sababu jumuiya inaunga mkono PostgreSQL, lakini hatuangalii ahadi-kwa-kuhakikisha kuwa kila kitu hakijavunjwa. Na inaonekana kwangu kuwa hii ni hatari kubwa.
Tuna WAL-G inayoendesha zaidi ya vikundi elfu moja katika usimamizi wa Hifadhidata ya Yandex. Na huhifadhi nakala za data mia kadhaa kila siku.
Tuna TODO nyingi katika nambari yetu. Ikiwa unataka kupanga, njoo, tunangojea maombi ya kuvuta, tunangojea maswali.
maswali
Habari za jioni! Asante! Nadhani yangu ni kwamba ikiwa unatumia WAL-delta, labda unategemea sana uandishi wa ukurasa kamili. Na ikiwa ni hivyo, uliendesha majaribio? Ulionyesha grafu nzuri. Je, inakuwa nzuri zaidi ikiwa FPW imezimwa?
Uandishi wa ukurasa kamili umewezeshwa kwa ajili yetu, hatujajaribu kuuzima. Hiyo ni, mimi, kama msanidi programu, sijajaribu kuizima. Wasimamizi wa mfumo ambao wametafiti labda wametafiti suala hili. Lakini tunahitaji FPW. Karibu hakuna mtu anayeizima, kwa sababu vinginevyo haiwezekani kuchukua nakala rudufu kutoka kwa nakala.
Asante kwa ripoti! Nina maswali mawili. Swali la kwanza ni nini kitatokea kwa nafasi za meza?
Tunasubiri ombi la kuvuta. Hifadhidata zetu zinaishi kwenye diski za SSD na NMVE na hatuhitaji kabisa kipengele hiki. Siko tayari kutumia wakati mzito sasa hivi kuifanya vizuri. Naomba kwa moyo wote tuunge mkono hili. Kuna watu waliiunga mkono, lakini waliiunga mkono kwa njia inayowafaa. Walifanya uma, lakini hawafanyi maombi ya kuvuta. (Imeongezwa katika toleo la 0.2.13)
Na swali la pili. Ulisema mwanzoni kwamba WAL-G inadhania kuwa inafanya kazi peke yake na hakuna vifungashio vinavyohitajika. Ninatumia kanga mwenyewe. Kwa nini zisitumike?
Tunataka iwe rahisi kama balalaika. Hii ina maana kwamba huhitaji kitu chochote isipokuwa balalaika. Tunataka mfumo uwe rahisi. Ikiwa una utendakazi unaohitaji kufanya katika hati, basi njoo utuambie - tutafanya hivyo katika Go.
Habari za jioni! Asante kwa ripoti! Hatukuweza kupata WAL-G kufanya kazi na utembuaji wa GPG. Husimbwa kwa njia fiche kawaida, lakini haitaki kusimbua. Je, ni jambo ambalo halijatufaa? Hali inasikitisha.
Unda suala kwenye GitHub na tuisuluhishe.
Hiyo ni, haujakutana na hii?
Kuna kipengele cha ripoti ya makosa ambayo WAL-G haielewi ni aina gani ya faili, inauliza: "Labda imesimbwa kwa njia fiche?" Labda shida sio usimbaji fiche hata kidogo. Ninataka kuboresha ukataji miti kwenye mada hii. Lazima aichambue. Kwa sasa tunashughulikia mada hii kwa maana kwamba hatupendi kabisa jinsi mfumo wa kupata funguo za umma na za kibinafsi unavyopangwa. Kwa sababu tunaita GPG ya nje ili inatupa funguo zake. Na kisha tunachukua funguo hizi na kuzihamisha kwa GPG ya ndani, ambayo ni wazi PGP, ambayo imetungwa kwa ajili yetu ndani ya WAL-G, na huko tunaita usimbaji fiche. Katika suala hili, tunataka kuboresha mfumo na tunataka kuunga mkono usimbaji fiche wa Libsodium (Imeongezwa katika toleo la 0.2.15). Kwa kweli, kuorodhesha kunapaswa kufanya kazi, wacha tufikirie - unahitaji zaidi ya dalili kuliko maneno kadhaa. Unaweza kukusanyika kwenye chumba cha mzungumzaji wakati fulani na uangalie mfumo. (Usimbaji fiche wa PGP bila GPG ya nje - v0.2.9)
Habari! Asante kwa ripoti! Nina maswali mawili. Nina hamu ya kushangaza ya kufanya pg_basebackup na WAL kuingia kwa watoa huduma wawili, i.e. ninataka kufanya wingu moja na lingine. Kuna njia fulani ya kufanya hivi?
Hili halipo sasa, lakini ni wazo la kuvutia.
Simwamini mtoaji mmoja tu, ninataka kuwa sawa katika mwingine, ikiwa tu.
Wazo hilo linavutia. Kitaalam, hii sio ngumu kutekeleza. Ili kuzuia wazo kupotea, naweza kukuuliza ufanye suala kwenye GitHub?
Ndio kweli.
Na kisha, wanafunzi wanapokuja kwenye Google Majira ya Kanuni, tutawaongeza kwenye mradi ili kuwe na kazi zaidi ya kupata zaidi kutoka kwao.
Na swali la pili. Kuna suala kwenye GitHub. Nadhani tayari imefungwa. Kuna hofu wakati wa kurejesha. Na ili kulishinda, ulifanya kusanyiko tofauti. Ni sawa katika masuala. Na kuna chaguo kufanya mazingira ya kutofautiana katika thread moja. Na ndiyo sababu inafanya kazi polepole sana. Na tulikumbana na tatizo hili, na bado halijarekebishwa.
Shida ni kwamba kwa sababu fulani hifadhi (CEPH) huweka upya muunganisho tunapoifikia kwa kutumia sarafu ya juu. Je, nini kifanyike kuhusu hili? Mantiki ya kujaribu tena inaonekana kama hii. Tunajaribu kupakua faili tena. Katika kupita moja, tulikuwa na idadi ya faili ambazo hazijapakuliwa, tutafanya ya pili kwa wale wote ambao hawakuingia. Na mradi angalau faili moja imepakiwa kwa iteration, tunarudia na kurudia na kurudia. Tuliboresha mantiki ya kujaribu tena - urejesho wa kielelezo. Lakini sio wazi kabisa nini cha kufanya na ukweli kwamba unganisho huvunjika tu kwenye upande wa mfumo wa uhifadhi. Hiyo ni, tunapopakia kwenye mkondo mmoja, haivunji miunganisho hii. Tunaweza kuboresha nini hapa? Tuna msongamano wa mtandao, tunaweza kuweka kikomo kwa kila muunganisho kwa idadi ya baiti inazotuma. Vinginevyo, sijui jinsi ya kukabiliana na ukweli kwamba hifadhi ya kitu haituruhusu kupakua au kupakua kutoka kwayo kwa sambamba.
Hakuna SLA? Je, haikuandikwa kwa ajili yao jinsi wanavyojiruhusu kuteswa?
Jambo ni kwamba watu wanaokuja na swali hili kawaida wana vault yao wenyewe. Hiyo ni, hakuna mtu anayetoka Amazon au Google Cloud au Yandex Object Storage.
Labda swali sio kwako tena?
Swali hapa katika kesi hii haijalishi kwa nani. Ikiwa kuna maoni yoyote juu ya jinsi ya kushughulikia hii, wacha tuifanye katika WAL-G. Lakini hadi sasa sina mawazo mazuri juu ya jinsi ya kukabiliana na hili. Kuna baadhi ya Hifadhi ya Kitu ambayo inasaidia kuorodhesha nakala tofauti. Unawauliza waorodheshe vitu, na wanaongeza folda hapo. WAL-G anaogopa na hii - kuna aina fulani ya kitu hapa ambacho sio faili, siwezi kuirejesha, ambayo inamaanisha kuwa nakala rudufu haikurejeshwa. Hiyo ni, kwa kweli, una nguzo iliyorejeshwa kabisa, lakini inakurudishia hali yenye makosa kwa sababu Hifadhi ya Kitu ilirejesha habari fulani ya kushangaza ambayo haikuelewa kikamilifu.
Hili ni jambo linalotokea kwenye wingu la Barua.
Ikiwa unaweza kuunda nakala ...
Inatolewa mara kwa mara...
Ikiwa kuna nakala, basi nadhani tutajaribu mikakati ya kujaribu tena na tutafute jinsi ya kujaribu tena na kuelewa kile ambacho wingu linahitaji kutoka kwetu. Labda itakuwa imara kwa ajili yetu juu ya viunganisho vitatu na haitavunja uhusiano, basi tutafikia kwa makini tatu. Kwa sababu sasa tunaacha uunganisho haraka sana, i.e. ikiwa tulizindua urejeshaji na nyuzi 16, basi baada ya jaribio la kwanza kutakuwa na nyuzi 8, nyuzi 4, nyuzi 2 na moja. Na kisha itavuta faili kwenye mkondo mmoja. Ikiwa kuna maadili ya uchawi kama nyuzi 7,5 ni bora kwa kusukuma, basi tutakaa juu yao na kujaribu kutengeneza nyuzi nyingine 7,5. Hapa kuna wazo.
Asante kwa ripoti! Mtiririko kamili wa kufanya kazi na WAL-G unaonekanaje? Kwa mfano, katika kesi ya kijinga wakati hakuna delta kwenye kurasa. Na sisi kuchukua na kuondoa Backup awali, kisha archive shimoni mpaka sisi ni bluu usoni. Hapa, kama ninavyoelewa, kuna kuvunjika. Wakati fulani unahitaji kufanya nakala rudufu ya kurasa, i.e. mchakato fulani wa nje unaendesha hii au hii inafanyikaje?
API ya chelezo ya delta ni rahisi sana. Kuna nambari huko - hatua max delta, hiyo ndiyo inaitwa. Inabadilika kuwa sifuri. Hii ina maana kwamba kila wakati unapofanya Backup-push, inapakua chelezo kamili. Ikiwa utaibadilisha kwa nambari yoyote chanya, kwa mfano, 3, basi wakati ujao utafanya nakala rudufu, inaangalia historia ya chelezo zilizopita. Anaona kwamba hauzidi mlolongo wa delta 3 na hufanya delta.
Hiyo ni, kila wakati tunapozindua WAL-G, inajaribu kufanya nakala kamili?
Hapana, tunaendesha WAL-G, na inajaribu kutengeneza delta ikiwa sera zako zinaruhusu.
Kwa kusema, ikiwa utaiendesha na sifuri kila wakati, itakuwa kama pg_basebackup?
Hapana, bado itaendesha haraka kwa sababu inatumia mgandamizo na usawazishaji. Pg_basebackup itaweka shimoni karibu na wewe. WAL-G huchukulia kuwa umeweka uhifadhi kwenye kumbukumbu. Na itatoa onyo ikiwa haijasanidiwa.
Pg_basebackup inaweza kuendeshwa bila shafts.
Ndiyo, basi watakuwa na tabia karibu sawa. Pg_basebackup nakala kwa mfumo wa faili. Kwa njia, tuna kipengele kipya ambacho nilisahau kutaja. Sasa tunaweza kuhifadhi nakala kwenye mfumo wa faili kutoka pg_basebackup. Sijui kwa nini hii inahitajika, lakini iko.
Kwa mfano, kwenye CephFS. Sio kila mtu anataka kusanidi Hifadhi ya Kitu.
Ndiyo, labda ndiyo sababu waliuliza swali kuhusu kipengele hiki ili tuweze kufanya hivyo. Na tulifanya hivyo.
Asante kwa ripoti! Kuna swali tu kuhusu kunakili kwenye mfumo wa faili. Nje ya kisanduku, je, sasa unaauni kunakili kwenye hifadhi ya mbali, kwa mfano, ikiwa kuna rafu katika kituo cha data au kitu kingine?
Katika uundaji huu, hili ni swali gumu. Ndiyo, tunakubali, lakini utendakazi huu bado haujajumuishwa katika toleo lolote. Hiyo ni, matoleo yote ya awali yanaunga mkono hili, lakini matoleo ya kutolewa hayafai. Utendaji huu uliongezwa katika toleo la 0.2. Hakika itatolewa hivi karibuni, mara tu tutakaporekebisha hitilafu zote zinazojulikana. Lakini hivi sasa hii inaweza tu kufanywa katika toleo la awali. Kuna hitilafu mbili katika toleo la awali. Tatizo na urejeshaji wa WAL-E, hatujarekebisha. Na katika toleo la hivi majuzi zaidi, hitilafu kuhusu hifadhi rudufu ya delta iliongezwa. Kwa hivyo, tunapendekeza kila mtu atumie matoleo ya toleo. Punde tu kunapokuwa hakuna hitilafu katika toleo la awali, tunaweza kusema kwamba tunaauni Google Cloud, vitu vinavyooana na S3 na hifadhi ya faili.
Habari, asante kwa ripoti. Kama ninavyoelewa, WAL-G sio aina fulani ya mfumo wa kati kama barmen? Je! unapanga kuhamia katika mwelekeo huu?
Tatizo ni kwamba tumetoka katika mwelekeo huu. WAL-G anaishi kwenye seva pangishi ya msingi, kwenye seva pangishi ya nguzo, na wapangishi wote kwenye kundi. Tulipohamia kwenye vikundi elfu kadhaa, tulikuwa na mitambo mingi ya wahudumu wa baa. Na kila wakati kitu kinapoanguka ndani yao, ni shida kubwa. Kwa sababu zinahitaji kurekebishwa, unahitaji kuelewa ni nguzo gani ambazo hazina nakala rudufu. Sina mpango wa kukuza WAL-G katika mwelekeo wa vifaa vya kimwili kwa mifumo ya chelezo. Ikiwa jamii inataka utendaji fulani hapa, sijali hata kidogo.
Tuna timu ambazo zina jukumu la kuhifadhi. Na tunajisikia vizuri sana kwamba sio sisi, kwamba kuna watu maalum ambao huweka faili zetu mahali ambapo faili ziko salama. Wanafanya kila aina ya usimbaji wa werevu hapo ili kuhimili upotevu wa idadi fulani ya faili. Wanawajibika kwa bandwidth ya mtandao. Unapokuwa na bartender, unaweza kugundua ghafla kwamba hifadhidata ndogo zilizo na trafiki nyingi zimekusanyika kwenye seva moja. Unaonekana kuwa na nafasi nyingi juu yake, lakini kwa sababu fulani kila kitu haifai kupitia mtandao. Inaweza kugeuka kwa njia nyingine kote. Kuna mitandao mingi huko, kuna cores za processor, lakini hakuna disks hapa. Na tulichoka na hitaji hili la kugeuza kitu, na tukahamia ukweli kwamba uhifadhi wa data ni huduma tofauti, ambayo watu maalum huwajibika.
P.S Toleo jipya limetolewa , ambayo unaweza kutumia faili ya usanidi ya .walg.json, ambayo iko kwenye saraka ya nyumbani ya postgres kwa chaguo-msingi. Unaweza kuachana na maandishi ya bash. Mfano .walg.json iko katika toleo hili
Video:
Chanzo: mapenzi.com