Pagpapakilala

Ilang oras na ang nakalipas ay binigyan ako ng gawain ng pagbuo ng isang failover cluster para sa PostgreSQL, tumatakbo sa ilang mga data center na konektado ng optical fiber sa loob ng isang lungsod, at may kakayahang makayanan ang isang pagkabigo (halimbawa, blackout) ng isang data center. Bilang ang software na responsable para sa fault tolerance, pinili ko Pacemakerdahil ito ang opisyal na solusyon mula sa RedHat para sa paglikha ng mga failover cluster. Ito ay mabuti dahil ang RedHat ay nagbibigay ng suporta para dito, at dahil ang solusyon na ito ay pangkalahatan (modular). Sa tulong nito, magiging posible na matiyak ang fault tolerance hindi lamang ng PostgreSQL, kundi pati na rin ng iba pang mga serbisyo, alinman sa paggamit ng mga karaniwang module o paglikha ng mga ito para sa mga partikular na pangangailangan.

Ang desisyong ito ay nagtaas ng isang makatwirang tanong: gaano ka-fault-tolerant ang isang failover cluster? Upang imbestigahan ito, bumuo ako ng isang test bench na ginagaya ang iba't ibang mga pagkabigo sa mga cluster node, naghihintay na maibalik ang serbisyo, binabawi ang nabigong node, at nagpapatuloy sa pagsubok sa isang loop. Ang proyektong ito ay orihinal na tinatawag na hapgsql, ngunit sa paglipas ng panahon ay nainis ako sa pangalan, na mayroon lamang isang patinig. Samakatuwid, nagsimula akong tumawag sa mga database ng fault-tolerant (at float IP na tumuturo sa kanila) krogan (isang karakter mula sa isang laro sa computer kung saan ang lahat ng mahahalagang organ ay nadoble), at ang mga node, cluster at ang proyekto mismo ay tuchanka (ang planeta kung saan nakatira ang mga krogans).

Ngayon pinayagan na ng management buksan ang proyekto sa open source na komunidad sa ilalim ng lisensya ng MIT. Malapit nang maisalin ang README sa Ingles (dahil inaasahang ang pangunahing mga mamimili ay ang mga developer ng Pacemaker at PostgreSQL), at nagpasya akong ipakita ang lumang bersyon ng README na Ruso (bahagyang) sa anyo ng artikulong ito.

Naka-deploy ang mga cluster sa mga virtual machine VirtualBox. Kabuuang 12 virtual machine (kabuuang 36GiB) ang ide-deploy, na bumubuo ng 4 na fault-tolerant na cluster (iba't ibang opsyon). Ang unang dalawang kumpol ay binubuo ng dalawang PostgreSQL server, na matatagpuan sa iba't ibang data center, at isang karaniwang server Saksihan c aparato ng korum (naka-host sa isang murang virtual machine sa isang ikatlong data center), na lumulutas sa kawalan ng katiyakan 50% / 50%, pagbibigay ng iyong boto sa isa sa mga partido. Pangatlong kumpol sa tatlong data center: isang master, dalawang alipin, hindi aparato ng korum. Ang ikaapat na kumpol ay binubuo ng apat na PostgreSQL server, dalawa sa bawat data center: isang master, ang natitirang mga replika, at gumagamit din Saksihan c aparato ng korum. Ang ikaapat ay maaaring makatiis sa pagkabigo ng dalawang server o isang data center. Ang solusyon na ito ay maaaring i-scale sa mas malaking bilang ng mga replika kung kinakailangan.

Tumpak na oras ng serbisyo ntpd na-reconfigure din para sa fault tolerance, ngunit ginagamit nito ang mismong pamamaraan ntpd (orphan mode). Nakabahaging server Saksihan gumaganap bilang isang sentral na server ng NTP, na namamahagi ng oras nito sa lahat ng mga kumpol, sa gayon ay nagsi-synchronize ng lahat ng mga server sa isa't isa. Kung Saksihan nabigo o nagiging isolated, pagkatapos ay ang isa sa mga cluster server (sa loob ng cluster) ay magsisimulang ipamahagi ang oras nito. Pantulong na pag-cache HTTP proxy itinaas din sa Saksihan, sa tulong nito, ang ibang mga virtual machine ay may access sa mga imbakan ng Yum. Sa katotohanan, ang mga serbisyo tulad ng tumpak na oras at mga proxy ay malamang na mai-host sa mga dedikadong server, ngunit sa booth kung saan sila naka-host. Saksihan para lamang i-save ang bilang ng mga virtual machine at espasyo.

Mga Bersyon

v0. Gumagana sa CentOS 7 at PostgreSQL 11 sa VirtualBox 6.1.

Istruktura ng kumpol

Ang lahat ng mga cluster ay idinisenyo upang matatagpuan sa maraming data center, pinagsama sa isang flat network at dapat makatiis sa pagkabigo o network isolation ng isang solong data center. kaya lang ay imposible gamitin para sa proteksyon laban sa hating-utak karaniwang teknolohiya ng Pacemaker na tinatawag na STONITH (Shoot The Other Node Sa Ulo) o eskrima. Ang kakanyahan nito: kung ang mga node sa kumpol ay nagsimulang maghinala na may mali sa ilang node, hindi ito tumutugon o kumikilos nang hindi tama, pagkatapos ay pilit nilang i-off ito sa pamamagitan ng "panlabas" na mga aparato, halimbawa, isang IPMI o UPS control card . Ngunit ito ay gagana lamang sa mga kaso kung saan, sa kaganapan ng isang solong pagkabigo, ang IPMI o UPS server ay patuloy na gumagana. Dito, plano naming protektahan laban sa isang mas malaking kabiguan, kapag nabigo ang buong data center (halimbawa, nawalan ng kapangyarihan). At sa ganoong pagtanggi, lahat stonith-hindi rin gagana ang mga device (IPMI, UPS, atbp.).

Sa halip, ang sistema ay batay sa ideya ng korum. Ang lahat ng mga node ay may boses, at ang mga nakakakita lamang ng higit sa kalahati ng lahat ng mga node ang maaaring gumana. Ang dami na ito ng "kalahating + 1" ay tinatawag korum. Kung ang quorum ay hindi naabot, pagkatapos ay ang node ay nagpasya na ito ay nasa network isolation at dapat na patayin ang mga mapagkukunan nito, i.e. ito ay kung ano ito proteksyon ng split-brain. Kung ang software na responsable para sa pag-uugaling ito ay hindi gumagana, ang isang asong tagapagbantay, halimbawa, batay sa IPMI, ay kailangang gumana.

Kung ang bilang ng mga node ay pantay (isang kumpol sa dalawang data center), kung gayon ang tinatawag na kawalan ng katiyakan ay maaaring lumitaw 50% / 50% (limampu't limampu) kapag ang paghihiwalay ng network ay nahahati nang eksakto sa kalahati ang cluster. Samakatuwid, para sa pantay na bilang ng mga node, nagdaragdag kami aparato ng korum ay isang hindi hinihinging daemon na maaaring ilunsad sa pinakamurang virtual machine sa ikatlong data center. Ibinibigay niya ang kanyang boto sa isa sa mga segment (na nakikita niya), at sa gayon ay nalulutas ang 50%/50% na kawalan ng katiyakan. Pinangalanan ko ang server kung saan ilulunsad ang quorum device Saksihan (terminolohiya mula sa repmgr, nagustuhan ko ito).

Ang mga mapagkukunan ay maaaring ilipat mula sa isang lugar patungo sa lugar, halimbawa, mula sa mga may sira na server patungo sa malusog, o sa utos ng mga administrator ng system. Upang malaman ng mga kliyente kung saan matatagpuan ang mga mapagkukunan na kailangan nila (saan kumonekta?), lumulutang na IP (lumutang IP). Ito ang mga IP na maaaring ilipat ng Pacemaker sa paligid ng mga node (lahat ay nasa isang patag na network). Ang bawat isa sa kanila ay sumisimbolo sa isang mapagkukunan (serbisyo) at matatagpuan kung saan kailangan mong kumonekta upang makakuha ng access sa serbisyong ito (sa aming kaso, isang database).

Tuchanka1 (circuit na may compaction)

Kaayusan

Ang ideya ay mayroon kaming maraming maliliit na database na may mababang pag-load, kung saan hindi kapaki-pakinabang ang pagpapanatili ng isang dedikadong server ng alipin sa mainit na standby mode para sa mga read only na transaksyon (hindi na kailangan ang gayong pag-aaksaya ng mga mapagkukunan).

Ang bawat data center ay may isang server. Ang bawat server ay may dalawang PostgreSQL instance (sa terminolohiya ng PostgreSQL ay tinatawag silang mga cluster, ngunit upang maiwasan ang pagkalito ay tatawagin ko silang mga instance (sa pamamagitan ng pagkakatulad sa iba pang mga database), at tatawagin ko lang ang mga cluster ng Pacemaker). Ang isang instance ay gumagana sa master mode, at tanging ito ang nagbibigay ng mga serbisyo (tanging float IP ang humahantong dito). Ang pangalawang pagkakataon ay gumagana bilang isang alipin para sa pangalawang data center, at magbibigay lamang ng mga serbisyo kung nabigo ang master nito. Dahil kadalasan ay isang instance lamang sa dalawa (ang master) ang magbibigay ng mga serbisyo (gumawa ng mga kahilingan), ang lahat ng mga mapagkukunan ng server ay na-optimize para sa master (ang memorya ay inilalaan para sa shared_buffers cache, atbp.), ngunit upang ang pangalawang pagkakataon mayroon ding sapat na mapagkukunan (kahit na para sa suboptimal na operasyon sa pamamagitan ng cache ng file system) kung sakaling mabigo ang isa sa mga sentro ng data. Ang alipin ay hindi nagbibigay ng mga serbisyo (hindi nagsasagawa ng read only na mga kahilingan) sa panahon ng normal na operasyon ng cluster, upang walang digmaan para sa mga mapagkukunan sa master sa parehong makina.

Sa kaso ng dalawang node, ang fault tolerance ay posible lamang sa asynchronous replication, dahil sa synchronous replication, ang pagkabigo ng isang alipin ay hahantong sa paghinto ng master.

Pagkabigong sumaksi

Ang hindi pagsaksi (aparato ng korum) Isasaalang-alang ko lamang ang para sa kumpol ng Tuchanka1, kasama ang lahat ng iba pa ito ay magiging parehong kuwento. Kung nabigo ang saksi, walang magbabago sa istraktura ng cluster, ang lahat ay patuloy na gagana sa parehong paraan na ginawa nito. Ngunit ang korum ay magiging 2 sa 3, at samakatuwid ang anumang kasunod na pagkabigo ay mamamatay para sa cluster. Kakailanganin pa rin itong ayusin nang madalian.

Tuchanka1 pagtanggi

Pagkabigo ng isa sa mga data center para sa Tuchanka1. Sa kasong ito Saksihan bumoto sa pangalawang node sa pangalawang data center. Doon, ang dating alipin ay nagiging isang master, bilang isang resulta, ang parehong mga masters ay nagtatrabaho sa parehong server at pareho ng kanilang mga float IP ay tumuturo sa kanila.

Tuchanka2 (klasikal)

Kaayusan

Klasikong scheme ng dalawang node. Ang panginoon ay gumagawa sa isa, ang alipin sa pangalawa. Parehong maaaring magsagawa ng mga kahilingan (ang alipin ay nabasa lamang), kaya pareho ang itinuro ng float IP: krogan2 ang master, krogan2s1 ang alipin. Parehong ang panginoon at ang alipin ay magkakaroon ng fault tolerance.

Sa kaso ng dalawang node, ang fault tolerance ay posible lamang sa asynchronous replication, dahil sa synchronous replication, ang pagkabigo ng alipin ay hahantong sa paghinto ng master.

Tuchanka2 pagtanggi

Kung nabigo ang isa sa mga sentro ng data Saksihan boto para sa pangalawa. Sa tanging gumaganang data center, ang master ay itataas, at ang parehong float IP ay ituturo dito: ang master at ang alipin. Siyempre, dapat na i-configure ang instance sa paraang mayroon itong sapat na mapagkukunan (mga limitasyon sa koneksyon, atbp.) upang sabay na tanggapin ang lahat ng koneksyon at kahilingan mula sa master at slave float IP. Iyon ay, sa panahon ng normal na operasyon dapat itong magkaroon ng sapat na supply ng mga limitasyon.

Tuchanka4 (maraming alipin)

Kaayusan

Isa na namang extreme. May mga database na tumatanggap ng maraming read-only na kahilingan (isang tipikal na kaso ng isang high-load na site). Ang Tuchanka4 ay isang sitwasyon kung saan maaaring mayroong tatlo o higit pang mga alipin na hahawak ng mga naturang kahilingan, ngunit hindi pa rin masyadong marami. Sa napakaraming bilang ng mga alipin, kakailanganing mag-imbento ng hierarchical replication system. Sa pinakamababang kaso (sa larawan), ang bawat isa sa dalawang data center ay may dalawang server, bawat isa ay may instance ng PostgreSQL.

Ang isa pang tampok ng scheme na ito ay na posible na ayusin ang isang kasabay na pagtitiklop. Ito ay na-configure upang kopyahin, kung maaari, sa isa pang data center, sa halip na sa isang kopya sa parehong data center bilang master. Ang master at bawat alipin ay itinuro ng isang float IP. Sa kabutihang palad, sa pagitan ng mga alipin ay kinakailangan na balansehin ang mga kahilingan sa anumang paraan sql proxy, halimbawa, sa panig ng kliyente. Ang iba't ibang uri ng kliyente ay maaaring mangailangan ng iba't ibang uri sql proxy, at tanging mga developer ng kliyente ang nakakaalam kung sino ang nangangailangan ng alin. Ang functionality na ito ay maaaring ipatupad alinman sa pamamagitan ng isang panlabas na daemon o ng isang client library (connection pool), atbp. Ang lahat ng ito ay lampas sa paksa ng isang failover database cluster (failover SQL proxy maaaring ipatupad nang nakapag-iisa, kasama ang pagpapaubaya sa kasalanan ng kliyente).

Tuchanka4 pagtanggi

Kung nabigo ang isang data center (i.e., dalawang server), iboboto ng saksi ang pangalawa. Bilang resulta, mayroong dalawang server na tumatakbo sa pangalawang data center: ang isa ay nagpapatakbo ng master, at ang master float IP ay tumuturo dito (para sa pagtanggap ng mga read-write na kahilingan); at sa pangalawang server ay may isang alipin na tumatakbo na may kasabay na pagtitiklop, at ang isa sa mga alipin na float IP ay tumuturo dito (para sa mga read-only na kahilingan).

Ang unang bagay na dapat tandaan ay hindi lahat ng slave float IP ay magiging mga manggagawa, ngunit isa lamang. At upang gumana sa mga ito ng tama ito ay kinakailangan na sql proxy ni-redirect ang lahat ng kahilingan sa tanging natitirang float IP; at kung sql proxy hindi, maaari mong ilista ang lahat ng float IP slave na pinaghihiwalay ng mga kuwit sa URL ng koneksyon. Sa kasong ito, kasama libpq ang koneksyon ay magiging sa unang gumaganang IP, ito ay ginagawa sa awtomatikong sistema ng pagsubok. Marahil sa ibang mga aklatan, halimbawa, JDBC, hindi ito gagana at kinakailangan sql proxy. Ginagawa ito dahil ang mga float IP para sa mga alipin ay ipinagbabawal na itaas nang sabay-sabay sa isang server, upang ang mga ito ay pantay na ibinahagi sa mga server ng alipin kung marami sa kanila ang tumatakbo.

Pangalawa: kahit na sa kaganapan ng isang pagkabigo sa data center, ang kasabay na pagtitiklop ay pananatilihin. At kahit na mangyari ang pangalawang kabiguan, iyon ay, ang isa sa dalawang server sa natitirang data center ay nabigo, ang kumpol, bagama't ito ay hihinto sa pagbibigay ng mga serbisyo, ay mananatili pa rin ng impormasyon tungkol sa lahat ng nakatuon na mga transaksyon kung saan ito ay nagbigay ng kumpirmasyon ng pangako. (walang mawawalang impormasyon sa kaso ng pangalawang pagkabigo).

Tuchanka3 (3 data center)

Kaayusan

Ito ay isang kumpol para sa isang sitwasyon kung saan mayroong tatlong ganap na gumaganang data center, bawat isa ay may ganap na gumaganang database server. Sa kasong ito aparato ng korum hindi kailangan. Ang isang data center ay may tauhan ng isang master, ang iba pang dalawa ay may tauhan ng mga alipin. Ang pagtitiklop ay kasabay, i-type ang ANY (slave1, slave2), iyon ay, ang kliyente ay makakatanggap ng commit confirmation kapag sinuman sa mga alipin ang unang tumugon na tinanggap niya ang commit. Ang mga mapagkukunan ay ipinahiwatig ng isang float IP para sa master at dalawa para sa mga alipin. Hindi tulad ng Tuchanka4, lahat ng tatlong float IP ay fault-tolerant. Upang balansehin ang read-only na mga query sa SQL na magagamit mo sql proxy (na may hiwalay na fault tolerance), o magtalaga ng isang slave float IP sa kalahati ng mga kliyente, at ang kalahati sa pangalawa.

Tuchanka3 pagtanggi

Kung nabigo ang isa sa mga data center, dalawa ang mananatili. Sa isa, ang master at float IP mula sa master ay itataas, sa pangalawa - ang alipin at parehong alipin float IP (ang halimbawa ay dapat magkaroon ng isang dobleng reserba ng mga mapagkukunan upang tanggapin ang lahat ng mga koneksyon mula sa parehong alipin float IP). Kasabay na pagtitiklop sa pagitan ng mga panginoon at alipin. Gayundin, ang kumpol ay magse-save ng impormasyon tungkol sa nakatuon at nakumpirma na mga transaksyon (walang mawawala ang impormasyon) kung sakaling masira ang dalawang data center (kung hindi sila masisira nang sabay-sabay).

Nagpasya akong huwag isama ang isang detalyadong paglalarawan ng istraktura ng file at pag-deploy. Ang sinumang gustong makipaglaro ay maaaring basahin ang lahat ng ito sa README. Nagbibigay lang ako ng paglalarawan ng awtomatikong pagsubok.

Awtomatikong sistema ng pagsubok

Upang subukan ang fault tolerance ng mga cluster sa pamamagitan ng pagtulad sa iba't ibang mga fault, isang awtomatikong sistema ng pagsubok ang nilikha. Inilunsad sa pamamagitan ng script test/failure. Maaaring gawin ng script bilang mga parameter ang bilang ng mga cluster na gusto mong subukan. Halimbawa ang utos na ito:

test/failure 2 3

susubukan lamang ang pangalawa at pangatlong cluster. Kung hindi tinukoy ang mga parameter, susuriin ang lahat ng cluster. Ang lahat ng mga kumpol ay sinubok nang magkatulad, at ang resulta ay ipinapakita sa tmux panel. Gumagamit ang Tmux ng nakalaang tmux server, kaya maaaring patakbuhin ang script mula sa ilalim ng default na tmux, na nagreresulta sa isang nested tmux. Inirerekomenda ko ang paggamit ng terminal sa isang malaking window at may maliit na font. Bago magsimula ang pagsubok, ang lahat ng virtual machine ay ibabalik sa isang snapshot sa oras na makumpleto ang script setup.

Ang terminal ay nahahati sa mga column ayon sa bilang ng mga cluster na sinusuri; bilang default (sa screenshot) mayroong apat. Ilalarawan ko ang mga nilalaman ng mga column gamit ang halimbawa ng Tuchanka2. Ang mga panel sa screenshot ay may bilang:

1. Ang mga istatistika ng pagsubok ay ipinapakita dito. Mga hanay:
   • pagkabigo — ang pangalan ng pagsubok (function sa script) na tumutulad sa kasalanan.
   • reaksyon — average na oras ng arithmetic sa mga segundo kung kailan nabawi ng cluster ang functionality nito. Ito ay sinusukat mula sa simula ng script na tumutulad sa isang fault hanggang sa sandaling ibinalik ng cluster ang functionality nito at nakapagpatuloy sa pagbibigay ng mga serbisyo. Kung ang oras ay napakaikli, halimbawa, anim na segundo (nangyayari ito sa mga kumpol na may ilang mga alipin (Tuchanka3 at Tuchanka4)), nangangahulugan ito na ang kasalanan ay nasa asynchronous na alipin at hindi nakakaapekto sa pagganap sa anumang paraan; walang mga switch ng estado ng cluster.
   • paglihis — nagpapakita ng pagkalat (katumpakan) ng halaga reaksyon gamit ang standard deviation method.
   • bilangin — ilang beses isinagawa ang pagsusulit na ito.
2. Ang isang maikling log ay nagbibigay-daan sa iyo upang suriin kung ano ang kasalukuyang ginagawa ng cluster. Ang numero ng pag-ulit (pagsubok), timestamp at pangalan ng operasyon ay ipinapakita. Ang pagtakbo ng masyadong mahaba (> 5 minuto) ay nagpapahiwatig ng problema.
3. puso (puso) - kasalukuyang oras. Para sa visual na pagtatasa ng pagganap masters Ang kasalukuyang oras ay patuloy na isinusulat sa talahanayan nito gamit ang float IP master. Kung matagumpay, ang resulta ay ipinapakita sa panel na ito.
4. matalo (pulso) - "kasalukuyang oras", na dati nang naitala ng script puso sa master, ngayon basahin mula sa alipin sa pamamagitan ng float IP nito. Binibigyang-daan kang biswal na masuri ang pagganap ng alipin at pagtitiklop. Sa Tuchanka1 walang mga alipin na may float IP (walang mga alipin na nagbibigay ng mga serbisyo), ngunit mayroong dalawang mga pagkakataon (DB), kaya hindi ito ipapakita dito mataloAt puso pangalawang pagkakataon.
5. Pagsubaybay sa kalusugan ng cluster gamit ang utility pcs mon. Ipinapakita ang istraktura, pamamahagi ng mga mapagkukunan sa mga node at iba pang kapaki-pakinabang na impormasyon.
6. Ang pagsubaybay sa system mula sa bawat virtual machine sa cluster ay ipinapakita dito. Maaaring mayroong higit pang mga naturang panel depende sa kung gaano karaming mga virtual machine ang mayroon ang cluster. Dalawang graph Pag-load ng CPU (May dalawang processor ang virtual machine), pangalan ng virtual machine, Pag-load ng System (pinangalanang Load Average dahil ito ay na-average sa loob ng 5, 10 at 15 minuto), iproseso ang data at paglalaan ng memorya.
7. Bakas ng script na nagsasagawa ng pagsubok. Sa kaganapan ng isang madepektong paggawa - isang biglaang pagkagambala ng operasyon o isang walang katapusang ikot ng paghihintay - dito mo makikita ang dahilan para sa pag-uugali na ito.

Ang pagsubok ay isinasagawa sa dalawang yugto. Una, dumaan ang script sa lahat ng uri ng pagsubok, random na pumipili ng virtual machine kung saan ilalapat ang pagsubok na ito. Pagkatapos ay isinasagawa ang isang walang katapusang cycle ng pagsubok, ang mga virtual machine at ang kasalanan ay pinipili nang sapalaran sa bawat oras. Ang biglaang pagwawakas ng script ng pagsubok (bottom panel) o isang walang katapusang paghihintay para sa isang bagay (> 5 minutong oras ng pagpapatupad para sa isang operasyon, makikita ito sa bakas) ay nagpapahiwatig na ang ilan sa mga pagsubok sa cluster na ito ay nabigo.

Ang bawat pagsubok ay binubuo ng mga sumusunod na operasyon:

1. Ilunsad ang isang function na emulates isang fault.
2. Handa? — naghihintay na maibalik ang cluster (kapag naibigay na ang lahat ng serbisyo).
3. Ipinapakita ang oras ng pag-recover ng cluster (reaksyon).
4. Ayusin — ang kumpol ay "inaaayos." Pagkatapos nito ay dapat itong bumalik sa isang ganap na pagpapatakbo ng estado at maging handa para sa susunod na malfunction.

Narito ang isang listahan ng mga pagsubok na may paglalarawan ng kanilang ginagawa:

• ForkBomb: Lumilikha ng "Out of memory" gamit ang fork bomb.
• OutOfSpace: Puno na ang hard drive. Ngunit ang pagsubok ay medyo simboliko; na may hindi gaanong pag-load na nilikha sa panahon ng pagsubok, ang PostgreSQL ay karaniwang hindi nabigo kapag puno ang hard drive.
• Postgres-KILL: pinapatay ang PostgreSQL gamit ang utos killall -KILL postgres.
• Postgres-STOP: nag-hang ng utos ng PostgreSQL killall -STOP postgres.
• Patayin: "de-energizes" ang virtual machine gamit ang command VBoxManage controlvm "виртуалка" poweroff.
• I-reset: na-overload ang virtual machine gamit ang command VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: sinuspinde ang demonyo ng SBD sa utos killall -STOP sbd.
• ShutDown: nagpapadala ng command sa virtual machine sa pamamagitan ng SSH systemctl poweroff, maganda ang pag-shut down ng system.
• I-unlink: paghihiwalay ng network, utos VBoxManage controlvm "виртуалка" setlinkstate1 off.

Pagkumpleto ng pagsubok gamit ang karaniwang tmux command na "kill-window" Ctrl-b &, o ang command na "detach-client". Ctrl-b d: sa puntong ito nagtatapos ang pagsubok, nagsasara ang tmux, naka-off ang mga virtual machine.

Natukoy ang mga problema sa panahon ng pagsubok

• Sa sandaling ito bantay na demonyo sbd gumagana sa pagpapahinto sa mga naobserbahang daemon, ngunit hindi pinapalamig ang mga ito. At, bilang resulta, mga pagkakamali na humahantong sa pagyeyelo lamang Corosync и Pacemaker, ngunit hindi nakabitin sbd. Para sa check Corosync mayroon na PR#83 (sa GitHub sa sbd), tinanggap sa thread panginoon. Nangako sila (sa PR#83) na magkakaroon ng katulad para sa Pacemaker, umaasa ako na sa pamamagitan ng Pulang Sombrero 8 gagawin. Ngunit ang mga naturang "malfunctions" ay haka-haka at madaling gayahin sa artipisyal na paggamit, halimbawa, killall -STOP corosync, ngunit hindi nagkikita sa totoong buhay.

• У Pacemaker sa bersyon para sa CentOS 7 maling itinakda sync_timeout у aparato ng korum, ang resulta kung nabigo ang isang node, may posibilidad na mag-reboot din ang pangalawang node, kung saan dapat lumipat ang master. Pinagaling sa pamamagitan ng pagpapalaki sync_timeout у aparato ng korum sa panahon ng pag-deploy (sa script setup/setup1). Ang pagbabagong ito ay hindi tinanggap ng mga developer Pacemaker, sa halip ay nangako silang muling idisenyo ang imprastraktura sa paraang (sa ilang hindi natukoy na hinaharap) na ang timeout na ito ay awtomatikong kalkulahin.

• Kung tinukoy iyon ng pagsasaayos ng database LC_MESSAGES (mga text message) Maaaring gamitin ang Unicode, hal. ru_RU.UTF-8, pagkatapos ay sa startup postgres sa isang kapaligiran kung saan ang lokal ay hindi UTF-8, sabihin sa isang walang laman na kapaligiran (dito peysmeyker+pgsqlms(paf) tumakbo postgres) pagkatapos maglalaman ang log ng mga tandang pananong sa halip na mga letrang UTF-8. Ang mga developer ng PostgreSQL ay hindi sumang-ayon sa kung ano ang gagawin sa kasong ito. Nagkakahalaga ito, kailangan mong i-install LC_MESSAGES=en_US.UTF-8 kapag nag-configure (lumikha) ng isang halimbawa ng database.

• Kung nakatakda ang wal_receiver_timeout (bilang default ito ay 60s), pagkatapos ay sa panahon ng PostgreSQL-STOP na pagsubok sa master sa tuchanka3 at tuchanka4 cluster ang pagtitiklop ay hindi muling kumonekta sa bagong master. Ang pagtitiklop doon ay kasabay, kaya hindi lamang ang alipin ang tumitigil, kundi pati na rin ang bagong panginoon. Gumagana sa pamamagitan ng pagtatakda ng wal_receiver_timeout=0 kapag kino-configure ang PostgreSQL.

• Paminsan-minsan ay naobserbahan ko ang pag-freeze ng replikasyon sa PostgreSQL sa ForkBomb test (memory overflow). Pagkatapos ng ForkBomb, minsan ang mga alipin ay maaaring hindi makakonekta muli sa bagong master. Nakatagpo ko lamang ito sa tuchanka3 at tuchanka4 na mga kumpol, kung saan ang master ay nagyelo dahil sa kasabay na pagtitiklop. Ang problema ay nawala nang kusa pagkatapos ng mahabang panahon (mga dalawang oras). Higit pang pananaliksik ang kailangan para itama ito. Ang mga sintomas ay katulad ng nakaraang bug, na sanhi ng ibang dahilan, ngunit may parehong mga kahihinatnan.

Krogan larawan na kinuha mula sa deviant Art na may pahintulot ng may-akda:

Pinagmulan: www.habr.com