{"id":91846,"date":"2020-08-19T19:41:57","date_gmt":"2020-08-19T17:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster"},"modified":"2020-08-19T19:41:57","modified_gmt":"2020-08-19T17:41:57","slug":"o-pereezde-s-redis-na-redis-cluster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"O preselitev z Redis na Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"O preselitev z Redis na Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ko prihajanju v izdelek, ki se razvija \u017ee ve\u010d kot desetletje, ni presenetljivo sre\u010dati zastarelih tehnologij. Ampak kaj, \u010de morate \u010dez \u0161est mesecev obvladovati obremenitev, ki je desetkrat ve\u010dja, cena padcev pa se pove\u010da stokrat? V tem primeru potrebujete vrhunskega in\u017eenirja za visoko obremenitev. Ker pa takega ni, so se odlo\u010dili zaupati re\u0161itev meni. V prvem delu \u010dlanka bom opisal, kako smo pre\u0161li z Redis-a na Redis-cluster, v drugem delu pa bom dal nasvete, kako za\u010deti uporabljati cluster in na kaj biti pozoren pri njegovi uporabi.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Technologiewahl<\/h1>\n<p><\/p>\n<p>Je res tako slab <em>lo\u010den Redis<\/em> (standalone redis) v konfiguraciji 1 glavni in N klonov? Zakaj ga imenujem zastarelo tehnologijo?<\/p>\n<p><\/p>\n<blockquote><p>Ne, Redis ni tako slab... Vendar pa obstajajo nekateri pomankljivosti, ki jih ni mogo\u010de ignorirati.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>Prvi\u010d, Redis ne podpira mehanizmov za obnovitev po izpadu glavnega stre\u017enika. Za re\u0161itev tega problema smo uporabili konfiguracijo z avtomatskim preusmerjanjem VIP-ov na novega glavnega, spremembo vloge enega od klonov in preklop preostalih. Ta mehanizem je deloval, a ga ni bilo mogo\u010de \u0161teti za zanesljivo re\u0161itev. Prvi\u010d, pojavile so se la\u017ene alarme, drugi\u010d, bil je enkratni postopek in po spro\u017eitvi so bile potrebne ro\u010dne akcije.<\/p>\n<p>\n<\/li>\n<li>\n<p>Drugi\u010d, prisotnost le enega glavnega je vodila do te\u017eave s shardiranjem. Treba je bilo ustvariti ve\u010d neodvisnih clusterjev '1 glavni in N klonov', nato ro\u010dno razpr\u0161iti baze po teh strojih in upati, da se jutri ena izmed baz ne bo pove\u010dala toliko, da bi jo bilo treba prelo\u017eiti na lo\u010den instanc.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Kak\u0161ne so mo\u017enosti?<\/p>\n<p><\/p>\n<ul>\n<li>Najdra\u017eja in najbogatej\u0161a re\u0161itev je Redis-Enterprise. To je plo\u0161\u010datna re\u0161itev s popolno tehni\u010dno podporo. Kljub temu, da izgleda popolno z vidika tehnologije, nam ni ustrezala iz ideolo\u0161kih razlogov. <\/li>\n<li>Redis-cluster. Iz \u0161katle podpira avtomatsko preklapljanje glavnega in shardiranje. Vmesnik se skoraj ne razlikuje od obi\u010dajne razli\u010dice. Izgleda obetavno, o skritih pasti bomo govorili pozneje.<\/li>\n<li>Tarantool, Memcache, Aerospike in drugi. Vsa ta orodja delajo pribli\u017eno isto. Vendar ima vsako svoje pomanjkljivosti. Odlo\u010dili smo se, da ne bomo dali vseh jajc v eno ko\u0161arico. Memcache in Tarantool uporabljamo za druge naloge, in povem vnaprej, da smo imeli z njimi ve\u010d te\u017eav.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Specifika uporabe<\/h1>\n<p><\/p>\n<p>Poglejmo, katere naloge smo zgodovinsko re\u0161evali z Redisom in kak\u0161ne funkcionalnosti smo uporabljali:<\/p>\n<p><\/p>\n<ul>\n<li>Predpomnilnik pred poizvedbami do oddaljenih storitev, kot je 2GIS | Golang<br \/>\n<blockquote><p>GET SET MGET MSET &quot;SELECT DB&quot;\n<\/p><\/blockquote>\n<\/li>\n<li>Predpomnilnik pred MYSQL | PHP<br \/>\n<blockquote><p>GET SET MGET MSET SCAN &quot;KEY BY PATTERN&quot; &quot;SELECT DB&quot;\n<\/p><\/blockquote>\n<\/li>\n<li>Glavno skladi\u0161\u010de za storitev za upravljanje s sejami in koordinatami voznikov | Golang<br \/>\n<blockquote><p>GET SET MGET MSET &quot;SELECT DB&quot; &quot;ADD GEO KEY&quot; &quot;GET GEO KEY&quot; SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Kot vidite, nobene vi\u0161je matematike. Kje pa je potem zapletenost? Poglejmo posamezno vsako metodo.<\/p>\n<p><\/p>\n<p>Metod<br \/>\nOpis<br \/>\nPosebnosti Redis-cluster<br \/>\nSolution<\/p>\n<p>GET SET<br \/>\nZapisati \/ prebrati klju\u010d<\/p>\n<p>MGET MSET<br \/>\nZapisati \/ prebrati ve\u010d klju\u010dev<br \/>\nKlju\u010di bodo na razli\u010dnih vozlih. Gotove knji\u017enice znajo izvajati Multi-operacije le v okviru enega vozla<br \/>\nZamenjati MGET z pipeline-om N GET operacij<\/p>\n<p>IZBERI DB<br \/>\nIzberite bazo, s katero bomo delali<br \/>\nNe podpira ve\u010d baz podatkov<br \/>\nVse shraniti v eno bazo. Dodajte predpone klju\u010dem<\/p>\n<p>SCAN<br \/>\nPrebrskati vse klju\u010de v bazi<br \/>\nKer imamo eno bazo, je pre\u010dkanje vseh klju\u010dev v clustrov preve\u010d potratno<br \/>\nOhraniti invariant znotraj enega klju\u010da in izvesti HSCAN po tem klju\u010du. Ali se popolnoma odpovedati<\/p>\n<p>GEO<br \/>\nOperacije z geo klju\u010dem<br \/>\nGeo klju\u010d ni shardiran<\/p>\n<p>KLJU\u010c PO PATRONU<br \/>\nIskanje klju\u010da po vzorcu<br \/>\nKer imamo eno bazo, bomo iskali po vseh klju\u010dih v clustrov. Preve\u010d potratno<br \/>\nOdpovedati se ali ohranjati invariant, kot pri SCAN-u<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis proti Redis-cluster<\/h1>\n<p><\/p>\n<p>Kaj izgubljamo in kaj pridobimo pri prehodu na cluster?<\/p>\n<p><\/p>\n<ul>\n<li>Slabosti: izgubljamo funkcionalnost ve\u010d baz. \n<ul>\n<li>\u010ce \u017eelimo shranjevati v enem clustru logi\u010dno nepovezane podatke, bomo morali izdelati re\u0161itev v obliki predpon. <\/li>\n<li>Izgubimo vse operacije 'po bazi', kot so SCAN, DBSIZE, CLEAR DB itd.<\/li>\n<li>Multi-operacije so postale bistveno bolj zapletene za izvajanje, ker je lahko potrebno dostopati do ve\u010d vozlov.<\/li>\n<\/ul>\n<\/li>\n<li>Prednosti: \n<ul>\n<li>Odpornost v obliki preklopa na rezervnega vodjo.<\/li>\n<li>Shardiranja na strani Redis.<\/li>\n<li>Prenos podatkov med vozli atomarno in brez zastojev.<\/li>\n<li>Dodajanje in prerazporeditev zmogljivosti in obremenitev brez zastojev.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Pri\u010dakujem, da \u010de vam ni treba zagotoviti visoke ravni odpornosti, premik na klaster ne bo vreden truda, saj je to lahko zapletena naloga. Vendar, \u010de morate izbrati med lo\u010deno razli\u010dico in klastrsko, je smiselno izbrati klaster, ker ni ni\u010d slab\u0161i in dodatno vam odvzame del skrbi.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Priprava na selitev<\/h1>\n<p><\/p>\n<p>Za\u010dnimo s zahtevami za selitev:<\/p>\n<p><\/p>\n<ul>\n<li>Mora biti brez\u0161ivna. Popolna zaustavitev storitve za 5 minut nas ne zadostuje.<\/li>\n<li>Mora biti kar se da varen in postopno izveden. \u017delimo imeti nadzor nad situacijo. Ne \u017eelimo, da vse prenesemo hkrati in molimo za gumb za povrnitev.<\/li>\n<li>Minimalne izgube podatkov med selitvijo. Zavedamo se, da bo atomarno selitev zelo te\u017eko izvesti, zato dopu\u0161\u010damo dolo\u010deno nesinkronizacijo med podatki v obi\u010dajnem in klasterskem Redis-u.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Vzdr\u017eevanje klasterja<\/h1>\n<p><\/p>\n<p>Pred selitvijo se je vredno vpra\u0161ati, ali lahko vzdr\u017eujemo klaster:<\/p>\n<p><\/p>\n<ul>\n<li>Grafi. Uporabljamo Prometheus in Grafano za grafi\u010dne prikaze obremenitve procesorjev, zasedenosti pomnilnika, \u0161tevila strank, \u0161tevila operacij GET, SET, AUTH itd.<\/li>\n<li>Strokovnost. Predstavljajte si, da bo jutri pod va\u0161o odgovornostjo ogromen klaster. \u010ce se pokvari, ga nih\u010de, razen vas, ne bo mogel popraviti. \u010ce bo za\u010del upo\u010dasnjevati \u2014 vsi se bodo obrnili k vam. \u010ce bo treba dodati vire ali prerazporediti obremenitev \u2014 spet k vam. Da ne postanete sivi pri 25, je smiselno predvideti te primere in vnaprej preveriti, kako se bo tehnologija obna\u0161ala pri tak\u0161nih ali druga\u010dnih dejanjih. O tem se bomo podrobneje pogovorili v razdelku 'Strokovnost'.<\/li>\n<li>Nadzori in obvestila. Ko se klaster pokvari, bi \u017eeleli izvedeti prvi. Tu smo se omejili na obve\u0161\u010danje, da vse vozli\u0161\u010da vra\u010dajo enake informacije o stanju klasterja (da, v\u010dasih je tudi druga\u010de). Druge te\u017eave je hitreje opaziti preko obvestil storitev-odjemalcev Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Preseljenje<\/h1>\n<p><\/p>\n<p>Kako se bomo selili:<\/p>\n<p><\/p>\n<ul>\n<li>Najprej je potrebno pripraviti knji\u017enico za delo s klasterjem. Kot osnovo za razli\u010dico v G\u043e smo vzeli go-redis in jo nekoliko prilagodili. Implementirali smo Multi-metode preko pipeline-ov, prav tako pa nekoliko spremenili pravila ponavljanja poizvedb. Z razli\u010dico za PHP je bilo ve\u010d te\u017eav, vendar smo se nazadnje odlo\u010dili za php-redis. Nedavno so uvedli podporo za klaster, ki se nam zdi dobro zasnovana.<\/li>\n<li>Nato je potrebno postaviti klaster. To lahko storimo dobesedno v dveh ukazih na podlagi konfiguracijske datoteke. Podrobneje o nastavitvah bomo razpravljali kasneje.<\/li>\n<li>Za postopno preselitev uporabljamo dry-mode. Ker imamo dve razli\u010dici knji\u017enice z enakim vmesnikom (eno za obi\u010dajno razli\u010dico, drugo za klaster), ni te\u017eko ustvariti ovitka, ki bo deloval z lo\u010deno razli\u010dico in hkrati podvajal vse poizvedbe v klaster, primerjal odgovore in bele\u017eil razlike v dnevnikih (v na\u0161em primeru v NewRelic). Tako, tudi \u010de se klasterna razli\u010dica pri uvajanju zlomi, na\u0161 produkcijski sistem ne bo prizadet. <\/li>\n<li>Ko je klaster uveden v dry-re\u017eimu, lahko mirno spremljamo graf razhajanja odgovorov. \u010ce se dele\u017e napak po\u010dasi, a zanesljivo pribli\u017euje neki majhni konstanti, to pomeni, da je vse v redu. Zakaj kljub temu obstajajo razhajanja? Ker se zapis v lo\u010deni razli\u010dici zgodi nekoliko prej kot v klasterju, in z mikro zamikom se lahko podatki razhajajo. Preostalo je le \u0161e preveriti dnevnike razhajanja, in \u010de so vsi razumljivi zaradi neatomarnosti zapisa, lahko gremo naprej.<\/li>\n<li>Zdaj lahko obrnemo dry-mode. Pisali in brali bomo iz klasterja, in podvajali v lo\u010deno razli\u010dico. Zakaj? V naslednjem tednu \u017eelimo opazovati delovanje klasterja. \u010ce se izka\u017ee, da so ob takratnih obremenitvah te\u017eave ali pa smo kaj spregledali, imamo vedno mo\u017enost vra\u010danja na staro kodo s trenutnimi podatki, zahvaljujo\u010d dry-mode.<\/li>\n<li>Preostalo je le \u0161e izklju\u010diti dry-mode in odstraniti lo\u010deno razli\u010dico. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Ekspertiza<\/h1>\n<p><\/p>\n<p>Najprej na kratko o delovanju klasterja.<\/p>\n<p><\/p>\n<p>Najprej, Redis je key-value shranjevanje. Kot klju\u010d se uporabljajo poljubne nize. Kot vrednosti se lahko uporabljajo \u0161tevilke, nizi in celotne strukture. Teh je ne\u0161teto, vendar za razumevanje splo\u0161ne strukture to ni pomembno.<br \/>\nNaslednji nivo abstrakcije po klju\u010dih so re\u017ee (SLOTS). Vsak klju\u010d pripada enemu od 16.383 re\u017e. Znotraj vsake re\u017ee lahko obstaja neomejeno \u0161tevilo klju\u010dev. Tako so vsi klju\u010di razdeljeni na 16.383 nepreglednih mno\u017eic.<br \/>\n<img decoding=\"async\" alt=\"O preselitev z Redis na Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nadalje, v klastru mora biti N master vozli\u0161\u010d. Vsako vozli\u0161\u010de lahko obravnavamo kot lo\u010den instan\u010dni Redis, ki ve vse o drugih vozli\u0161\u010dih znotraj klastre. Vsaka master vozli\u0161\u010de vsebuje dolo\u010deno \u0161tevilo re\u017e. Vsaka re\u017e pripada samo eni master vozli\u0161\u010du. Vse re\u017ee je potrebno razporediti med vozli\u0161\u010da. \u010ce dolo\u010dene re\u017ee niso razporejene, klju\u010di, shranjeni v njih, ne bodo dostopni. Vsako master vozli\u0161\u010de je smiselno zagnati na lo\u010deni logi\u010dni ali fizi\u010dni napravi. Prav tako je treba upo\u0161tevati, da vsako vozli\u0161\u010de deluje samo na enem jedru, in \u010de \u017eelite na eni logi\u010dni napravi zagnati ve\u010d instanc Redis, se prepri\u010dajte, da delujejo na razli\u010dnih jedrih (sami nismo tega preizkusili, a teoreti\u010dno bi moralo delovati). V bistvu master vozli\u0161\u010da zagotavljajo obi\u010dajno razdelitev, in ve\u010dje \u0161tevilo master vozli\u0161\u010d omogo\u010da skaliranje pisnih in bralnih poizvedb.<\/p>\n<p><\/p>\n<p>Ko so vsi klju\u010di razporejeni po re\u017eah, in so re\u017ee razporejene med master vozli\u0161\u010da, lahko vsaki master vozli\u0161\u010du dodamo poljubno \u0161tevilo slave vozli\u0161\u010d. Znotraj vsakih takih povezav \"master-slave\" deluje obi\u010dajna replikacija. Slaves so potrebni za skaliranje bralnih poizvedb in za preklapljanje v primeru okvare master vozli\u0161\u010da.<br \/>\n<img decoding=\"async\" alt=\"O preselitev z Redis na Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zdaj se pogovorimo o operacijah, ki bi jih bilo dobro znati izvesti.<\/p>\n<p><\/p>\n<p>Do sistema se bomo obrnili preko Redis-CLI. Ker Redis nima enotne to\u010dke vstopa, je mo\u017eno izvajati naslednje operacije na katerem koli vozli\u0161\u010du. V vsakem odstavku posebej poudarjam mo\u017enost izvajanja operacije pod obremenitvijo.<\/p>\n<p><\/p>\n<ul>\n<li>Prva in najpomembnej\u0161a stvar, ki jo potrebujemo: operacija cluster nodes. Ta vrne stanje klasterja, prika\u017ee seznam vozli\u0161\u010d, njihove vloge, razporeditev re\u017e itd. Dodatne informacije lahko pridobimo s pomo\u010djo cluster info in cluster slots.<\/li>\n<li>Bilo bi dobro mo\u0107i dodavati i uklanjati \u010dvorove. Za to postoje operacije cluster meet i cluster forget. Obratite pozornost da cluster forget treba primijeniti na SVAKI \u010dvor, kako na mastere, tako i na replike. A cluster meet treba pozvati samo na jednom \u010dvoru. Ova razlika mo\u017ee zbuniti, pa je bolje upoznati se s njom prije nego \u0161to pokrenete klaster u proizvodnji. Dodavanje \u010dvora se sigurno vr\u0161i u radu i nikako ne utje\u010de na funkcioniranje klastera (\u0161to je logi\u010dno). Ako planirate ukloniti \u010dvor iz klastera, trebate se uvjeriti da na njemu nema slotova (ina\u010de riskirate gubitak pristupa svim klju\u010devima na tom \u010dvoru). Tako\u0111er, ne uklanjajte master koji ima slave, ina\u010de \u0107e se provoditi bespotrebno glasanje za novog mastera. Ako na \u010dvorovima ve\u0107 nema slotova, to je manji problem, ali za\u0161to bismo imali suvi\u0161ne izbore kada mo\u017eemo prvo ukloniti slave.<\/li>\n<li>Ako je potrebno silom zamijeniti master i slave, mo\u017ee se koristiti naredba cluster failover. Pozivaju\u0107i je u radu, treba shvatiti da \u0107e master biti nedostupan tijekom izvr\u0161avanja operacije. Obi\u010dno prebacivanje traje manje od sekunde, ali nije atomsko. Mo\u017eete ra\u010dunati da \u0107e dio zahtjeva prema masteru u tom trenutku zavr\u0161iti s gre\u0161kom.<\/li>\n<li>Preden odstranite vozli\u0161\u010de iz klasterja, na njem ne sme ostati nobenih re\u017e. Najbolje jih je prenesti z ukazom cluster reshard. Re\u017ee bodo prenesene z enega mojstra na drugega. Celoten postopek lahko traja nekaj minut, odvisno od koli\u010dine prenesenih podatkov, vendar je proces prenosa varen in ne vpliva na delovanje klasterja. Tako lahko vse podatke prenesete z enega vozli\u0161\u010da na drugo med obremenitvijo, ne da bi skrbeli za njihovo dostopnost. Vendar obstajajo tudi nekatere nianse. Prvi\u010d, prenos podatkov obremeni tako prejemno kot po\u0161iljateljsko vozli\u0161\u010de. \u010ce je prejemno vozli\u0161\u010de \u017ee mo\u010dno obremenjeno z obdelavo, ga ne obremenjujte \u0161e z novimi podatki. Drugi\u010d, takoj ko na po\u0161iljateljskem mojstru ne bo ve\u010d nobenih re\u017e, bodo vsi njegovi slavi takoj pre\u0161li k mojstru, na katerega so bile te re\u017ee prenesene. In te\u017eava je v tem, da si vsi ti slavi hkrati \u017eelijo sinhronizirati podatke. Imate \u0161e sre\u010do, \u010de bo to delna, ne pa popolna sinhronizacija. Upo\u0161tevajte to in kombinirajte operacije prenosa re\u017e in izklopa\/prenosa slavov. Ali pa upajte, da imate dovolj rezerve.<\/li>\n<li>Kaj storiti, \u010de med prenosom odkrijete, da ste kje izgubili re\u017ee? Upam, da vas ta te\u017eava ne bo zajela, toda \u010de \u017ee, obstaja operacija cluster fix. Ta slabo in dobro razpr\u0161i re\u017ee po vozli\u0161\u010dih naklju\u010dno. Priporo\u010dam, da preverite njeno delovanje, preden iz klasterja odstranite vozli\u0161\u010de z razporejenimi re\u017eami. Ker podatki v nerazporejenih re\u017eah nekako niso dostopni, je skrb za te\u017eave z dostopnostjo teh re\u017e \u017ee prepozna. Na razporejene re\u017ee ta operacija ne bo vplivala.<\/li>\n<li>\u0160e ena koristna operacija je monitor. Ta omogo\u010da v realnem \u010dasu videti celoten seznam poizvedb, ki prihajajo na vozli\u0161\u010de. Kar je \u0161e bolj\u0161e, po njej lahko izvedete grep in izveste, ali obstaja potreben promet.<\/li>\n<\/ul>\n<p><\/p>\n<p>Prav tako je vredno omeniti postopek preklopa mojstra. Na kratko: obstaja, in po mojem mnenju deluje odli\u010dno. Vendar pa ne mislite, da bo Redis takoj preklopil in stranke ne bodo opazile izgube, \u010de iztaknete vti\u010d na napravi z mojstrsko vozli\u0161\u010de. Po mojih izku\u0161njah preklop traja nekaj sekund. V tem \u010dasu bodo nekateri podatki nedostopni: zazna se nedostopnost mojstra, vozli\u0161\u010da glasujejo za novega, slavi se preklapljajo, podatki se sinhronizirajo. Najbolj\u0161i na\u010din, da se sami prepri\u010date, da shema deluje, je, da izvedete lokalna usposabljanja. Postavite klaster na svojem prenosniku, dajte minimalno obremenitev, simulirajte padec (na primer, tako, da blokirate porte) in ocenite hitrost preklopa. Po mojem mnenju lahko le z dvodnevnim igranjem tak\u0161ne vrste postanete prepri\u010dani v delovanje tehnologije. No, ali pa upate, da programska oprema, ki jo uporablja polovica interneta, zagotovo deluje.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">\u041a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044f<\/h1>\n<p><\/p>\n<p>Pogosto je konfiguracija prva stvar, ki jo potrebujemo za za\u010detek dela z orodjem. Ko vse deluje, pa se ne \u017eelimo ve\u010d dotikati konfiguracije. Potrebna je dolo\u010dena prizadevanja, da se prisilimo vrniti k nastavitvam in jih skrbno pregledati. Po mojem spominu smo imeli vsaj dva resna spodrsljaja zaradi nepazljivosti do konfiguracije. Bodite \u0161e posebej pozorni na naslednje to\u010dke:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>\u010cas, po katerem se zaprejo neaktivne povezave (v sekundah). 0 \u2014 se ne zaprejo.<\/em><br \/>\nNe glede na to, da na\u0161e knji\u017enice niso vse znale pravilno zapirati povezav. \u010ce izklopimo to nastavitev, tvegamo, da bomo dosegli omejitev \u0161tevila strank. Po drugi strani pa, \u010de tak\u0161na te\u017eava obstaja, bo samodejno prekinjanje izgubljenih povezav to prikrilo, in morda ne bomo opazili. Poleg tega te nastavitve ne smete vklju\u010devati pri uporabi persist-poni\u017eanj.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Shranjevanje RDB-posnetka.<\/em><br \/>\nTe\u017eave RDB\/AOF bomo podrobno obravnavali spodaj.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>\u010ce je vklju\u010deno, bo mojster prenehal sprejemati zahteve za spremembo ob napaki RDB-posnetka. \u010ce se povezava z mojstrom izgubi, lahko slave \u0161e naprej odgovarja na zahteve (yes). Ali pa preneha odgovarjati (no).<\/em><br \/>\nNi nam v\u0161e\u010d situacija, kjer Redis postane bu\u010da.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>Po tem \u010dasu bomo za\u010deli skrbeti, da je mojster odpovedal in je \u010das za izvajanje postopka failover.<\/em><br \/>\nRavno tako bo potrebno ro\u010dno iskati ravnote\u017eje med la\u017enimi alarmi in zagonim failover. Po na\u0161em izku\u0161njah je to 5 sekund.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>To\u010dno toliko podatkov lahko hranimo v predpomnilniku za odpadlo replico. \u010ce se predpomnilnik izprazni, se bo potrebno popolnoma sinhronizirati.<\/em><br \/>\nPraksa ka\u017ee, da je bolje nastaviti nekoliko ve\u010djo vrednost. Razlogov, zakaj lahko republika za\u010dne zamujati, je dovolj. \u010ce zamujate, je velika verjetnost, da \u017ee va\u0161 mojster komaj zmore, in popolna sinhronizacija bo zadnja kaplja.<\/li>\n<li>maxclients 10000<br \/>\n<em>Najve\u010dje \u0161tevilo hkrati povezanih strank.<\/em><br \/>\nPo na\u0161ih izku\u0161njah je bolje nastaviti ve\u010djo vrednost. Redis odli\u010dno obvlada 10 tiso\u010d povezav. Le poskrbite, da bo v sistemu dovolj re\u017e. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>Pravilnik, po katerem se klju\u010di bri\u0161ejo, ko dose\u017eemo omejitev razpolo\u017eljive pomnilnika.<\/em><br \/>\nTukaj ni pomembno samo pravilo, temve\u010d razumevanje, kako bo to potekalo. Redis zaslu\u017ei pohvalo za sposobnost, da brez te\u017eav deluje pri doseganju omejitve pomnilnika. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">Te\u017eave RDB in AOF<\/h1>\n<p><\/p>\n<p>\u010ceprav sam Redis shranjuje vse informacije v delovnem pomnilniku, obstaja tudi mehanizem za shranjevanje podatkov na disk. Natan\u010dneje, tri mehanizme:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 popoln posnetek vseh podatkov. Nastavi se z konfiguracijo SAVE X Y in bere kot \"Shrani popoln posnetek vseh podatkov vsakih X sekund, \u010de se je spremenil vsaj Y klju\u010dev.\"<\/li>\n<li>Append-only file \u2014 seznam operacij v zaporedju njihovega izvajanja. Dodaja nove prihajajo\u010de operacije v datoteko vsakih X sekund ali po Y operacijah.<\/li>\n<li>RDB in AOF \u2014 kombinacija dveh prej\u0161njih.<\/li>\n<\/ul>\n<p><\/p>\n<p>Vsaka metoda ima svoje prednosti in slabosti, ne bom jih na\u0161teval vseh, le opozoril bom na manj o\u010ditne, po mojem mnenju, vidike.<\/p>\n<p><\/p>\n<p>Prvi\u010d, za shranitev RDB-snapshot je potrebno poklicati FORK. \u010ce je podatkov veliko, lahko to obremeni celoten Redis za obdobje od nekaj milisekund do sekunde. Poleg tega sistem potrebuje dodeliti pomnilnik za tak snapshot, kar privede do potrebe po dvojni rezervi delovnega pomnilnika na logi\u010dni napravi: \u010de je za Redis namenjenih 8 GB, mora biti na virtualni napravi na voljo 16.<\/p>\n<p><\/p>\n<p>Po drugi strani se pojavljajo te\u017eave s parcialno sinhronizacijo. V na\u010dinu AOF, ko se slavni stre\u017enik ponovno pove\u017ee, se lahko namesto parcialne sinhronizacije izvede popolna. Zakaj se to dogaja, mi ni uspelo razumeti. Vendar se je o tem vredno spomniti.<\/p>\n<p><\/p>\n<p>Ti dve to\u010dki \u017ee pripeljeta do razmi\u0161ljanja, ali so ti podatki res potrebni na disku, \u010de se \u017ee vse podvaja s slavnimi stre\u017eniki. Podatke je mogo\u010de izgubiti le, \u010de vsi slavni stre\u017eniki odpovejo, kar je problem na ravni 'po\u017ear v podatkovnem centru'. Kot kompromis lahko predlagamo shranjevanje podatkov le na slavnih stre\u017enikih, vendar je v tem primeru treba zagotoviti, da ti stre\u017eniki nikoli ne postanejo glavni pri nujnem okrevanju (za to je nastavitev prioritet slavnimi stre\u017eniki v njihovi konfiguraciji). V vsakem posameznem primeru se spra\u0161ujemo, ali je smiselno shraniti podatke na disk, in ve\u010dinoma odgovarjamo 'ne'.<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Zaklju\u010dek<\/h1>\n<p><\/p>\n<p>Na koncu upam, da sem dal splo\u0161en pregled delovanja redis-clustra za tiste, ki o njem \u0161e niso sli\u0161ali, ter izpostavil nekatere o\u010ditne vidike za tiste, ki ga \u017ee dolgo uporabljajo.<br \/>\nHvala za va\u0161 \u010das in kot vedno so komentarji na temo dobrodo\u0161li.<\/p>\n<p>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/515620\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91847,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91846","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47O selitvi z Redis na Redis-cluster | ProHoster","description":"Prihajanje v izdelek, ki se razvija naprej.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster","og:description":"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-19T17:41:57+00:00","article:modified_time":"2020-08-19T17:41:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91846","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:19:41","updated":"2022-10-03 14:54:15","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}