perkenalan

Sababaraha waktu ka tukang kuring dibéré pancén pikeun ngembangkeun hiji klaster failover pikeun PostgreSQL, beroperasi dina sababaraha puseur data disambungkeun ku serat optik dina hiji kota, sarta sanggup nahan hiji kagagalan (contona, blackout) hiji puseur data. Salaku software nu jawab kasabaran sesar, kuring milih pacemakersabab ieu mangrupikeun solusi resmi ti RedHat pikeun nyiptakeun klaster failover. Éta saé sabab RedHat nyayogikeun dukungan pikeun éta, sareng kusabab solusi ieu universal (modular). Kalayan pitulungna, éta bakal tiasa mastikeun kasabaran kasalahan henteu ngan ukur PostgreSQL, tapi ogé jasa anu sanés, boh nganggo modul standar atanapi nyiptakeunana pikeun kabutuhan khusus.

Kaputusan ieu ngajukeun patarosan anu lumayan: kumaha toleran kasalahan bakal kluster failover? Pikeun nalungtik ieu, kuring ngembangkeun hiji bangku test nu simulates rupa gagal dina titik klaster, ngantosan jasa dibalikeun, recovers titik gagal, sarta terus nguji dina loop a. Proyék ieu asalna disebut hapgsql, tapi lila-lila kuring bosen ku nami, anu ngan ukur ngagaduhan hiji vokal. Ku alatan éta, kuring mimiti nelepon database toleran lepat (sareng ngambang IP nunjuk ka aranjeunna) krogan (karakter tina kaulinan komputer dimana sadaya organ penting diduplikasi), sareng titik, klaster sareng proyék éta sorangan. tuchanka (planét dimana Krogans hirup).

Ayeuna manajemen geus diwenangkeun muka proyék ka komunitas open source handapeun lisénsi MIT. README baris geura-giru ditarjamahkeun kana basa Inggris (sabab diperkirakeun yén konsumén utama bakal Pacemaker na PostgreSQL pamekar), sarta kuring mutuskeun nampilkeun versi Rusia heubeul README (sawaréh) dina bentuk artikel ieu.

Kluster disebarkeun dina mesin virtual VirtualBox. Jumlahna aya 12 mesin virtual (total 36GiB) bakal disebarkeun, anu ngabentuk 4 klaster toleran kasalahan (pilihan anu béda). Dua klaster kahiji diwangun ku dua server PostgreSQL, nu lokasina di puseur data béda, sarta server umum. saksi c alat kuorum (hosted dina mesin virtual mirah dina puseur data katilu), nu solves kateupastian 50% / 50%, méré sora anjeun ka salah sahiji pihak. Klaster katilu dina tilu pusat data: hiji master, dua budak, henteu alat kuorum. Kluster kaopat diwangun ku opat server PostgreSQL, dua per pusat data: hiji master, réplika sésana, sareng ogé nganggo. saksi c alat kuorum. Kaopat tiasa tahan gagalna dua server atanapi hiji pusat data. Solusi ieu tiasa diskalakeun kana jumlah réplika anu langkung ageung upami diperyogikeun.

jasa waktos akurat ntpd ogé reconfigured pikeun kasabaran sesar, tapi ngagunakeun métode sorangan ntpd (mode yatim piatu). server dibagikeun saksi tindakan minangka server NTP sentral, ngadistribusikaeun waktu na ka sadaya klaster, kukituna nyingkronkeun sadaya server saling. Lamun saksi gagal atawa jadi terasing, lajeng salah sahiji server klaster (dina klaster) bakal ngawitan ngadistribusikaeun waktu na. Caching bantu proxy HTTP ogé diangkat ka saksi, kalayan bantosanana, mesin virtual anu sanés gaduh aksés kana repositori Yum. Kanyataanana, jasa sapertos waktos akurat sareng proksi bakal paling dipikaresep di-host dina server khusus, tapi dina stan aranjeunna di-host dina. saksi ngan pikeun ngahemat jumlah mesin virtual sareng rohangan.

Ayat

v0. Gawéna sareng CentOS 7 sareng PostgreSQL 11 dina VirtualBox 6.1.

Struktur klaster

Sadaya klaster dirancang pikeun ayana di sababaraha pusat data, digabungkeun kana hiji jaringan datar sareng kedah tahan kagagalan atanapi isolasi jaringan tina pusat data tunggal. Éta alesanana teu mungkin pamakéan pikeun panyalindungan ngalawan pamisah-otak téhnologi Pacemaker baku disebut STONITH (némbak titik séjén dina sirah) atawa Anggar. Intina: upami titik-titik dina kluster mimiti curiga yén aya anu salah dina sababaraha titik, éta henteu ngaréspon atanapi kalakuanana henteu leres, teras aranjeunna maksakeun mareuman alat-alat "éksternal", contona, kartu kontrol IPMI atanapi UPS. . Tapi ieu ngan bakal bisa dipaké dina kasus dimana, dina acara gagal tunggal, IPMI atanapi UPS server terus jalan. Di dieu urang rencanana ngajaga ngalawan kagagalan leuwih catastrophic, nalika sakabéh puseur data gagal (contona, leungit kakuatan). Sareng kalayan panolakan sapertos kitu, sadayana stonith-alat (IPMI, UPS, jeung sajabana) oge moal jalan.

Gantina, sistem dumasar kana gagasan quorum. Sadaya titik gaduh sora, sareng ngan ukur anu tiasa ningali langkung ti satengah sadaya titik tiasa jalan. Jumlah ieu "satengah + 1" disebut kuorum. Lamun kuorum teu ngahontal, lajeng titik mutuskeun yén éta téh dina isolasi jaringan sarta kudu mareuman sumberdaya na, i.e. ieu naon éta panyalindungan otak pamisah. Upami parangkat lunak anu tanggung jawab kana paripolah ieu henteu jalan, maka pangawas, contona, dumasar kana IPMI, kedah dianggo.

Upami jumlah titik genap (hiji klaster dina dua pusat data), maka anu disebut kateupastian tiasa timbul. 50% / 50% (lima puluh lima puluh) nalika isolasi jaringan ngabagi klaster persis dina satengah. Ku alatan éta, pikeun jumlah genap titik, urang tambahkeun alat kuorum mangrupa daemon undemanding nu bisa dibuka dina mesin virtual cheapest di puseur data katilu. Anjeunna masihan sora ka salah sahiji bagéan (anu anjeunna ningali), sareng ku kituna ngabéréskeun kateupastian 50%/50%. Kuring ngaranna server nu alat quorum bakal dibuka saksi (terminologi ti repmgr, kuring resep).

Sumberdaya tiasa dipindahkeun ti hiji tempat ka tempat, contona, tina server anu lepat ka anu séhat, atanapi ku paréntah pangurus sistem. Sangkan klien terang dimana sumber daya anu diperyogikeun ayana (dimana nyambungkeun?), ngambang IP (ngambang IP). Ieu mangrupikeun IP anu Pacemaker tiasa ngalih kana titik (sadayana aya dina jaringan datar). Tiap di antarana melambangkan sumberdaya (jasa) jeung bakal lokasina dimana anjeun kudu nyambungkeun pikeun meunangkeun aksés ka layanan ieu (dina hal urang, database).

Tuchanka1 (circuit kalawan compaction)

struktur

Gagasan éta yén urang gaduh seueur pangkalan data leutik kalayan beban anu rendah, anu henteu nguntungkeun pikeun ngajaga server budak anu dikhususkeun dina modeu sayaga panas pikeun ngan ukur transaksi anu dibaca (teu kedah runtah sumber daya sapertos kitu).

Unggal puseur data boga hiji server. Unggal server boga dua instansi PostgreSQL (dina terminologi PostgreSQL disebut klaster, tapi ulah kabingungan kuring bakal nelepon aranjeunna instansi (ku analogi jeung database séjén), sarta kuring ngan bakal nelepon Pacemaker klaster klaster). Hiji conto ngoperasikeun dina modeu master, sarta ngan nyadiakeun layanan (ngan IP ngambang ngarah ka dinya). Instance kadua dianggo salaku budak pikeun puseur data kadua, sarta baris nyadiakeun layanan ngan lamun master na gagal. Kusabab lolobana waktu ngan hiji conto ti dua (master) bakal nyadiakeun layanan (ngalaksanakeun requests), sadaya sumberdaya server dioptimalkeun pikeun master (memori dialokasikeun pikeun shared_buffers cache, jsb), tapi ku kituna kadua conto. ogé boga sumberdaya cukup (sanajan pikeun operasi suboptimal ngaliwatan cache sistem file) bisi gagalna salah sahiji puseur data. budak teu nyadiakeun layanan (teu nedunan maca wungkul requests) salila operasi normal tina klaster, ku kituna euweuh perang pikeun sumberdaya jeung master dina mesin sarua.

Dina kasus dua titik, kasabaran sesar ngan ukur tiasa dilakukeun ku réplikasi asinkron, sabab kalayan réplikasi sinkron, kagagalan budak bakal ngakibatkeun eureun master.

Gagal nyaksian

Kagagalan saksi (alat kuorum) Kuring bakal mertimbangkeun ngan pikeun klaster Tuchanka1, kalawan sakabeh batur eta bakal carita sarua. Upami saksi gagal, moal aya anu robih dina struktur klaster, sadayana bakal terus jalanna sami-sami. Tapi kuorum bakal jadi 2 kaluar 3, sarta ku kituna sagala kagagalan saterusna bakal fatal pikeun klaster. Eta tetep kudu dibenerkeun urgently.

Tuchanka1 panolakan

Gagalna salah sahiji pusat data pikeun Tuchanka1. Dina hal ieu saksi ngaluarkeun sora na ka titik kadua di puseur data kadua. Di dinya, urut budak janten master, salaku hasilna, duanana master dianggo dina server anu sami sareng duanana IP ngambangna nunjuk ka aranjeunna.

Tuchanka2 (klasik)

struktur

Skéma klasik dua titik. Master dianggo dina hiji, budak dina kadua. Duanana tiasa ngaéksekusi pamundut (budak dibaca wungkul), janten duanana ditunjuk ku float IP: krogan2 nyaéta master, krogan2s1 mangrupikeun budak. Boh tuan jeung budak bakal boga toleransi kasalahan.

Dina kasus dua titik, kasabaran sesar ngan mungkin ku réplikasi asinkron, sabab ku réplikasi sinkron, kagagalan budak bakal ngakibatkeun eureun master.

Tuchanka2 panolakan

Lamun salah sahiji puseur data gagal saksi sora pikeun nu kadua. Dina hiji-hijina pusat data anu tiasa dianggo, master bakal diangkat, sareng duanana ngambang IP bakal nunjuk ka éta: master sareng budak. Tangtosna, conto kedah dikonpigurasikeun ku cara anu gaduh sumber anu cekap (wates sambungan, jsb) pikeun sakaligus nampi sadaya sambungan sareng pamundut ti master sareng budak ngambang IP. Hartina, salila operasi normal kudu boga suplai cukup wates.

Tuchanka4 (seueur budak)

struktur

Geus ekstrim sejen. Aya pangkalan data anu nampi seueur pamundut anu dibaca wungkul (kasus khas situs anu beban tinggi). Tuchanka4 nyaéta kaayaan dimana meureun aya tilu atawa leuwih budak pikeun nanganan requests misalna, tapi tetep teu loba teuing. Kalayan jumlah budak anu ageung pisan, anjeun kedah nyiptakeun sistem réplikasi hirarkis. Dina kasus minimum (dina gambar), unggal dua pusat data gaduh dua server, masing-masing nganggo conto PostgreSQL.

Fitur séjén tina skéma ieu nyaéta yén anjeun tiasa ngatur hiji réplikasi sinkron. Hal ieu dikonpigurasi pikeun ngayakeun réplikasi, upami mungkin, ka pusat data anu sanés, tinimbang kana réplika dina pusat data anu sami sareng master. Master sareng unggal budak ditunjuk ku IP ngambang. Untungna, antara budak bakal perlu saimbang requests kumaha bae sql proxy, contona, dina sisi klien. tipena béda klien bisa merlukeun tipe béda sql proxy, sareng ngan ukur pamekar klien anu terang saha anu peryogi. Fungsionalitas ieu tiasa dilaksanakeun ku daemon éksternal atanapi ku perpustakaan klien (kolam renang sambungan), jsb. Sadaya ieu ngalangkungan topik kluster database failover (failover SQL proxy tiasa dilaksanakeun sacara mandiri, sareng kasabaran kasalahan klien).

Tuchanka4 panolakan

Lamun hiji puseur data (ie, dua server) gagal, saksi sora pikeun kadua. Hasilna, aya dua server ngajalankeun di puseur data kadua: hiji ngajalankeun master a, sarta master float IP nunjuk ka dinya (pikeun narima requests baca-tulis); sarta dina server kadua aya budak ngajalankeun kalawan réplikasi sinkron, sarta salah sahiji budak float IP nunjuk ka dinya (pikeun requests baca-hijina).

Hal kahiji anu kedah diperhatoskeun nyaéta henteu sadayana IP ngambang budak bakal janten pagawé, tapi ngan hiji. Sareng pikeun damel sareng éta leres bakal peryogi éta sql proxy dialihkeun sadaya pamundut ka IP ngambang wungkul sésana; jeung lamun sql proxy henteu, teras anjeun tiasa daptar sadaya budak IP ngambang dipisahkeun ku koma dina URL sambungan. Dina hal ieu, kalawan libpq sambungan bakal ka IP gawé munggaran, ieu dipigawé dina sistem nguji otomatis. Panginten di perpustakaan sanés, contona, JDBC, ieu moal jalan sareng peryogi sql proxy. Hal ieu dilakukeun sabab ngambang IP pikeun budak dilarang diangkat sakaligus dina hiji server, ambéh maranéhanana disebarkeun merata diantara server budak lamun aya sababaraha di antarana ngajalankeun.

Kadua: sanajan dina kasus gagalna puseur data, réplikasi sinkron bakal dijaga. Sareng upami aya kagagalan sekundér, nyaéta, salah sahiji dua server dina sésa-sésa pusat data gagal, klaster, sanaos bakal lirén nyayogikeun jasa, tetep bakal nahan inpormasi ngeunaan sadaya transaksi anu komitmen anu parantos masihan konfirmasi komitmen. (moal aya inpormasi karugian upami gagal sekundér).

Tuchanka3 (3 pusat data)

struktur

Ieu klaster pikeun situasi dimana aya tilu puseur data pinuh fungsi, nu masing-masing boga server database fungsi pinuh. Dina hal ieu alat kuorum teu diperlukeun. Hiji puseur data ieu staffed ku master, dua lianna anu staffed ku budak. Réplikasi sinkron, ngetik ANY (slave1, slave2), nyaéta, klien bakal nampi konfirmasi komitmen nalika salah sahiji budak anu mimiti ngaréspon yén anjeunna nampi komitmen. Sumberdaya dituduhkeun ku hiji IP ngambang pikeun master sareng dua pikeun budak. Beda sareng Tuchanka4, sadaya tilu IP ngambang henteu toleran. Pikeun nyaimbangkeun queries SQL baca-hijina anjeun tiasa nganggo sql proxy (kalawan kasabaran sesar misah), atawa napelkeun hiji budak ngambang IP ka satengah tina klien, sarta satengah séjén pikeun kadua.

Tuchanka3 panolakan

Lamun salah sahiji puseur data gagal, dua tetep. Dina hiji, master sareng float IP tina master diangkat, dina kadua - budak sareng duanana budak float IP (contona kedah gaduh sumber daya ganda pikeun nampi sadaya sambungan ti duanana budak float IP). Réplikasi sinkron antara tuan sareng budak. Ogé, klaster bakal ngahemat inpormasi ngeunaan transaksi anu komitmen sareng dikonfirmasi (moal aya rugi inpormasi) upami aya karusakan dua pusat data (upami aranjeunna henteu ancur sakaligus).

Kuring mutuskeun teu kaasup pedaran lengkep ngeunaan struktur file na deployment. Saha waé anu hoyong maén tiasa maca sadayana dina README. Kuring ukur nyadiakeun pedaran nguji otomatis.

Sistem tés otomatis

Pikeun nguji kasabaran kasalahan klaster ku simulasi rupa-rupa kasalahan, sistem uji otomatis parantos diciptakeun. Dibuka ku naskah test/failure. Skrip tiasa nyandak salaku parameter jumlah klaster anu anjeun hoyong uji. Contona paréntah ieu:

test/failure 2 3

ngan bakal nguji klaster kadua jeung katilu. Upami parameter henteu ditangtukeun, maka sadaya klaster bakal diuji. Sadaya klaster diuji sacara paralel, sareng hasilna dipidangkeun dina panel tmux. Tmux nganggo server tmux khusus, janten naskah tiasa dijalankeun tina tmux standar, hasilna tmux nested. Abdi nyarankeun ngagunakeun terminal dina jandela badag tur kalawan font leutik. Sateuacan tés dimimitian, sadaya mesin virtual digulung deui ka snapshot nalika naskah réngsé setup.

Terminal dibagi kana kolom dumasar kana jumlah klaster anu diuji; sacara standar (dina screenshot) aya opat. Kuring bakal ngajelaskeun eusi kolom ngagunakeun conto Tuchanka2. Panel-panel dina layar dinomerkeun:

1. Statistik tés dipintonkeun di dieu. Kolom:
   • kagagalan - nami test (fungsi dina naskah) nu emulates lepat.
   • réaksi - waktos rata-rata arithmetic dina detik nalika kluster pulih fungsionalitasna. Ieu diukur ti mimiti naskah emulating kasalahan nepi ka momen nalika klaster restores fungsionalitas sarta bisa neruskeun nyadiakeun layanan. Upami waktosna pondok pisan, contona, genep detik (ieu kajantenan dina klaster sareng sababaraha budak (Tuchanka3 sareng Tuchanka4)), ieu hartosna kasalahan éta aya dina budak asinkron sareng henteu mangaruhan kinerja dina cara naon waé; saklar kaayaan klaster.
   • simpangan - nembongkeun sumebarna (akurasi) tina nilai réaksi ngagunakeun métode simpangan baku.
   • ngitung - sabaraha kali tés ieu dipigawé.
2. A log pondok ngidinan Anjeun pikeun evaluate naon kluster ayeuna lakukeun. Nomer iteration (test), timestamp sareng nami operasi ditampilkeun. Ngajalankeun panjang teuing (> 5 menit) nunjukkeun masalah.
3. jajantung (jantung) - waktos ayeuna. Pikeun assessment visual kinerja tuan Waktu ayeuna terus-terusan ditulis kana méja na nganggo master IP ngambang. Lamun sukses, hasilna dipintonkeun dina panel ieu.
4. neunggeul (pulsa) - "waktos ayeuna", nu saméméhna dirékam ku naskah jajantung ngawasaan, ayeuna maca ti budak via float IP na. Ngidinan anjeun sacara visual ngevaluasi kinerja budak sareng réplikasi. Di Tuchanka1 teu aya budak anu ngambang IP (henteu aya budak anu nyayogikeun jasa), tapi aya dua instansi (DB), janten éta moal ditingalikeun di dieu. neunggeuljeung jajantung conto kadua.
5. Ngawas kaséhatan klaster ngagunakeun utiliti pcs mon. Némbongkeun struktur, distribusi sumberdaya sakuliah titik jeung informasi mangpaat séjén.
6. Ngawaskeun sistem tina unggal mesin virtual dina kluster dipintonkeun di dieu. Meureun aya leuwih panels sapertos gumantung kana sabaraha mesin virtual kluster boga. Dua grafik beban CPU (mesin virtual gaduh dua prosesor), nami mesin virtual, Beban Sistem (ngaranna beban Rata-rata sabab rata-rata leuwih 5, 10 jeung 15 menit), ngolah data jeung alokasi memori.
7. Lacak tina tés ngalaksanakeun tés. Upami aya gangguan - gangguan ngadadak operasi atanapi siklus ngantosan anu teu aya tungtungna - di dieu anjeun tiasa ningali alesan pikeun kabiasaan ieu.

Tés dilaksanakeun dina dua tahap. Kahiji, naskah ngaliwat sagala jinis tés, sacara acak milih mesin virtual pikeun nerapkeun tés ieu. Lajeng hiji siklus sajajalan tina nguji dipigawé, mesin virtual jeung sesar dipilih acak unggal waktu. Terminasi dadakan tina naskah nguji (panel handap) atawa hiji loop sajajalan ngantosan hal (> 5 menit waktu palaksanaan pikeun hiji operasi, ieu bisa ditempo dina renik) nunjukkeun yén sababaraha tés dina klaster ieu geus gagal.

Unggal tés diwangun ku operasi di handap ieu:

1. Ngajalankeun fungsi nu emulates kasalahan.
2. Siap? - ngantosan klaster dibalikeun (nalika sadaya jasa disayogikeun).
3. Nunjukkeun waktos waktos pamulihan klaster (réaksi).
4. ngalereskeun - klaster nuju "diperbaikan." Saatos éta kedah uih deui ka kaayaan operasional pinuh sareng siap pikeun gangguan salajengna.

Ieu daptar tés sareng pedaran ngeunaan naon anu aranjeunna laksanakeun:

• ForkBomb: Nyiptakeun "Out of memory" ngagunakeun bom garpu.
• OutOfSpace: Hard drive pinuh. Tapi tésna rada simbolis; kalayan beban anu teu penting anu diciptakeun nalika tés, PostgreSQL biasana henteu gagal nalika hard drive pinuh.
• Postgres-maéhan: maéhan PostgreSQL kalayan paréntah killall -KILL postgres.
• Postgres-STOP: hangs paréntah PostgreSQL killall -STOP postgres.
• Pareum: "de-energizes" mesin virtual kalawan paréntah VBoxManage controlvm "виртуалка" poweroff.
• Reset: overloads mesin virtual kalawan paréntah VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: ngagantungkeun sétan SBD kalayan paréntah killall -STOP sbd.
• Pareuman: ngirimkeun paréntah ka mesin virtual via SSH systemctl poweroff, Sistim nu shuts turun gracefully.
• Unlink: isolasi jaringan, paréntah VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ngabéréskeun tés boh nganggo paréntah tmux standar "kill-window" Ctrl-b &, atawa paréntah "detach-client". Ctrl-b d: dina titik ieu nguji ends, tmux nutup, mesin virtual dipareuman.

Masalah anu diidentifikasi nalika tés

• Dina momen ieu pangawas sétan sbd jalan dina stopping daemons observasi, tapi teu katirisan aranjeunna. Jeung, salaku hasilna, faults nu ngakibatkeun katirisan wungkul Corosync и pacemaker, tapi teu gantung sbd... Pikeun dipariksa Corosync geus PR # 83 (dina GitHub di sbd), ditarima kana thread ngawasaan. Aranjeunna jangji (dina PR # 83) nu bakal aya hal sarupa Pacemaker, Kuring miharep éta ku Topi Beureum 8 bakal dilaksanakan. Tapi "malfunctions" sapertos spekulatif sareng tiasa gampang disimulasi sacara artifisial nganggo, contona, killall -STOP corosync, Tapi pernah papanggih dina kahirupan nyata.

• У pacemaker dina versi pikeun CentOS 7 salah diatur sync_timeout у alat kuorum, salaku hasilna lamun hiji titik gagal, kalawan sababaraha kamungkinan titik kadua ogé rebooted, ka nu master sakuduna dituju pindah. Diubaran ku ngagedéan sync_timeout у alat kuorum salila deployment (dina script setup/setup1). Amandemen ieu henteu ditarima ku pamekar pacemaker, Gantina aranjeunna jangji baris ngadesain ulang infrastruktur ku cara kitu (dina sababaraha mangsa nu bakal datang unspecified) nu timeout ieu bakal diitung otomatis.

• Lamun konfigurasi database nangtukeun éta LC_MESSAGES (pesen téks) Unicode bisa dipaké, misalna. ru_RU.UTF-8, teras dina ngamimitian postgres dina lingkungan dimana lokal henteu UTF-8, sebutkeun dina lingkungan kosong (di dieu pacilingan+pgsqlms(paf) lumpat postgres), saterusna log bakal ngandung tanda tanya tinimbang UTF-8 hurup. Pamekar PostgreSQL teu sapuk kana naon anu kudu dilakukeun dina hal ieu. Éta waragad, Anjeun kudu masang LC_MESSAGES=en_US.UTF-8 nalika ngonpigurasikeun (nyieun) conto database.

• Upami wal_receiver_timeout disetel (sacara standar nyaéta 60s), teras nalika tés PostgreSQL-STOP dina master dina klaster tuchanka3 sareng tuchanka4 réplikasi teu nyambung deui ka master anyar. Réplikasi aya sinkron, jadi teu ngan budak eureun, tapi ogé master anyar. Gawéna ku netepkeun wal_receiver_timeout = 0 nalika ngonpigurasikeun PostgreSQL.

• Aya kalana kuring niténan réplikasi freezes di PostgreSQL dina test ForkBomb (memori mudal). Saatos ForkBomb, kadang budak tiasa henteu nyambung deui ka master énggal. Kuring geus ngan encountered ieu dina tuchanka3 na tuchanka4 klaster, dimana master froze alatan réplikasi sinkron. Masalahna ngaleungit sorangan saatos lami (kira-kira dua jam). Panaliti langkung seueur diperyogikeun pikeun ngabenerkeun ieu. Gejala nu sarupa jeung bug saméméhna, nu disababkeun ku alesan béda, tapi kalawan konsekuensi sarua.

Krogan gambar dicokot tina Deviant Art kalawan idin ti pangarang:

sumber: www.habr.com