Tolerancija na pogreške i visoka dostupnost velike su teme, stoga ćemo RabbitMQ-u i Kafki posvetiti zasebne članke. Ovaj članak je o RabbitMQ, a sljedeći je o Kafki, u usporedbi s RabbitMQ. Ovo je dugačak članak, stoga se udobno smjestite.

Pogledajmo strategije tolerancije grešaka, dosljednosti i visoke dostupnosti (HA) i kompromise koje svaka strategija čini. RabbitMQ može raditi na klasteru čvorova - i tada se klasificira kao distribuirani sustav. Kada je riječ o distribuiranim sustavima, često govorimo o dosljednosti i dostupnosti.

Ovi koncepti opisuju kako se sustav ponaša kada zakaže. Kvar mrežne veze, kvar poslužitelja, kvar tvrdog diska, privremena nedostupnost poslužitelja zbog sakupljanja smeća, gubitka paketa ili usporavanja mrežne veze. Sve to može dovesti do gubitka podataka ili sukoba. Ispostavilo se da je praktički nemoguće postaviti sustav koji je i potpuno konzistentan (bez gubitka podataka, bez odstupanja podataka) i dostupan (prihvaća čitanje i pisanje) za sve scenarije kvara.

Vidjet ćemo da su dosljednost i dostupnost na suprotnim krajevima spektra i morate odabrati koji ćete način optimizirati. Dobra vijest je da je uz RabbitMQ ovaj izbor moguć. Imate ove vrste "štreberskih" poluga za pomicanje ravnoteže prema većoj dosljednosti ili većoj pristupačnosti.

Posebnu pozornost obratit ćemo na to koje konfiguracije dovode do gubitka podataka zbog potvrđenih zapisa. Postoji lanac odgovornosti između izdavača, posrednika i potrošača. Nakon što se poruka prenese brokeru, njegov je posao ne izgubiti poruku. Kada broker potvrdi da je izdavač primio poruku, ne očekujemo da će biti izgubljena. No vidjet ćemo da se to zapravo može dogoditi ovisno o konfiguraciji vašeg posrednika i izdavača.

Primitive otpornosti jednog čvora

Otporno čekanje/usmjeravanje

U RabbitMQ postoje dvije vrste redova: trajni i netrajni. Svi redovi čekanja spremaju se u bazu podataka Mnesia. Durable queues se ponovno oglašavaju pri pokretanju čvora i tako preživljavaju ponovna pokretanja, padove sustava ili padove poslužitelja (sve dok podaci traju). To znači da sve dok deklarirate usmjeravanje (razmjenu) i red čekanja kao otporne, infrastruktura čekanja/usmjeravanja će se vratiti na mrežu.

Nestalni redovi čekanja i usmjeravanje uklanjaju se kada se čvor ponovno pokrene.

Stalne poruke

Samo zato što je red trajan ne znači da će sve njegove poruke preživjeti ponovno pokretanje čvora. Samo poruke koje je izdavač postavio kao neprekidan (uporan). Stalne poruke stvaraju dodatno opterećenje za brokera, ali ako je gubitak poruka neprihvatljiv, onda nema druge mogućnosti.

Riža. 1. Matrica održivosti

Grupiranje sa zrcaljenjem čekanja

Da bismo preživjeli gubitak brokera, trebamo višak. Možemo kombinirati više RabbitMQ čvorova u klaster, a zatim dodati dodatnu redundanciju repliciranjem redova čekanja između više čvorova. Na ovaj način, ako jedan čvor zakaže, ne gubimo podatke i ostajemo dostupni.

Zrcaljenje reda čekanja:

• jedan glavni red (master), koji prima sve naredbe za pisanje i čitanje
• jedno ili više ogledala koja primaju sve poruke i metapodatke iz glavnog reda čekanja. Ova zrcala nisu tu za skaliranje, već čisto za redundanciju.

Riža. 2. Zrcaljenje reda čekanja

Zrcaljenje je postavljeno odgovarajućom politikom. U njemu možete odabrati koeficijent replikacije, pa čak i čvorove na kojima bi se trebao nalaziti red. Primjeri:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (jedan majstor i jedno ogledalo)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Potvrda izdavača

Za postizanje dosljednog snimanja potrebne su potvrde izdavača. Bez njih postoji rizik od gubitka poruka. Potvrda se šalje izdavaču nakon što se poruka zapiše na disk. RabbitMQ ne zapisuje poruke na disk po primitku, već periodično, u području od nekoliko stotina milisekundi. Kada se red čekanja zrcali, potvrda se šalje tek nakon što sva zrcala također zapišu svoju kopiju poruke na disk. To znači da korištenje potvrda dodaje kašnjenje, ali ako je sigurnost podataka važna, onda su one neophodne.

Red čekanja za nadogradnju

Kada broker odustane ili se sruši, svi voditelji reda (masteri) na tom čvoru se sruše zajedno s njim. Klaster zatim odabire najstarije zrcalo svakog mastera i promovira ga kao novog mastera.

Riža. 3. Više zrcaljenih redova čekanja i njihova pravila

Broker 3 pada. Imajte na umu da je Queue C mirror na Brokeru 2 promaknut u master. Također imajte na umu da je stvoreno novo ogledalo za red C na Brokeru 1. RabbitMQ uvijek pokušava održati faktor replikacije naveden u vašim pravilima.

Riža. 4. Broker 3 ne uspijeva, što uzrokuje kvar C reda

Sljedeći broker 1 pada! Ostao nam je samo jedan broker. Ogledalo reda B promaknuto je u glavnog.

Slika. 5

Vratili smo brokera 1. Bez obzira na to koliko dobro podaci prežive gubitak i oporavak brokera, sve zrcaljene poruke čekanja odbacuju se nakon ponovnog pokretanja. Ovo je važno napomenuti jer će biti posljedica. Ubrzo ćemo pogledati ove implikacije. Tako je broker 1 sada ponovno član klastera, a klaster pokušava biti u skladu s pravilima i stoga stvara zrcala na brokeru 1.

U ovom slučaju, gubitak brokera 1 bio je potpun, kao i podaci, tako da je nezrcaljeni red B potpuno izgubljen.

Riža. 6. Posrednik 1 vraća se na uslugu

Broker 3 ponovno je na mreži, tako da redovi čekanja A i B vraćaju zrcala stvorena na njemu kako bi zadovoljili svoje HA politike. Ali sada su svi glavni redovi čekanja na jednom čvoru! Ovo nije idealno, ravnomjerna raspodjela između čvorova je bolja. Nažalost, ovdje nema mnogo opcija za rebalans mastera. Kasnije ćemo se vratiti na ovaj problem jer prvo moramo pogledati sinkronizaciju reda čekanja.

Riža. 7. Posrednik 3 vraća se na uslugu. Svi glavni redovi na jednom čvoru!

Dakle, sada biste trebali imati ideju o tome kako ogledala pružaju redundanciju i toleranciju na greške. To osigurava dostupnost u slučaju kvara jednog čvora i štiti od gubitka podataka. Ali još nismo gotovi jer je u stvarnosti sve mnogo kompliciranije.

sinkronizacija

Prilikom stvaranja novog zrcala, sve nove poruke uvijek će se replicirati na ovo zrcalo i bilo koja druga. Što se tiče postojećih podataka u glavnom redu čekanja, možemo ih replicirati na novi mirror, koji postaje potpuna kopija glavnog. Također možemo odlučiti da ne repliciramo postojeće poruke i pustimo glavni red čekanja i novo zrcalo da se spoje na vrijeme, pri čemu nove poruke stižu na rep, a postojeće poruke napuštaju glavu glavnog reda čekanja.

Ova se sinkronizacija izvodi automatski ili ručno i njome se upravlja pomoću politike čekanja. Pogledajmo primjer.

Imamo dva zrcalna reda čekanja. Red A se sinkronizira automatski, a Red B se sinkronizira ručno. Oba reda čekanja sadrže deset poruka.

Riža. 8. Dva reda s različitim načinima sinkronizacije

Sada gubimo brokera 3.

Riža. 9. Broker 3 je pao

Broker 3 se vraća u službu. Klaster stvara ogledalo za svaki red čekanja na novom čvoru i automatski sinkronizira novi red čekanja A s glavnim. Međutim, ogledalo novog reda B ostaje prazno. Na ovaj način imamo potpunu redundanciju u redu A i samo jedno ogledalo za postojeće poruke reda B.

Riža. 10. Novo ogledalo reda A prima sve postojeće poruke, ali novo ogledalo reda B ne.

U oba reda stiže još deset poruka. Posrednik 2 se tada ruši i red A se vraća na najstarije zrcalo, koje je na posredniku 1. Nema gubitka podataka kada zakaže. U redu B postoji dvadeset poruka u masteru i samo deset u zrcalu jer ovaj red nikada nije replicirao originalnih deset poruka.

Riža. 11. Red čekanja A vraća se na brokera 1 bez gubitka poruka

U oba reda stiže još deset poruka. Sada se ruši Broker 1. Red A se lako prebacuje na zrcalo bez gubljenja poruka. Međutim, red B ima problema. U ovom trenutku možemo optimizirati dostupnost ili dosljednost.

Ako želimo optimizirati pristupačnost, onda politika ha-promaknuti-na-neuspjeh treba instalirati u uvijek. Ovo je zadana vrijednost, tako da jednostavno ne možete navesti pravilo uopće. U ovom slučaju, u biti dopuštamo kvarove u nesinkroniziranim zrcalima. To će uzrokovati gubitak poruka, ali će red ostati čitljiv i upisiv.

Riža. 12. Red čekanja A vraća se natrag na posrednika 3 bez gubitka poruka. Red čekanja B vraća se na brokera 3 s deset izgubljenih poruka

Možemo i ugraditi ha-promote-on-failure u vrijednosti when-synced. U ovom slučaju, umjesto da se vrati na zrcalo, red će čekati dok se Broker 1 sa svojim podacima ne vrati u mrežni način rada. Nakon što se vrati, glavni red se vraća na Broker 1 bez gubitka podataka. Dostupnost je žrtvovana radi sigurnosti podataka. Ali ovo je rizičan način rada koji čak može dovesti do potpunog gubitka podataka, što ćemo razmotriti uskoro.

Riža. 13. Red čekanja B ostaje nedostupan nakon gubitka brokera 1

Možete pitati: "Je li bolje nikada ne koristiti automatsku sinkronizaciju?" Odgovor je da je sinkronizacija operacija blokiranja. Tijekom sinkronizacije, glavni red čekanja ne može izvoditi nikakve operacije čitanja ili pisanja!

Pogledajmo primjer. Sada imamo jako duge redove. Kako mogu narasti do takve veličine? Iz nekoliko razloga:

• Redovi se ne koriste aktivno
• Ovo su brzi redovi, a trenutno su potrošači spori
• Redovi su brzi, došlo je do greške i potrošači sustižu korak

Riža. 14. Dva velika reda s različitim načinima sinkronizacije

Sada Broker 3 pada.

Riža. 15. Broker 3 pada, ostavljajući po jednog majstora i ogledalo u svakom redu

Broker 3 vraća se na mrežu i stvaraju se nova ogledala. Glavni red čekanja A počinje replicirati postojeće poruke na novo ogledalo, a za to vrijeme red čekanja nije dostupan. Potrebna su dva sata za repliciranje podataka, što rezultira dva sata zastoja za ovaj red!

Međutim, Red B ostaje dostupan tijekom cijelog razdoblja. Žrtvovala je nešto suvišnosti radi pristupačnosti.

Riža. 16. Red čekanja ostaje nedostupan tijekom sinkronizacije

Nakon dva sata, red A također postaje dostupan i može ponovno početi prihvaćati čitanje i pisanje.

Ažuriranja

Ovo blokiranje tijekom sinkronizacije otežava ažuriranje klastera s vrlo velikim redovima čekanja. U nekom trenutku potrebno je ponovno pokrenuti glavni čvor, što znači ili prebacivanje na zrcaljenje ili onemogućavanje čekanja dok se poslužitelj nadograđuje. Ako se odlučimo za prijelaz, izgubit ćemo poruke ako se ogledala ne sinkroniziraju. Prema zadanim postavkama, tijekom ispada brokera, ne izvodi se prijelaz na nesinkronizirano ogledalo. To znači da čim se broker vrati, ne gubimo nijednu poruku, jedina šteta je jednostavno čekanje u redu. Pravila ponašanja kada je broker isključen određena su politikom ha-promote-on-shutdown. Možete postaviti jednu od dvije vrijednosti:

• always= prijelaz na nesinkronizirana zrcala je omogućen
• when-synced= prijelaz samo na sinkronizirano zrcalo, inače red postaje nečitljiv i ne može se pisati. Red se vraća na uslugu čim se posrednik vrati

Na ovaj ili onaj način, s velikim redovima morate birati između gubitka podataka i nedostupnosti.

Kada dostupnost poboljšava sigurnost podataka

Postoji još jedna komplikacija koju treba razmotriti prije donošenja odluke. Iako je automatska sinkronizacija bolja za redundanciju, kako ona utječe na sigurnost podataka? Naravno, uz bolju redundanciju, manja je vjerojatnost da će RabbitMQ izgubiti postojeće poruke, ali što je s novim porukama izdavača?

Ovdje morate uzeti u obzir sljedeće:

• Može li izdavač jednostavno vratiti pogrešku i zatražiti od upstream usluge ili korisnika da pokušaju ponovno kasnije?
• Može li izdavač poruku spremiti lokalno ili u bazu podataka kako bi pokušao ponovno kasnije?

Ako izdavač može samo odbaciti poruku, tada zapravo poboljšanje pristupačnosti također poboljšava sigurnost podataka.

Dakle, treba tražiti ravnotežu, a rješenje ovisi o konkretnoj situaciji.

Problemi s ha-promote-on-failure=when-synced

Ideja ha-promaknuti-na-neuspjeh= kada je sinkronizirano je da sprječavamo prebacivanje na nesinkronizirani mirror i time izbjegavamo gubitak podataka. Red ostaje nečitljiv ili upisiv. Umjesto toga, pokušavamo oporaviti srušenog brokera s netaknutim podacima kako bi mogao nastaviti funkcionirati kao glavni bez gubitka podataka.

Ali (i ovo je veliko ali) ako je broker izgubio svoje podatke, onda imamo veliki problem: izgubljen je red! Svi podaci su nestali! Čak i ako imate zrcala koja uglavnom sustižu glavni red čekanja, i ta se zrcala odbacuju.

Da bismo ponovno dodali čvor s istim imenom, kažemo klasteru da zaboravi izgubljeni čvor (naredbom rabbitmqctl zaboraviti_čvor_klastera) i pokrenite novog posrednika s istim imenom hosta. Dok klaster pamti izgubljeni čvor, pamti stari red i nesinkronizirana zrcala. Kada se klasteru kaže da zaboravi napušteni čvor, taj red je također zaboravljen. Sada ga moramo ponovno deklarirati. Izgubili smo sve podatke, iako smo imali zrcala s djelomičnim skupom podataka. Bolje bi bilo prijeći na nesinkronizirano ogledalo!

Stoga, ručna sinkronizacija (i neuspjeh sinkronizacije) u kombinaciji s ha-promote-on-failure=when-synced, po mom mišljenju, prilično riskantno. Dokumenti kažu da ova opcija postoji za sigurnost podataka, ali to je dvosjekli nož.

Master rebalansiranje

Kao što smo obećali, vraćamo se problemu akumulacije svih mastera na jednom ili nekoliko čvorova. To se može dogoditi čak i kao rezultat ažuriranja valjanog klastera. U klasteru s tri čvora, svi glavni redovi će se akumulirati na jednom ili dva čvora.

Ponovno balansiranje mastera može biti problematično iz dva razloga:

• Ne postoje dobri alati za izvođenje rebalansa
• Sinkronizacija reda čekanja

Postoji treća strana za rebalans plugin, koji nije službeno podržan. Što se tiče dodataka trećih strana u RabbitMQ priručniku rekao je: “Dodatak pruža neke dodatne alate za konfiguraciju i izvješćivanje, ali nije podržan niti potvrđen od strane RabbitMQ tima. Koristite na vlastitu odgovornost."

Postoji još jedan trik za premještanje glavnog reda kroz HA pravila. U priručniku se spominje skripta za ovo. Djeluje ovako:

• Uklanja sva ogledala pomoću privremene politike koja ima viši prioritet od postojeće HA politike.
• Mijenja HA privremenu politiku za korištenje načina rada čvora, navodeći čvor na koji treba prenijeti glavni red čekanja.
• Sinkronizira red čekanja za push migraciju.
• Nakon dovršetka migracije, briše privremenu politiku. Početna HA politika stupa na snagu i stvoren je potreban broj zrcala.

Loša strana je ta što ovaj pristup možda neće funkcionirati ako imate velike redove čekanja ili stroge zahtjeve za redundancijom.

Sada da vidimo kako RabbitMQ klasteri rade s mrežnim particijama.

Gubitak povezanosti

Čvorovi distribuiranog sustava povezani su mrežnim vezama, a mrežne veze mogu i bit će isključene. Učestalost ispada ovisi o lokalnoj infrastrukturi ili pouzdanosti odabranog oblaka. U svakom slučaju, distribuirani sustavi moraju biti u stanju nositi se s njima. Još jednom imamo izbor između dostupnosti i dosljednosti, a opet je dobra vijest da RabbitMQ pruža obje opcije (samo ne u isto vrijeme).

Uz RabbitMQ imamo dvije glavne mogućnosti:

• Omogućuje logičnu podjelu (split-brain). To osigurava dostupnost, ali može uzrokovati gubitak podataka.
• Onemogući logičko odvajanje. Može rezultirati kratkoročnim gubitkom dostupnosti ovisno o tome kako se klijenti povezuju s klasterom. Također može dovesti do potpune nedostupnosti u klasteru s dva čvora.

Ali što je logično razdvajanje? Ovo je kada se klaster podijeli na dva dijela zbog gubitka mrežnih veza. Sa svake strane, zrcala se promiču u majstora, tako da na kraju postoji nekoliko majstora po potezu.

Riža. 17. Glavni red čekanja i dva ogledala, svako na posebnom čvoru. Tada dolazi do kvara na mreži i jedno ogledalo se odvaja. Odvojeni čvor vidi da su druga dva otpala i promiče svoja zrcala glavnom. Sada imamo dva glavna reda čekanja, oba za pisanje i za čitanje.

Ako izdavači pošalju podatke na oba mastera, na kraju imamo dvije različite kopije reda čekanja.

Različiti načini RabbitMQ-a pružaju dostupnost ili dosljednost.

Način zanemarivanja (zadano)

Ovaj način rada osigurava pristupačnost. Nakon gubitka veze dolazi do logičnog odvajanja. Nakon ponovnog uspostavljanja veze, administrator mora odlučiti kojoj će particiji dati prioritet. Strana koja gubi bit će ponovno pokrenuta i svi prikupljeni podaci na toj strani bit će izgubljeni.

Riža. 18. Tri izdavača povezana su s tri brokera. Interno, klaster usmjerava sve zahtjeve u glavni red čekanja na Brokeru 2.

Sada gubimo brokera 3. On vidi da su drugi brokeri pali i promovira svoje ogledalo u gospodara. Tako dolazi do logičnog razdvajanja.

Riža. 19. Logička podjela (split-brain). Zapisi idu u dva glavna reda, a dvije se kopije razlikuju.

Veza je ponovno uspostavljena, ali logično razdvajanje ostaje. Administrator mora ručno odabrati stranu koja gubi. U donjem slučaju administrator ponovno pokreće Broker 3. Gube se sve poruke koje nije uspio poslati.

Riža. 20. Administrator onemogućuje Broker 3.

Riža. 21. Administrator pokreće Broker 3 i on se pridružuje klasteru, gubeći sve poruke koje su tamo ostale.

Tijekom gubitka veze i nakon njezine obnove, klaster i ovaj red čekanja bili su dostupni za čitanje i pisanje.

Autoheal mod

Djeluje slično načinu Ignore, osim što sam klaster automatski odabire gubitničku stranu nakon razdvajanja i vraćanja veze. Strana koja gubi vraća se u klaster prazna, a red čekanja gubi sve poruke koje su poslane samo toj strani.

Pauziraj manjinski način rada

Ako ne želimo dopustiti logičko particioniranje, tada nam je jedina opcija odbaciti čitanje i pisanje na manjoj strani nakon particije klastera. Kada broker vidi da je na manjoj strani, obustavlja rad, odnosno zatvara sve postojeće veze i odbija sve nove. Jednom u sekundi provjerava uspostavljanje veze. Nakon što se veza uspostavi, nastavlja s radom i pridružuje se klasteru.

Riža. 22. Tri izdavača povezana su s tri brokera. Interno, klaster usmjerava sve zahtjeve u glavni red čekanja na Brokeru 2.

Brokeri 1 i 2 tada se odvajaju od brokera 3. Umjesto da promaknu svoje ogledalo u master, broker 3 se suspendira i postaje nedostupan.

Riža. 23. Broker 3 pauzira, isključuje sve klijente i odbija zahtjeve za povezivanje.

Nakon što se veza uspostavi, vraća se u klaster.

Pogledajmo još jedan primjer gdje je glavni red čekanja na Brokeru 3.

Riža. 24. Glavni red na Brokeru 3.

Zatim dolazi do istog gubitka povezanosti. Broker 3 zastaje jer je na manjoj strani. S druge strane, čvorovi vide da je broker 3 otpao, pa je starije zrcalo iz brokera 1 i 2 promaknuto u glavnog.

Riža. 25. Prijelaz na brokera 2 ako je broker 3 nedostupan.

Kada se veza uspostavi, Broker 3 će se pridružiti klasteru.

Riža. 26. Klaster se vratio u normalan rad.

Ovdje je važno razumjeti da dobivamo dosljednost, ali također možemo dobiti dostupnost, ako Uspješno ćemo prebaciti klijente u veći dio odjela. Za većinu situacija, ja bih osobno odabrao način Pause Minority, ali to stvarno ovisi o pojedinačnom slučaju.

Kako bi se osigurala dostupnost, važno je osigurati da se klijenti uspješno povežu s hostom. Pogledajmo naše mogućnosti.

Osiguravanje povezanosti korisnika

Imamo nekoliko opcija kako usmjeriti klijente na glavni dio klastera ili na radne čvorove (nakon što jedan čvor zakaže) nakon gubitka veze. Prvo, zapamtimo da je određeni red čekanja smješten na određenom čvoru, ali se usmjeravanje i pravila repliciraju na sve čvorove. Klijenti se mogu spojiti na bilo koji čvor, a unutarnje usmjeravanje usmjerit će ih kamo trebaju ići. Ali kada je čvor suspendiran, on odbija veze, pa se klijenti moraju povezati s drugim čvorom. Ako čvor otpadne, on malo toga može učiniti.

Naše mogućnosti:

• Klasteru se pristupa pomoću balansera opterećenja koji jednostavno kruži kroz čvorove i klijenti se ponovno pokušavaju povezati dok ne uspije. Ako je čvor neispravan ili obustavljen, tada pokušaji povezivanja na taj čvor neće uspjeti, ali sljedeći pokušaji će ići na druge poslužitelje (na kružni način). Ovo je prikladno za kratkotrajni gubitak povezivanja ili pali poslužitelj koji će se brzo vratiti.
• Pristupite klasteru putem balansera opterećenja i uklonite obustavljene/neispravne čvorove s popisa čim se otkriju. Ako to učinimo brzo i ako klijenti mogu ponovno pokušati uspostaviti vezu, tada ćemo postići stalnu dostupnost.
• Dajte svakom klijentu popis svih čvorova, a klijent nasumično odabire jedan od njih prilikom povezivanja. Ako primi pogrešku prilikom pokušaja povezivanja, pomiče se na sljedeći čvor na popisu dok se ne poveže.
• Uklonite promet s neuspješnog/suspendiranog čvora pomoću DNS-a. To se radi pomoću malog TTL-a.

Zaključci

RabbitMQ klasteriranje ima svoje prednosti i nedostatke. Najozbiljniji nedostaci su sljedeći:

• kada se pridruže klasteru, čvorovi odbacuju svoje podatke;
• blokiranje sinkronizacije uzrokuje da red čekanja postane nedostupan.

Sve teške odluke proizlaze iz ove dvije arhitektonske značajke. Kad bi RabbitMQ mogao spremati podatke kada se klaster ponovno spoji, tada bi sinkronizacija bila brža. Da je sposoban za sinkronizaciju bez blokiranja, bolje bi podržavao velike redove čekanja. Rješavanje ova dva problema uvelike bi poboljšalo izvedbu RabbitMQ-a kao visokodostupne tehnologije slanja poruka otporne na greške. Oklijevao bih preporučiti RabbitMQ s klasteriranjem u sljedećim situacijama:

• Nepouzdana mreža.
• Nepouzdano skladištenje.
• Vrlo dugi redovi.

Kada su u pitanju postavke visoke dostupnosti, razmotrite sljedeće:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Ili autoheal)
• postojane poruke
• osigurati da se klijenti povežu s aktivnim čvorom kada neki čvor zakaže

Za dosljednost (sigurnost podataka) razmotrite sljedeće postavke:

• Potvrde izdavača i ručne potvrde na strani potrošača
• ha-promote-on-failure=when-synced, ako izdavači mogu pokušati ponovno kasnije i ako imate vrlo pouzdanu pohranu! Inače staviti =always.
• ha-sync-mode=automatic (ali za velike neaktivne redove može biti potreban ručni način rada; također razmotrite hoće li nedostupnost uzrokovati gubitak poruka)
• Pauziraj manjinski način rada
• postojane poruke

Još nismo pokrili sva pitanja tolerancije grešaka i visoke dostupnosti; na primjer, kako sigurno izvršiti administrativne postupke (kao što su tekuća ažuriranja). Također moramo razgovarati o federaciji i dodatku Shovel.

Ako sam još nešto propustio, javite mi.

Vidi i moj pošta, gdje izvodim pustoš na RabbitMQ klasteru koristeći Docker i Blockade da testiram neke od scenarija gubitka poruka opisanih u ovom članku.

Prethodni članci u seriji:
br. 1 - habr.com/ru/company/itsumma/blog/416629
br. 2 - habr.com/ru/company/itsumma/blog/418389
br. 3 - habr.com/ru/company/itsumma/blog/437446

Izvor: www.habr.com