Sarrera

Duela denbora pixka bat, hutsegite-kluster bat garatzeko zeregina eman zidaten PostgreSQL, hiri berean zuntz bidez konektatutako hainbat datu-zentrotan funtzionatzen duena, eta datu-zentro baten hutsegiteei (adibidez, itzaltzeari) aurre egiteko gai dena. Akatsen tolerantziaz arduratzen den software gisa, aukeratu nuen taupada-, hau delako RedHat-en irtenbide ofiziala hutsegite-klusterrak sortzeko. Ona da RedHat-ek laguntza ematen diolako eta irtenbide hau unibertsala (modularra) delako. Bere laguntzarekin, akatsen tolerantzia eskaintzea posible izango da PostgreSQLrentzat ez ezik, beste zerbitzu batzuetarako ere, modulu estandarrak erabiliz edo behar zehatzetarako sortuz.

Erabaki honen aurrean, arrazoizko galdera bat sortu zen: nola izango da hutsegiteen kluster bat akatsekiko tolerantzia? Hori ikertzeko, proba-banku bat garatu dut, klusterreko nodoetan hainbat hutsegite simulatzen dituena, berreskuratzeko itxaron, huts egindako nodoa leheneratzen duena eta probak egiten jarraitzen duen begizta batean. Hasieran, proiektu honi hapgsql deitzen zitzaion, baina denborarekin aspertu egin nintzen izenaz, bokal bakarra duena. Hori dela eta, akats-toleranteen datu-baseak izendatzen hasi nintzen (eta horietara zuzendutako IP flotatzaileak) krogan (ordenagailu-joko bateko pertsonaia, zeinetan organo garrantzitsu guztiak bikoizten diren), eta nodoak, klusterrak eta proiektua bera dira tuchanka (kroganak bizi diren planeta).

Zuzendaritzak orain onartu du ireki kode irekiko komunitaterako proiektu bat MIT lizentziapean. README laster ingelesera itzuliko da (Pacemaker eta PostgreSQL garatzaileak kontsumitzaile nagusiak izango direla espero baita), eta READMEren errusiar bertsio zaharra (partzialki) argitaratzea erabaki nuen artikulu honen moduan.

Klusterrak makina birtualetan zabaltzen dira VirtualBox. Guztira, 12 makina birtual zabalduko dira (36GiB guztira), 4 failover cluster osatzen dituztenak (aukera desberdinak). Lehenengo bi klusterrak datu-zentro desberdinetan kokatutako bi PostgreSQL zerbitzariz eta zerbitzari komun batez osatuta daude lekuko c quorum gailua (hirugarren datu-zentro batean makina birtual merke batean ostatatua) ziurgabetasuna konpontzen duena 50% /% 50norberaren botoa emanez. Hirugarren multzoa hiru datu-zentrotan: maisu bat, bi esklabo, ez quorum gailua. Laugarren klusterrak PostgreSQL lau zerbitzariz osatuta dago, bi datu-zentro bakoitzeko: bat maisu, gainerakoak erreplikak dira eta, gainera, erabiltzen ditu. lekuko c quorum gailua. Laugarrenak bi zerbitzariren edo datu-zentro baten hutsegitetik irauten du. Irtenbide hau erreplika gehiagotara eskalatu daiteke beharrezkoa bada.

Denbora zerbitzua ntpd akatsen tolerantziarako ere birkonfiguratu da, baina metodoa erabiltzen du ntpd (umezurtz modua). Zerbitzari partekatua lekuko NTP zerbitzari zentral gisa jarduten du, bere denbora kluster guztietan banatuz, eta, horrela, zerbitzari guztiak elkarren artean sinkronizatzen ditu. Bada lekuko huts egiten du edo isolatuta geratzen da, orduan kluster zerbitzarietako bat (kluster barruan) bere denbora banatzen hasiko da. Cache osagarria HTTP proxy gainera igota lekuko, bere laguntzarekin, beste makina birtualek Yum biltegietarako sarbidea dute. Egia esan, denbora zehatza eta proxy bezalako zerbitzuak ziurrenik zerbitzari dedikatuetan ostatatuko dira, eta kabinan ostatatuta daude. lekuko makina birtualen kopurua eta espazioa gordetzeko soilik.

bertsio

v0. CentOS 7 eta PostgreSQL 11-ekin funtzionatzen du VirtualBox 6.1-en.

Kluster egitura

Kluster guztiak hainbat datu-zentrotan kokatzeko diseinatuta daude, sare lau batean elkartuta eta datu-zentro baten hutsegite edo sarearen isolamendua jasan behar dute. Horregatik ezinezkoa da babesteko erabili zatitu-garuna Taupada-markagailuen teknologia estandarra izenekoa STONITH (Beste nodoari tiro buruan) edo hesiak. Bere funtsa: klusterreko nodoak nodoren batean zerbait gaizki dagoela susmatzen hasten badira, ez du erantzuten edo gaizki jokatzen du, orduan "kanpoko" gailuen bidez indarrez itzaltzen dute, adibidez, IPMI edo UPS kontrol-txartel baten bidez. Baina honek IPMI zerbitzariaren edo UPSaren hutsegite bakarrarekin lanean jarraitzen duten kasuetan bakarrik funtzionatuko du. Era berean, datu-zentro osoa huts egiten duenean (adibidez, energiarik gabe geratzen denean) akats hondamendiago baten aurka babesteko asmoa du. Eta halako ukoarekin, dena harria-gailuek (IPMI, UPS, etab.) ere ez dute funtzionatuko.

Horren ordez, sistema quorum baten ideian oinarritzen da. Nodo guztiek dute ahotsa, eta nodo guztien erdia baino gehiago ikusten dutenek bakarrik funtziona dezakete. Zenbaki horri "erdia + 1" deitzen zaio quoruma. Quoruma lortzen ez bada, orduan nodoak sarearen isolamenduan dagoela erabakitzen du eta bere baliabideak itzali behar ditu, hau da. horrela da zatitutako garunaren babesa. Jokabide honen arduraduna den softwareak ez badu funtzionatzen, orduan, adibidez, IPMIn oinarritutako watchdog batek funtzionatu beharko luke.

Nodo kopurua bikoitia bada (kluster bat bi datu-zentrotan), orduan ziurgabetasuna deitutakoa sor daiteke. 50% /% 50 (berrogeita hamaika) sarearen isolamenduak klusterra zehazki erditik banatzen duenean. Beraz, nodo kopuru bikoiti baterako, gehitzen da quorum gailua - Hirugarren datu-zentroko makina birtual merkeenean exekutatu daitekeen deabru zorrotza. Segmentuetako bati ematen dio botoa (ikusten duena), eta, horrela, %50/%50 ziurgabetasuna konpontzen du. Quorum gailua exekutatuko den zerbitzariari deitu nion lekuko (repmgr-eko terminologia, gustatu zait).

Baliabideak leku batetik bestera mugi daitezke, adibidez, zerbitzari akastunetatik erabilgarri daudenetara edo sistema-administratzaileen aginduz. Bezeroek behar dituzten baliabideak non dauden jakin dezaten (non konektatu?), IP flotagarria (float IP). Hauek dira Pacemaker-ek nodoetan zehar mugi ditzakeen IPak (dena sare lau batean dago). Horietako bakoitzak baliabide bat (zerbitzua) sinbolizatzen du eta zerbitzu honetara (gure kasuan, datu-basea) sartzeko konektatu behar duzun tokian kokatuko da.

Tuchanka1 (eskema konprimitua)

Egitura

Ideia zen karga baxuko datu-base txiki asko ditugula, eta, horretarako, ez da errentagarria esklabo zerbitzari dedikatu bat egonean modu beroan mantentzea irakurtzeko soilik den transakzioetarako (ez dago halako baliabide xahutzerik behar).

Datu zentro bakoitzak zerbitzari bat du. Zerbitzari bakoitzak bi PostgreSQL instantzia ditu (PostgreSQL terminologian cluster deitzen zaie, baina nahasketa saihesteko, instantzia deituko diet (beste datu-base batzuekin analogia eginez), eta Pacemaker clusters clusterrak bakarrik deituko ditut). Instantzia batek modu maisuan funtzionatzen du, eta zerbitzuak soilik eskaintzen ditu (float IP soilik eramaten du bertara). Bigarren instantzia bigarren datu-zentrorako esklabo gisa funtzionatzen du, eta bere maisuak huts egiten badu soilik emango ditu zerbitzuak. Gehienetan bi instantzietako bakar batek (maisua) zerbitzuak emango dituenez (eskaerak egin), zerbitzariaren baliabide guztiak maisurako optimizatuta daude (memoria shared_buffers cacherako esleitzen da, etab.), baina bigarren instantzia izan dadin. baliabide nahikoak ere baditu (fitxategi-sistemaren cachearen bidez lan ez-optimoa bada ere) datu-zentroren batek huts egiten badu. Esklaboak ez du zerbitzurik ematen (ez ditu irakurtzeko soilik eskaerak exekutatzen) kluster funtzionamendu arruntean, beraz, makina berean maisuarekin baliabideen gerra ez da egon.

Bi nodoen kasuan, hutsegite-tolerantzia erreplikazio asinkronoarekin bakarrik da posible, izan ere, erreplikazio sinkronoarekin, esklabuaren hutsegiteek maisua geldiaraztea ekarriko du.

lekukoa ez ematea

lekukorik ez ematea (quorum gailua) Tuchanka1 klustererako bakarrik hartuko dut kontuan, istorio bera izango da beste guztiekin. Lekukoak huts egiten badu, ez da ezer aldatuko kluster-egituran, denak funtzionatu zuen moduan jarraituko du. Baina quoruma 2tik 3 bihurtuko da, eta, beraz, hurrengo edozein hutsegite hilgarria izango da klusterrentzat. Oraindik premiaz egin behar da.

Errefusa Tuchanka1

Tuchanka1-ren datu-zentroetako baten porrota. Kasu honetan lekuko bere botoa bigarren datu-zentroko bigarren nodoari ematen dio. Bertan, esklabo ohia maisu bihurtzen da, ondorioz, bi maisuek zerbitzari berean lan egiten dute eta euren IP flotatzaile biek haiei seinalatzen diete.

Tuchanka2 (klasikoa)

Egitura

Bi nodoen eskema klasikoa. Nagusiak batean lan egiten du, esklaboak bigarrenean. Biek eskaerak exekutatu ditzakete (esklaboa irakurtzeko soilik da), beraz, biak float IP bidez seinalatzen dira: krogan2 maisua da, krogan2s1 esklaboa. Bai maisuak bai esklaboak akatsen tolerantzia izango dute.

Bi nodoen kasuan, hutsegite-tolerantzia erreplikazio asinkronoarekin bakarrik posible da, izan ere, erreplikazio sinkronoarekin, esklabuaren hutsegiteak maisua geldiaraztea ekarriko du.

Errefusa Tuchanka2

Datu-zentroren batek huts egiten badu lekuko bigarrenari botoa eman. Lan egiten duen datu-zentro bakarrean, maisua igoko da, eta flotatzaile IP biek seinalatu egingo dute: maisua eta esklaboa. Jakina, instantzia konfiguratu behar da nahikoa baliabide (konexio-mugak, etab.) aldi berean onartzeko, maisu eta esklabo float IP-aren konexio eta eskaera guztiak. Hau da, funtzionamendu arruntean, mugetarako nahikoa marjina izan behar du.

Tuchanka4 (esklabo asko)

Egitura

Dagoeneko beste muturreko bat. Badira irakurtzeko soilik eskaera asko dituzten datu-baseak (oso kargatutako gune baten kasu tipikoa). Tuchanka4 horrelako eskaerak kudeatzeko hiru esklabo edo gehiago egon daitezkeen egoera da, baina oraindik ez dira gehiegi. Esklabo kopuru oso handiarekin, beharrezkoa izango da erreplikazio sistema hierarkiko bat asmatu. Gutxieneko kasuan (irudian), bi datu-zentro bakoitzak bi zerbitzari ditu, eta horietako bakoitzak PostgreSQL instantzia bat du.

Eskema honen beste ezaugarri bat da dagoeneko posible dela hemen erreplikazio sinkroniko bat antolatzea. Ahal bada, beste datu-zentro batean errepikatzeko konfiguratuta dago, eta ez maisuaren datu-zentro berean dagoen erreplika batean. Maisua eta esklabo bakoitza float IP baten bidez adierazten dira. Onerako, esklaboen artean beharrezkoa izango da eskaeren nolabaiteko oreka egitea sql proxy, adibidez, bezeroaren aldetik. Bezero mota ezberdinek mota desberdinak eska ditzakete sql proxy, eta bezeroen garatzaileek bakarrik dakite nork behar duen. Funtzionalitate hau kanpoko deabru batek edo bezero liburutegi batek (konexio-pool) inplementa daiteke. Hori guztia datu-basearen hutsegite-klusterren esparrutik kanpo dago (failover SQL proxy modu independentean inplementa daiteke, bezeroaren hutsegitearekin batera).

Errefusa Tuchanka4

Datu-zentro batek (hau da, bi zerbitzariak) huts egiten badu, lekukoek bigarrenaren aldeko botoa emango dute. Ondorioz, bi zerbitzariek funtzionatzen dute bigarren datu-zentroan: maisuak batean lan egiten du eta float IP maisuak hara seinalatzen du (irakurketa-idazketa eskaerak jasotzeko); eta erreplikazio sinkronikoa duen esklabo bat exekutatzen ari da bigarren zerbitzarian, eta esklabo flotatzaile IPetako batek hara seinalatzen du (irakurtzeko soilik eskaerak egiteko).

Kontuan izan behar den lehenengo gauza: esklabo float IP guztiek ez dute funtzionatuko, bakarra baizik. Eta behar bezala lan egiteko, beharrezkoa izango da sql proxy eskaera guztiak birbideratu ditu geratzen den IP flotatzaile bakarrera; eta bada sql proxy ez, float IP esklabo guztiak komaz bereizita zerrenda ditzakezu konexioaren URLan. Kasu horretan, rekin libpq konexioa lehen laneko IParekin izango da, proba automatikoko sisteman egiten den moduan. Agian beste liburutegietan, adibidez, JDBC, honek ez du funtzionatuko eta beharrezkoa da sql proxy. Esklaboentzako float IP zerbitzari batean aldi berean igotzea debekatuta dagoelako egiten da, zerbitzari esklaboen artean berdin banatuko direlako hainbat baldin badira.

Bigarrena: datu-zentroaren hutsegiterik gertatuz gero ere, erreplikazio sinkronikoa mantenduko da. Eta bigarren mailako hutsegite bat gertatzen bada ere, hau da, bi zerbitzarietako batek gainerako datu-zentroan huts egiten badu, klusterrak, zerbitzuak emateari uzten dion arren, oraindik gordeko du konprometitutako transakzio guztiei buruzko informazioa (konpromisoa berretsi duen). bigarren mailako hutsegiteari buruzko informazio galerarik ez izatea).

Tuchanka3 (3 datu-zentro)

Egitura

Hau guztiz funtzionatzen duten hiru datu-zentro dauden egoera baterako cluster bat da, eta horietako bakoitzak guztiz funtzionatzen duen datu-base zerbitzari bat dauka. Kasu honetan quorum gailua ez da beharrezkoa. Maisu batek datu-zentro batean lan egiten du, eta esklaboek beste bietan. Erreplikazioa sinkronoa da, ANY idatzi (slave1, slave2), hau da, bezeroak konpromisoaren baieztapena jasoko du esklaboren bat konprometitua onartu duela erantzuten lehena denean. Baliabideak IP flotatzaile batek seinalatzen ditu maisuarentzat eta bi esklaboentzat. Tuchanka4 ez bezala, hiru float IPak akatsak toleranteak dira. Irakurtzeko soilik SQL kontsultak orekatzeko, erabil dezakezu sql proxy (akatsen tolerantzia bereiziarekin), edo esklabo IP float bat esleitu bezeroen erdiari, eta bigarrena beste erdiari.

Errefusa Tuchanka3

Datu-zentroetako batek huts egiten badu, bi geratzen dira. Batean, maisuaren IP flotatzailea eta maisuaren IPa planteatzen dira, bigarrenean, esklaboa eta bi esklabo float IPak (instantziak baliabide marjina bikoitza izan behar du esklabu float IP bietako konexio guztiak onartzeko). Maisu eta esklaboen arteko erreplikazio sinkronikoa. Era berean, klusterrak konprometitutako eta baieztatutako transakzioei buruzko informazioa gordeko du (ez da informaziorik galduko) bi datu-zentro suntsitzen badira (aldi berean suntsitzen ez badira).

Fitxategien egituraren eta hedapenaren deskribapen zehatzik ez sartzea erabaki nuen. Jolastu nahi baduzu, hau guztia irakur dezakezu IRAKURRI-n. Proba automatikoaren deskribapena baino ez dut ematen.

Proba sistema automatikoa

Hainbat akats imitatuz klusterren akatsen tolerantzia egiaztatzeko, proba automatikoko sistema bat egin zen. Gidoi batek abian jarria test/failure. Scriptak parametro gisa har ditzake probatu nahi dituzun kluster kopurua. Adibidez, komando hau:

test/failure 2 3

bigarren eta hirugarren klusterrak bakarrik probatuko ditu. Parametroak zehazten ez badira, kluster guztiak probatuko dira. Kluster guztiak paraleloan probatzen dira eta emaitza tmux panelean bistaratzen da. Tmux-ek tmux zerbitzari dedikatu bat erabiltzen du, beraz, script-a tmux lehenetsiaren azpitik exekutatu daiteke, habiaratuta dagoen tmux bat sortuz. Terminala leiho handi batean eta letra-tipo txiki batekin erabiltzea gomendatzen dut. Probak hasi aurretik, makina birtual guztiak argazki batera itzultzen dira scripta amaitzen den unean. setup.

Terminala zutabetan banatzen da probatutako kluster kopuruaren arabera, lehenespenez (pantaila-argazkian) lau daude. Zutabeen edukia deskribatuko dut Tuchanka2 adibide gisa erabiliz. Pantaila-argazkiko panelak zenbakituta daude:

1. Bertan bistaratzen dira probaren estatistikak. Hizlariak:
   • porrota — hutsegitea emulatzen duen probaren izena (gidoiaren funtzioa).
   • erreakzioa — Klusterrak bere errendimendua berreskuratu duen segundotan dagoen batez besteko denbora aritmetikoa. Hutsegitea emulatzen duen script-aren hasieratik neurtzen da, eta klusterrak bere osasuna berreskuratzen duen eta zerbitzuak ematen jarraitzeko gai den arte. Denbora oso laburra bada, adibidez, sei segundo (hau esklabo ugari dituzten multzoetan gertatzen da (Tuchanka3 eta Tuchanka4)), horrek esan nahi du matxura esklabo asinkrono batean amaitu zela eta ez zuen errendimenduan inola ere eragin, ez zegoen kluster-egoeraren etengailuak.
   • desbideraketa - balioaren hedapena (zehaztasuna) erakusten du erreakzioa desbideratze estandarraren metodoaren bidez.
   • zenbatu Zenbat aldiz egin den proba hau.
2. Erregistro labur batek klusterrak une honetan egiten ari dena ebaluatzeko aukera ematen du. Iterazio (proba) zenbakia, denbora-zigilua eta eragiketaren izena bistaratzen dira. Exekuzio luzeegiak (> 5 minutu) nolabaiteko arazoa adierazten du.
3. bihotza (bihotza) uneko ordua da. Errendimendu bisuala ebaluatzeko maisu uneko ordua etengabe idazten da bere taulan maisuaren float IP erabiliz. Arrakasta bada, emaitza panel honetan bistaratuko da.
4. irabiatu (pultsua) - "uneko ordua", aurretik gidoiak grabatu zuena bihotza menperatu, orain irakurri esklabo bere float IP bidez. Esklabo baten errendimendua eta erreplikazioa bisualki ebaluatzeko aukera ematen du. Ez dago float IP duen esklaborik Tuchanka1-en (ez dago zerbitzurik eskaintzen duten esklaborik), baina bi instantzia daude (DB), beraz, ez da hemen erakutsiko irabiatuEta bihotza bigarren instantzia.
5. Klusterren egoera kontrolatzea utilitatea erabiliz pcs mon. Egitura, baliabideen banaketa nodoen arabera eta bestelako informazio erabilgarria erakusten du.
6. Kluster makina birtual bakoitzeko sistemaren jarraipena erakusten du. Horrelako panel gehiago egon daitezke, klusterrak zenbat makina birtual dituen. Bi grafiko CPU karga (bi prozesadore makina birtualetan), makina birtualaren izena, Sistemaren karga (Load Average izenekoa, batez beste 5, 10 eta 15 minutu baino gehiagokoa izan zelako), prozesuko datuak eta memoria-esleipena.
7. Probak egiten dituen gidoia trazatzea. Matxura gertatuz gero -bat-bateko lana etetea edo amaigabeko itxaronaldi-zikloa-, hemen ikus dezakezu portaera horren arrazoia.

Probak bi fasetan egiten dira. Lehenik eta behin, script-ak proba mota guztiak igarotzen ditu, proba hori aplikatu behar zaion makina birtual bat ausaz aukeratuz. Ondoren, proba-ziklo amaigabea egiten da, makina birtualak eta matxura bat aukeratzen dira aldi bakoitzean ausaz. Test script-a (beheko panela) bat-batean amaitzeak edo zerbaiten itxaron-begizta amaigabeak (> 5 minutuko denbora eragiketa bat burutzeko, hau arrastoan ikus daiteke) kluster honetako proba batzuek huts egin dutela adierazten dute.

Proba bakoitzak eragiketa hauek ditu:

1. Matxura bat emulatzen duen funtzio bat abiaraztea.
2. Prest? - Klusterren osasuna berreskuratzeko zain (zerbitzu guztiak ematen direnean).
3. Klusterrak berreskuratzeko denbora-muga erakusten da (erreakzioa).
4. Konpondu - kluster "konponduta" dago. Horren ondoren, guztiz funtzionatzen duen egoerara itzuli beharko litzateke eta hurrengo matxurarako prest.

Hona hemen proben zerrenda bat egiten dutenaren deskribapenarekin:

• Forkbomb: "Out of memory" sortzen du sardexka-bonba batekin.
• EspaziozKanpo: disko gogorra beteta dago. Baina proba nahiko sinbolikoa da, probak zehar sortzen den karga hutsalarekin, disko gogorra gainezka egiten denean, PostgreSQL-k normalean ez du huts egiten.
• Postgres-HILDU: komandoarekin PostgreSQL hiltzen du killall -KILL postgres.
• postgres-STOP: PostgreSQL zintzilikatzen du komandoarekin killall -STOP postgres.
• Itzali: makina birtuala "desenergizatzen" du komandoarekin VBoxManage controlvm "виртуалка" poweroff.
• Berrezarri: makina birtuala berriro kargatzen du komandoarekin VBoxManage controlvm "виртуалка" reset.
• SBD STOP: SBD deabrua eteten du komandoarekin killall -STOP sbd.
• Itzali: SSH bidez komando bat bidaltzen du makina birtualera systemctl poweroff, sistema ederki itzaltzen da.
• deskonektatu: sarearen isolamendua, komandoa VBoxManage controlvm "виртуалка" setlinkstate1 off.

Amaitu probak tmux komando estandarrarekin "kill-window" ctrl-b&, edo "detach-client" komandoaren bidez ctrl-bd: aldi berean, probak amaitu dira, tmux itxi egiten da, makina birtualak itzaltzen dira.

Probak zehar identifikatutako arazoak

• Une honetan watchdog daemon sbd behatutako deabruak geldiaraztea kudeatzen du, baina ez izoztea. Eta, ondorioz, matxurak gaizki konpontzen dira, eta izozte bat besterik ez da eragiten Korosync и taupada-, baina ez zintzilik sbd... Egiaztatzeko Korosync jada PR#83 (GitHub-en helbidean sbd), adarrean onartua master. Promestu zuten (PR#83-n) Pacemakerrentzat antzeko zerbait egongo zela, espero dut Red Hat 8 egingo du. Baina horrelako "funtzionamendu akatsak" espekulatiboak dira, erraz imitatzen dira artifizialki erabiliz, adibidez, killall -STOP corosyncbaina inoiz ez ezagutu bizitza errealean.

• У taupada- for bertsioan CentOS 7 gaizki ezarrita sync_timeout у quorum gailua, hori dela eta nodo batek huts egiten badu, bigarren nodoa berrabiaraziko da probabilitate batekin, hara joan behar zuen maisua. Handipenarekin sendatua sync_timeout у quorum gailua hedapenean (gidoian setup/setup1). Zuzenketa hau ez zuten garatzaileek onartu taupada-, horren ordez, azpiegiturak berriro landuko dituztela agindu zuten (etorkizun mugagabe batean) denbora-muga hori automatikoki kalkulatzeko.

• Datu-basearen konfigurazioan zehaztu baduzu hori LC_MESSAGES (testu mezuak) Unicode erabil daiteke, adibidez, ru_RU.UTF-8, gero abiaraztean postgres lokalizazioa UTF-8 ez den ingurune batean, esate baterako, ingurune huts batean (hemen taupada-markagailua+pgsqlms(paf) hasten da postgres) orduan erregistroan UTF-8 letren ordez galdera ikurrak egongo dira. PostgreSQL garatzaileek ez zuten inoiz adostu zer egin kasu honetan. Kostatzen da, jarri behar duzu LC_MESSAGES=en_US.UTF-8 DB instantzia bat konfiguratzean (sortzean).

• wal_receiver_timeout ezartzen bada (lehenespenez 60 segundokoa da), orduan PostgreSQL-STOP maisuan probatzen duzunean tuchanka3 eta tuchanka4 klusterretan Erreplikatzea ez da berriro konektatzen maisu berri batera. Erreplikazioa sinkronikoa da, beraz, esklaboa ez ezik, maisu berria ere gelditzen da. PostgreSQL konfiguratzean wal_receiver_timeout=0 ezarriz lortzen da.

• Tarteka PostgreSQL erreplikazioa ForkBomb proban zintzilik ikusi nuen (memoria gainezka). ForkBomb-en ondoren, batzuetan, baliteke esklaboak ez konektatzea maisu berrira. Hau tuchanka3 eta tuchanka4 multzoetan bakarrik ikusi dut, non erreplikazioa sinkronoa denez, maisua zintzilikatu zen. Arazoa berez joan zen, denbora luze baten ondoren (bi ordu inguru). Ikerketa gehiago behar da hori konpontzeko. Sintomak aurreko akatsaren antzekoak dira, kausa ezberdin batek eragindakoa, baina ondorio berberekin.

Kroganetik ateratako argazkia Deviant Art egilearen baimenarekin:

Iturria: www.habr.com