Utangulizi

Wakati fulani uliopita nilipewa jukumu la kuunda nguzo ya kushindwa kwa PostgreSQL, inayofanya kazi katika vituo kadhaa vya data vilivyounganishwa kwa nyuzi macho ndani ya jiji moja, na vinavyoweza kuhimili hitilafu (kwa mfano, kukatika) kwa kituo kimoja cha data. Kama programu ambayo inawajibika kwa uvumilivu wa makosa, nilichagua Mpakajikwa sababu hii ndio suluhisho rasmi kutoka kwa RedHat kwa kuunda nguzo za kushindwa. Ni nzuri kwa sababu RedHat hutoa msaada kwa ajili yake, na kwa sababu ufumbuzi huu ni wa ulimwengu wote (msimu). Kwa msaada wake, itawezekana kuhakikisha uvumilivu wa makosa sio tu ya PostgreSQL, lakini pia ya huduma zingine, ama kutumia moduli za kawaida au kuunda kwa mahitaji maalum.

Uamuzi huu ulizua swali la busara: nguzo ya kushindwa itakuwa ya kustahimili vipi? Ili kuchunguza hili, nilitengeneza benchi ya majaribio ambayo huiga makosa mbalimbali kwenye nodi za nguzo, inasubiri huduma kurejeshwa, kurejesha nodi iliyoshindwa, na inaendelea kupima kwa kitanzi. Mradi huu hapo awali uliitwa hapgsql, lakini baada ya muda nilichoshwa na jina, ambalo lilikuwa na vokali moja tu. Kwa hivyo, nilianza kuita hifadhidata zinazostahimili makosa (na IP ya kuelea ikielekeza kwao) krogan (mhusika kutoka kwa mchezo wa kompyuta ambamo viungo vyote muhimu vinarudiwa), na nodi, nguzo na mradi yenyewe tuchanka (sayari ambapo krogans wanaishi).

Sasa usimamizi umeruhusu fungua mradi kwa jamii ya chanzo wazi chini ya leseni ya MIT. README itatafsiriwa hivi karibuni kwa Kiingereza (kwa sababu inatarajiwa kwamba watumiaji wakuu watakuwa watengenezaji wa Pacemaker na PostgreSQL), na niliamua kuwasilisha toleo la zamani la Kirusi la README (sehemu) kwa namna ya makala hii.

Vikundi vinawekwa kwenye mashine pepe VirtualBox. Jumla ya mashine 12 za mtandaoni (36GiB kwa jumla) zitatumwa, ambazo zinaunda makundi 4 yanayostahimili hitilafu (chaguo tofauti). Vikundi viwili vya kwanza vinajumuisha seva mbili za PostgreSQL, ambazo ziko katika vituo tofauti vya data, na seva ya kawaida. kushuhudia c kifaa cha akidi (imepangishwa kwenye mashine ya bei nafuu ya mtandaoni katika kituo cha tatu cha data), ambayo hutatua kutokuwa na uhakika 50% / 50%, ukitoa kura yako kwa mojawapo ya vyama. Kundi la tatu katika vituo vitatu vya data: bwana mmoja, watumwa wawili, hapana kifaa cha akidi. Kundi la nne lina seva nne za PostgreSQL, mbili kwa kila kituo cha data: bwana mmoja, nakala zingine, na pia hutumia. kushuhudia c kifaa cha akidi. Ya nne inaweza kuhimili kushindwa kwa seva mbili au kituo kimoja cha data. Suluhisho hili linaweza kuongezwa kwa idadi kubwa ya nakala ikiwa ni lazima.

Huduma ya wakati sahihi ntpd pia imeundwa upya kwa uvumilivu wa makosa, lakini hutumia njia yenyewe ntpd (hali ya yatima) Seva iliyoshirikiwa kushuhudia hufanya kazi kama seva kuu ya NTP, ikisambaza wakati wake kwa vikundi vyote, na hivyo kusawazisha seva zote kwa kila mmoja. Kama kushuhudia inashindwa au kutengwa, basi moja ya seva za nguzo (ndani ya nguzo) itaanza kusambaza wakati wake. Uhifadhi wa msaidizi Wakala wa HTTP pia kupandishwa kwa kushuhudia, kwa msaada wake, mashine zingine za mtandaoni zinaweza kufikia hazina za Yum. Kwa kweli, huduma kama vile muda sahihi na seva mbadala kuna uwezekano mkubwa zaidi zitapangishwa kwenye seva maalum, lakini kwenye kibanda zinapangishwa. kushuhudia ili tu kuokoa idadi ya mashine na nafasi.

Matoleo

v0. Inafanya kazi na CentOS 7 na PostgreSQL 11 kwenye VirtualBox 6.1.

Muundo wa nguzo

Vikundi vyote vimeundwa ili viwe katika vituo vingi vya data, vilivyounganishwa katika mtandao mmoja bapa na lazima vihimili kushindwa au kutengwa kwa mtandao kwa kituo kimoja cha data. Ndiyo maana haiwezekani tumia kwa ulinzi dhidi ya mgawanyiko wa ubongo teknolojia ya kiwango cha pacemaker inayoitwa STONITH (Piga Nodi Nyingine Kichwani) au uzio. Kiini chake: ikiwa nodi kwenye nguzo zinaanza kushuku kuwa kuna kitu kibaya na nodi fulani, haijibu au inatenda vibaya, basi huizima kwa nguvu kupitia vifaa vya "nje", kwa mfano, kadi ya kudhibiti IPMI au UPS. . Lakini hii itafanya kazi tu katika hali ambapo, katika tukio la kushindwa moja, seva ya IPMI au UPS inaendelea kufanya kazi. Hapa tunapanga kulinda dhidi ya kushindwa kwa janga zaidi, wakati kituo kizima cha data kinashindwa (kwa mfano, kupoteza nguvu). Na kwa kukataa vile, kila kitu jiwe-vifaa (IPMI, UPS, nk) pia haitafanya kazi.

Badala yake, mfumo unategemea wazo la akidi. Nodes zote zina sauti, na wale tu ambao wanaweza kuona zaidi ya nusu ya nodes zote wanaweza kufanya kazi. Kiasi hiki cha "nusu + 1" inaitwa akidi. Ikiwa quorum haijafikiwa, basi node inaamua kuwa iko katika kutengwa kwa mtandao na lazima kuzima rasilimali zake, i.e. hivi ndivyo ilivyo ulinzi wa ubongo uliogawanyika. Ikiwa programu inayohusika na tabia hii haifanyi kazi, basi mlinzi, kwa mfano, kulingana na IPMI, atalazimika kufanya kazi.

Ikiwa idadi ya nodi ni sawa (nguzo katika vituo viwili vya data), basi kinachojulikana kama kutokuwa na uhakika kinaweza kutokea. 50% / 50% (hamsini na hamsini) wakati kutengwa kwa mtandao kunagawanya nguzo kwa nusu. Kwa hiyo, kwa idadi hata ya nodes, tunaongeza kifaa cha akidi ni daemoni isiyolipishwa ambayo inaweza kuzinduliwa kwenye mashine pepe ya bei nafuu katika kituo cha tatu cha data. Anatoa kura yake kwa mojawapo ya makundi (ambayo anaona), na hivyo kutatua kutokuwa na uhakika kwa 50%/50%. Nilitaja seva ambayo kifaa cha akidi kitazinduliwa kushuhudia (istilahi kutoka kwa repmgr, niliipenda).

Rasilimali zinaweza kuhamishwa kutoka mahali hadi mahali, kwa mfano, kutoka kwa seva mbovu hadi zile zenye afya, au kwa amri ya wasimamizi wa mfumo. Ili wateja wajue ni wapi rasilimali wanazohitaji ziko (wapi pa kuunganishwa?), IP inayoelea (kuelea IP) Hizi ni IP ambazo Pacemaker inaweza kuzunguka nodi (kila kitu kiko kwenye mtandao tambarare). Kila mmoja wao anaashiria rasilimali (huduma) na itakuwa iko ambapo unahitaji kuunganishwa ili kupata huduma hii (kwa upande wetu, hifadhidata).

Tuchanka1 (mzunguko na compaction)

Muundo

Wazo lilikuwa kwamba tuna hifadhidata nyingi ndogo zilizo na mzigo mdogo, ambayo haina faida kudumisha seva iliyojitolea ya watumwa katika hali ya kusubiri ya moto kwa shughuli za kusoma tu (hakuna haja ya upotevu wa rasilimali).

Kila kituo cha data kina seva moja. Kila seva ina hali mbili za PostgreSQL (katika istilahi za PostgreSQL zinaitwa nguzo, lakini ili kuzuia machafuko nitaziita mifano (kwa mlinganisho na hifadhidata zingine), na nitaita tu nguzo za Pacemaker). Mfano mmoja hufanya kazi katika hali kuu, na tu hutoa huduma (IP tu ya kuelea inaongoza kwake). Mfano wa pili hufanya kazi kama mtumwa wa kituo cha pili cha data, na itatoa huduma ikiwa tu bwana wake atashindwa. Kwa kuwa mara nyingi ni mfano mmoja tu kati ya mbili (bwana) atatoa huduma (fanya maombi), rasilimali zote za seva zimeboreshwa kwa bwana (kumbukumbu imetengwa kwa kache ya shared_buffers, nk), lakini ili mfano wa pili. pia ina rasilimali za kutosha ( ingawa kwa operesheni ndogo kupitia kashe ya mfumo wa faili) ikiwa moja ya vituo vya data itashindwa. Mtumwa haitoi huduma (haifanyi maombi ya kusoma tu) wakati wa operesheni ya kawaida ya nguzo, ili hakuna vita kwa rasilimali na bwana kwenye mashine moja.

Katika kesi ya nodes mbili, uvumilivu wa kosa unawezekana tu kwa kurudia kwa asynchronous, kwa kuwa kwa kurudia kwa synchronous, kushindwa kwa mtumwa kutasababisha kuacha kwa bwana.

Kushindwa kushuhudia

Kushindwa kushuhudia (kifaa cha akidi) Nitazingatia tu kwa nguzo ya Tuchanka1, pamoja na wengine wote itakuwa hadithi sawa. Ikiwa shahidi itashindwa, hakuna kitu kitakachobadilika katika muundo wa nguzo, kila kitu kitaendelea kufanya kazi kwa njia ile ile. Lakini akidi itakuwa 2 kati ya 3, na kwa hivyo kutofaulu yoyote baadae itakuwa mbaya kwa nguzo. Bado itabidi kurekebishwa haraka.

Tuchanka1 kukataa

Kushindwa kwa mojawapo ya vituo vya data vya Tuchanka1. Kwa kesi hii kushuhudia inapiga kura yake kwa nodi ya pili katika kituo cha pili cha data. Huko, mtumwa wa zamani anageuka kuwa bwana, kwa sababu hiyo, mabwana wote wawili hufanya kazi kwenye seva moja na IPs zao zote mbili za kuelea zinawaelekeza.

Tuchanka2 (ya classical)

Muundo

Mpango wa classic wa nodi mbili. Bwana anafanya kazi kwa mmoja, mtumwa kwa pili. Wote wanaweza kutekeleza maombi (mtumwa anasomwa tu), kwa hivyo zote mbili zinaelekezwa kwa IP ya kuelea: krogan2 ndiye bwana, krogan2s1 ni mtumwa. Bwana na mtumwa watakuwa na uvumilivu wa makosa.

Katika kesi ya nodes mbili, uvumilivu wa kosa huwezekana tu kwa kurudia kwa asynchronous, kwa sababu kwa kurudia kwa synchronous, kushindwa kwa mtumwa kutasababisha kuacha kwa bwana.

Tuchanka2 kukataa

Ikiwa moja ya vituo vya data itashindwa kushuhudia kura kwa wa pili. Kwenye kituo cha data pekee cha kufanya kazi, bwana atafufuliwa, na IP zote mbili za kuelea zitaelekeza kwake: bwana na mtumwa. Bila shaka, mfano lazima usanidiwe kwa njia ambayo ina rasilimali za kutosha (vikomo vya uunganisho, nk) ili kukubali wakati huo huo miunganisho yote na maombi kutoka kwa IP ya bwana na mtumwa. Hiyo ni, wakati wa operesheni ya kawaida inapaswa kuwa na ugavi wa kutosha wa mipaka.

Tuchanka4 (watumwa wengi)

Muundo

Tayari mwingine uliokithiri. Kuna hifadhidata zinazopokea maombi mengi ya kusoma tu (kesi ya kawaida ya tovuti yenye mzigo mkubwa). Tuchanka4 ni hali ambapo kunaweza kuwa na watumwa watatu au zaidi kushughulikia maombi hayo, lakini bado sio wengi sana. Kwa idadi kubwa sana ya watumwa, itakuwa muhimu kuvumbua mfumo wa urudufishaji wa kihierarkia. Katika hali ya chini (katika picha), kila moja ya vituo viwili vya data vina seva mbili, kila moja ikiwa na mfano wa PostgreSQL.

Kipengele kingine cha mpango huu ni kwamba tayari inawezekana kuandaa replication moja ya synchronous. Imesanidiwa kuiga, ikiwezekana, kwa kituo kingine cha data, badala ya nakala iliyo katika kituo sawa cha data na mkuu. Bwana na kila mtumwa wanaelekezwa na IP ya kuelea. Kwa bahati nzuri, kati ya watumwa itakuwa muhimu kusawazisha maombi kwa namna fulani wakala wa sql, kwa mfano, kwa upande wa mteja. Aina tofauti za wateja zinaweza kuhitaji aina tofauti wakala wa sql, na watengenezaji mteja pekee ndio wanaojua ni nani anayehitaji. Utendaji huu unaweza kutekelezwa ama na daemoni ya nje au na maktaba ya mteja (dimbwi la muunganisho), nk. Haya yote yanapita zaidi ya mada ya nguzo ya faili ya faili (failover Wakala wa SQL inaweza kutekelezwa kwa kujitegemea, pamoja na uvumilivu wa makosa ya mteja).

Tuchanka4 kukataa

Ikiwa kituo kimoja cha data (yaani, seva mbili) kitashindwa, shahidi hupigia kura ya pili. Kama matokeo, seva mbili zinaendesha katika kituo cha pili cha data: moja inaendesha bwana, na bwana anaelea IP inaelekeza kwake (kwa kupokea maombi ya kusoma-kuandika); na kwenye seva ya pili kuna mtumwa anayeendesha na kurudiwa kwa usawazishaji, na moja ya IP ya kuelea ya watumwa inaelekeza kwake (kwa maombi ya kusoma tu).

Jambo la kwanza kukumbuka ni kwamba sio IP zote za kuelea kwa watumwa zitakuwa wafanyikazi, lakini moja tu. Na kufanya kazi nayo kwa usahihi itakuwa muhimu wakala wa sql ilielekeza maombi yote kwa IP pekee iliyobaki ya kuelea; na kama wakala wa sql hapana, basi unaweza kuorodhesha watumwa wote wa IP waliotenganishwa na koma kwenye URL ya unganisho. Katika kesi hii, na libpq uunganisho utakuwa kwa IP ya kwanza ya kazi, hii inafanywa katika mfumo wa kupima moja kwa moja. Labda katika maktaba zingine, kwa mfano, JDBC, hii haitafanya kazi na ni muhimu wakala wa sql. Hii inafanywa kwa sababu IP za kuelea kwa watumwa zimepigwa marufuku kuinuliwa kwa wakati mmoja kwenye seva moja, ili zisambazwe sawasawa kati ya seva za watumwa ikiwa kuna kadhaa kati yao zinazoendesha.

Pili: hata katika tukio la kushindwa kwa kituo cha data, uigaji wa synchronous utadumishwa. Na hata ikiwa hitilafu ya pili itatokea, ambayo ni, moja ya seva mbili kwenye kituo cha data kilichobaki itashindwa, nguzo, ingawa itaacha kutoa huduma, bado itahifadhi habari juu ya shughuli zote zilizofanywa ambazo imetoa uthibitisho wa ahadi. (hakutakuwa na taarifa ya hasara katika kesi ya kushindwa sekondari).

Tuchanka3 (vituo 3 vya data)

Muundo

Hili ni kundi la hali ambapo kuna vituo vitatu vya data vinavyofanya kazi kikamilifu, ambavyo kila kimoja kina seva ya hifadhidata inayofanya kazi kikamilifu. Kwa kesi hii kifaa cha akidi haihitajiki. Kituo kimoja cha data kinafanywa na bwana, wengine wawili wanafanya kazi na watumwa. Urudufishaji ni sawa, chapa ANY (slave1, slave2), yaani, mteja atapokea uthibitisho wa ahadi wakati mtumwa yeyote atakuwa wa kwanza kujibu kwamba amekubali ahadi. Rasilimali zinaonyeshwa na IP ya kuelea moja kwa bwana na mbili kwa watumwa. Tofauti na Tuchanka4, IP zote tatu za kuelea zinastahimili makosa. Ili kusawazisha hoja za SQL za kusoma tu unaweza kutumia wakala wa sql (pamoja na uvumilivu tofauti wa makosa), au toa IP ya kuelea kwa mtumwa kwa nusu ya wateja, na nusu nyingine kwa ya pili.

Tuchanka3 kukataa

Ikiwa moja ya vituo vya data itashindwa, mbili zinabaki. Katika moja, IP ya bwana na kuelea kutoka kwa bwana huinuliwa, kwa pili - mtumwa na IP za kuelea mtumwa (mfano lazima iwe na akiba mara mbili ya rasilimali ili kukubali miunganisho yote kutoka kwa IP za kuelea kwa watumwa). Urudiaji wa usawazishaji kati ya mabwana na watumwa. Pia, nguzo itahifadhi habari kuhusu shughuli zilizofanywa na zilizothibitishwa (hakutakuwa na hasara ya habari) katika tukio la uharibifu wa vituo viwili vya data (ikiwa haziharibiwa wakati huo huo).

Niliamua kutojumuisha maelezo ya kina ya muundo wa faili na upelekaji. Yeyote anayetaka kucheza anaweza kuisoma yote katika README. Ninatoa tu maelezo ya majaribio ya kiotomatiki.

Mfumo wa kupima otomatiki

Ili kupima uvumilivu wa makosa ya makundi kwa kuiga makosa mbalimbali, mfumo wa kupima kiotomatiki umeundwa. Imezinduliwa na hati test/failure. Hati inaweza kuchukua kama vigezo nambari za vikundi ambavyo ungependa kujaribu. Kwa mfano amri hii:

test/failure 2 3

itajaribu tu nguzo ya pili na ya tatu. Ikiwa vigezo havijabainishwa, basi nguzo zote zitajaribiwa. Vikundi vyote vinajaribiwa kwa sambamba, na matokeo yanaonyeshwa kwenye paneli ya tmux. Tmux hutumia seva maalum ya tmux, kwa hivyo hati inaweza kuendeshwa kutoka chini ya tmux chaguo-msingi, na kusababisha tmux iliyopangwa. Ninapendekeza kutumia terminal kwenye dirisha kubwa na kwa font ndogo. Kabla ya majaribio kuanza, mashine zote pepe hurejeshwa hadi kwenye muhtasari wakati hati inakamilika. setup.

Terminal imegawanywa katika safuwima kulingana na idadi ya nguzo zinazojaribiwa; kwa chaguo-msingi (kwenye picha ya skrini) kuna nne. Nitaelezea yaliyomo kwenye safu kwa kutumia mfano wa Tuchanka2. Paneli kwenye picha ya skrini zimepewa nambari:

1. Takwimu za majaribio zinaonyeshwa hapa. Safu wima:
   • kushindwa - jina la jaribio (kazi katika hati) inayoiga kosa.
   • mmenyuko - muda wa wastani wa hesabu katika sekunde ambapo nguzo ilipata utendakazi wake. Hupimwa tangu mwanzo wa hati inayoiga hitilafu hadi wakati ambapo nguzo itarejesha utendakazi wake na kuweza kuendelea kutoa huduma. Ikiwa wakati ni mfupi sana, kwa mfano, sekunde sita (hii hutokea kwa makundi na watumwa kadhaa (Tuchanka3 na Tuchanka4)), hii ina maana kwamba kosa lilikuwa kwa mtumwa wa asynchronous na halikuathiri utendaji kwa njia yoyote; swichi za hali ya nguzo.
   • kupotoka - inaonyesha kuenea (usahihi) wa thamani mmenyuko kwa kutumia njia ya kawaida ya kupotoka.
   • kuhesabu - ni mara ngapi jaribio hili lilifanyika.
2. Rekodi fupi hukuruhusu kutathmini kile kikundi kinafanya kwa sasa. Nambari ya kurudia (jaribio), muhuri wa muda na jina la operesheni huonyeshwa. Kukimbia kwa muda mrefu sana (> dakika 5) kunaonyesha tatizo.
3. moyo (moyo) - wakati wa sasa. Kwa tathmini ya kuona ya utendaji mabwana Wakati wa sasa umeandikwa kila mara kwa meza yake kwa kutumia bwana wa IP wa kuelea. Ikiwa imefanikiwa, matokeo yanaonyeshwa kwenye paneli hii.
4. kuwapiga (mapigo) - "wakati wa sasa", ambayo hapo awali ilirekodiwa na hati moyo kwa bwana, sasa soma kutoka mtumwa kupitia IP yake ya kuelea. Inakuruhusu kutathmini kuibua utendaji wa mtumwa na urudufishaji. Katika Tuchanka1 hakuna watumwa walio na IP ya kuelea (hakuna watumwa wanaotoa huduma), lakini kuna matukio mawili (DBs), kwa hivyo haitaonyeshwa hapa. kuwapigaNa moyo tukio la pili.
5. Kufuatilia afya ya nguzo kwa kutumia matumizi pcs mon. Inaonyesha muundo, usambazaji wa rasilimali kwenye nodi na habari zingine muhimu.
6. Ufuatiliaji wa mfumo kutoka kwa kila mashine pepe kwenye nguzo unaonyeshwa hapa. Kunaweza kuwa na paneli zaidi kama hizo kulingana na ni mashine ngapi pepe ambazo nguzo hiyo ina. Grafu mbili Mzigo wa CPU (mashine halisi zina vichakataji viwili), jina la mashine halisi, Mzigo wa Mfumo (iliyopewa Wastani wa Kupakia kwa sababu ni wastani wa dakika 5, 10 na 15), kuchakata data na mgao wa kumbukumbu.
7. Ufuatiliaji wa jaribio la maandishi. Katika tukio la malfunction - usumbufu wa ghafla wa operesheni au mzunguko usio na mwisho wa kusubiri - hapa unaweza kuona sababu ya tabia hii.

Upimaji unafanywa katika hatua mbili. Kwanza, hati hupitia aina zote za majaribio, ikichagua bila mpangilio mashine pepe ya kutumia jaribio hili. Kisha mzunguko usio na mwisho wa kupima unafanywa, mashine za kawaida na kosa huchaguliwa kwa nasibu kila wakati. Kukomesha ghafla kwa hati ya majaribio (jopo la chini) au kitanzi kisicho na mwisho cha kungoja kitu (> muda wa utekelezaji wa dakika 5 kwa operesheni moja, hii inaweza kuonekana katika ufuatiliaji) inaonyesha kuwa baadhi ya majaribio kwenye nguzo hii yameshindwa.

Kila jaribio lina shughuli zifuatazo:

1. Fungua chaguo la kukokotoa linaloiga hitilafu.
2. Tayari? — Kusubiri nguzo kurejeshwa (wakati huduma zote zinatolewa).
3. Inaonyesha muda wa urejeshaji wa nguzo (mmenyuko).
4. Fix - nguzo "inarekebishwa." Baada ya hapo inapaswa kurudi kwenye hali ya kufanya kazi kikamilifu na kuwa tayari kwa malfunction ijayo.

Hapa kuna orodha ya majaribio na maelezo ya kile wanachofanya:

• ForkBomb: Huunda "Nje ya kumbukumbu" kwa kutumia bomu la uma.
• OutOfSpace: Hifadhi ngumu imejaa. Lakini jaribio ni la mfano; na mzigo mdogo ambao huundwa wakati wa majaribio, PostgreSQL kawaida haishindwi wakati diski kuu imejaa.
• Postgres-KILL: inaua PostgreSQL na amri killall -KILL postgres.
• Postgres-STOP: hutegemea amri ya PostgreSQL killall -STOP postgres.
• Kuzima kwa Nguvu: "hupunguza nguvu" mashine pepe kwa amri VBoxManage controlvm "виртуалка" poweroff.
• Upya: hupakia mashine pepe kwa amri VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: husimamisha pepo wa SBD kwa amri killall -STOP sbd.
• Kuzimisha: hutuma amri kwa mashine ya kawaida kupitia SSH systemctl poweroff, mfumo huzima kwa uzuri.
• Tenganisha: kutengwa kwa mtandao, amri VBoxManage controlvm "виртуалка" setlinkstate1 off.

Kukamilisha majaribio kwa kutumia amri ya kawaida ya tmux "kill-window" Ctrl-b &, au amri ya "detach-client". Ctrl-b d: kwa wakati huu upimaji unaisha, tmux hufunga, mashine za mtandaoni zimezimwa.

Matatizo yaliyotambuliwa wakati wa kupima

• Kwa wakati huu pepo la mwangalizi sbd inafanya kazi katika kusimamisha damoni zinazozingatiwa, lakini sio kuzigandisha. Na, kwa sababu hiyo, makosa ambayo husababisha kufungia tu Corosync и Mpakaji, lakini sio kunyongwa sbd... Kwa hundi Corosync tayari PR#83 (kwenye GitHub saa sbd), imekubaliwa kwenye uzi bwana. Waliahidi (katika PR#83) kwamba kutakuwa na kitu sawa kwa Pacemaker, natumai kwamba ifikapo Kofia Nyekundu 8 nita fanya. Lakini "makosa" kama haya ni ya kubahatisha na yanaweza kuigwa kwa urahisi kwa kutumia, kwa mfano, killall -STOP corosync, lakini kamwe kukutana katika maisha halisi.

• У Mpakaji katika toleo la CentOS 7 imewekwa vibaya sync_timeout у kifaa cha akidi, matokeo yake ikiwa nodi moja imeshindwa, na uwezekano fulani nodi ya pili pia ilianza tena, ambayo bwana alitakiwa kuhamia. Kuponywa kwa upanuzi sync_timeout у kifaa cha akidi wakati wa kupeleka (katika script setup/setup1) Marekebisho haya hayakukubaliwa na wasanidi programu Mpakaji, badala yake waliahidi kuunda upya miundombinu kwa njia ambayo (katika siku zijazo zisizojulikana) kwamba muda huu wa kuisha utahesabiwa kiotomatiki.

• Ikiwa usanidi wa hifadhidata unabainisha hilo LC_MESSAGES (ujumbe wa maandishi) Unicode inaweza kutumika, k.m. ru_RU.UTF-8, kisha wakati wa kuanza postgres katika mazingira ambayo eneo sio UTF-8, sema katika mazingira tupu (hapa pacemaker+pgsqlms(paf) anaendesha postgres), basi logi itakuwa na alama za kuuliza badala ya herufi za UTF-8. Wasanidi wa PostgreSQL hawajakubaliana juu ya nini cha kufanya katika kesi hii. Ni gharama, unahitaji kufunga LC_MESSAGES=en_US.UTF-8 wakati wa kusanidi (kuunda) mfano wa hifadhidata.

• Ikiwa wal_receiver_timeout imewekwa (kwa chaguo-msingi ni 60s), basi wakati wa jaribio la PostgreSQL-STOP kwenye bwana kwenye nguzo za tuchanka3 na tuchanka4. urudufishaji hauunganishi tena na bwana mpya. Replication kuna synchronous, hivyo si tu mtumwa ataacha, lakini pia bwana mpya. Hufanya kazi kote kwa kuweka wal_receiver_timeout=0 wakati wa kusanidi PostgreSQL.

• Wakati mwingine niliona kuganda kwa urudufishaji katika PostgreSQL kwenye jaribio la ForkBomb (kumbukumbu kufurika). Baada ya ForkBomb, wakati mwingine watumwa hawawezi kuunganishwa tena na bwana mpya. Nimekutana na hii tu katika nguzo za tuchanka3 na tuchanka4, ambapo bwana aliganda kwa sababu ya uigaji wa synchronous. Tatizo liliondoka lenyewe baada ya muda mrefu (kama saa mbili). Utafiti zaidi unahitajika kurekebisha hili. Dalili ni sawa na mdudu uliopita, unaosababishwa na sababu tofauti, lakini kwa matokeo sawa.

Picha ya Krogan iliyochukuliwa kutoka deviant Art kwa idhini ya mwandishi:

Chanzo: mapenzi.com