{"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\/no\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"Om flyttingen fra Redis til Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Om flyttingen fra Redis til Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>N\u00e5r man jobber med et produkt som har utviklet seg i over ti \u00e5r, er det ikke overraskende \u00e5 finne utdaterte teknologier i det. Men hva skjer hvis du om seks m\u00e5neder m\u00e5 h\u00e5ndtere en belastning som er ti ganger h\u00f8yere, og kostnaden ved nedetid \u00f8ker hundre ganger? I s\u00e5 fall trenger du en dyktig Highload Engineer. Men siden vi ikke hadde en slik tilgjengelig, ble problemet overlatt til meg. I del \u00e9n av artikkelen vil jeg fortelle om overgangen fra Redis til Redis-cluster, og i del to vil jeg gi r\u00e5d om hvordan man begynner \u00e5 bruke clusteren og hva man b\u00f8r v\u00e6re oppmerksom p\u00e5 under driften.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Valg av teknologi<\/h1>\n<p><\/p>\n<p>Er det s\u00e5 ille <em>med en egen Redis<\/em> (standalone redis) i en konfigurasjon med 1 master og N slaver? Hvorfor kaller jeg det en utdatert teknologi?<\/p>\n<p><\/p>\n<blockquote><p>Nei, Redis er ikke s\u00e5 ille... Men det er noen ulemper som ikke kan ignoreres.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>For det f\u00f8rste st\u00f8tter ikke Redis mekanismer for gjenoppretting etter feil p\u00e5 masteren. For \u00e5 l\u00f8se dette problemet brukte vi en konfigurasjon med automatisk overf\u00f8ring av VIP-er til den nye masteren, endring av rollen til en av slavene og bytting av de andre. Denne mekanismen fungerte, men man kunne ikke kalle det en p\u00e5litelig l\u00f8sning. For det f\u00f8rste oppsto det falske positive varsler, og for det andre var det engangsbruk, og etter en utl\u00f8sing var det behov for manuell h\u00e5ndtering for \u00e5 f\u00e5 det tilbake til normal.<\/p>\n<p>\n<\/li>\n<li>\n<p>For det andre f\u00f8rte det \u00e5 ha bare \u00e9n master til problemer med sharding. Man m\u00e5tte opprette flere uavhengige klynger med '1 master og N slaver', deretter manuelt fordele databasene p\u00e5 disse maskinene og h\u00e5pe at en av databasene ikke ble s\u00e5 stor at den m\u00e5tte flyttes til en egen instans.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Hva er alternativene?<\/p>\n<p><\/p>\n<ul>\n<li>Den dyreste og mest omfattende l\u00f8sningen er Redis-Enterprise. Dette er en pakkel\u00f8sning med full teknisk st\u00f8tte. Selv om det ser perfekt ut fra et teknisk synspunkt, passet det ikke for oss av ideologiske grunner. <\/li>\n<li>Redis-cluster. Ut av boksen har det st\u00f8tte for automatisk failover av masteren og sharding. Grensesnittet er nesten identisk med den vanlige versjonen. Det ser lovende ut, og vi vil diskutere mulige fallgruver senere.<\/li>\n<li>Tarantool, Memcache, Aerospike og andre. Alle disse verkt\u00f8yene gj\u00f8r omtrent det samme. Men hver av dem har sine egne ulemper. Vi har bestemt oss for ikke \u00e5 legge alle eggene i en kurv. Memcache og Tarantool bruker vi til andre oppgaver, og for \u00e5 v\u00e6re f\u00f8r vi kommer til poenget, skal jeg si at vi har hatt flere problemer med dem i v\u00e5r praksis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Spesifikasjonen for bruk<\/h1>\n<p><\/p>\n<p>La oss se p\u00e5 hvilke oppgaver vi historisk har l\u00f8st med Redis og hvilken funksjonalitet vi har brukt:<\/p>\n<p><\/p>\n<ul>\n<li>Cache f\u00f8r foresp\u00f8rselen til eksterne tjenester som 2GIS | Golang<br \/>\n<blockquote><p>HENT SET MGET MSET \"VELJ DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cache f\u00f8r MYSQL | PHP<br \/>\n<blockquote><p>HENT SET MGET MSET SKANN \"N\u00d8KKEL ETTER M\u00d8NSTER\" \"VELJ DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Hovedlagring for tjenesten som arbeider med \u00f8kter og koordinater til sj\u00e5f\u00f8rer | Golang<br \/>\n<blockquote><p>HENT SET MGET MSET \"VELJ DB\" \"LEGG TIL GEO N\u00d8KKEL\" \"HENT GEO N\u00d8KKEL\" SKANN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Som du ser, ingen h\u00f8yere matematikk. Hva er s\u00e5 kompleksiteten? La oss se n\u00e6rmere p\u00e5 hver metode.<\/p>\n<p><\/p>\n<p>Metode<br \/>\nDescription<br \/>\nEgenskaper ved Redis-kluster<br \/>\nSolution<\/p>\n<p>GET SET<br \/>\nSkrive\/lese n\u00f8kkel<\/p>\n<p>MGET MSET<br \/>\nSkrive\/lese flere n\u00f8kler<br \/>\nN\u00f8klene vil ligge p\u00e5 forskjellige noder. Ferdige biblioteker kan kun gj\u00f8re Multi-operasjoner innenfor en node.<br \/>\nErstatt MGET med en pipeline av N GET-operasjoner<\/p>\n<p>SELECT DB<br \/>\nVelge databasen vi skal bruke<br \/>\nSt\u00f8tter ikke flere databaser<br \/>\nOppbevar alt i \u00e9n database. Legg til prefikser til n\u00f8klene<\/p>\n<p>SCAN<br \/>\nG\u00e5 gjennom alle n\u00f8klene i databasen<br \/>\nSiden vi har \u00e9n database, er det for kostbart \u00e5 g\u00e5 gjennom alle n\u00f8klene i klusteret.<br \/>\nOpprettholde invariant innenfor en n\u00f8kkel og gj\u00f8re HSCAN p\u00e5 denne n\u00f8kkelen. Eller avst\u00e5 helt.<\/p>\n<p>GEO<br \/>\nOperasjoner med geon\u00f8kkel<br \/>\nGeon\u00f8kkelen deles ikke opp.<\/p>\n<p>KEY BY PATTERN<br \/>\nS\u00f8ke etter n\u00f8kkel basert p\u00e5 m\u00f8nster<br \/>\nSiden vi har \u00e9n database, skal vi s\u00f8ke gjennom alle n\u00f8klene i klusteret. For kostbart.<br \/>\nAvst\u00e5 eller opprettholde invariant, som i tilfellet med SCAN.<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-kluster<\/h1>\n<p><\/p>\n<p>Hva mister vi og hva f\u00e5r vi ved \u00e5 g\u00e5 over til kluster?<\/p>\n<p><\/p>\n<ul>\n<li>Ulemper: vi mister funksjonaliteten til flere databaser. \n<ul>\n<li>Hvis vi vil lagre logisk usammenhengende data i ett kluster, m\u00e5 vi lage l\u00f8sninger med prefikser. <\/li>\n<li>Vi mister alle operasjoner \"per database\", som SCAN, DBSIZE, CLEAR DB osv.<\/li>\n<li>Multi-operasjoner har blitt betydelig vanskeligere \u00e5 implementere, fordi det kan kreve tilgang til flere noder.<\/li>\n<\/ul>\n<\/li>\n<li>Fordeler: \n<ul>\n<li>Feiltoleranse i form av n\u00f8dskifting av hovedserver.<\/li>\n<li>Shardingside p\u00e5 Redis.<\/li>\n<li>Overf\u00f8ring av data mellom noder atomisk og uten nedetid.<\/li>\n<li>Legge til og omfordele kapasitet og belastninger uten nedetid.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Jeg vil konkludere med at si at hvis du ikke trenger \u00e5 sikre et h\u00f8yt niv\u00e5 av tilgjengelighet, s\u00e5 er det ikke verdt \u00e5 flytte til en klynge, da dette kan v\u00e6re en krevende oppgave. Men hvis man f\u00f8rst velger mellom en separat versjon og en klynge, b\u00f8r man velge klyngen, da den ikke er d\u00e5rligere, og i tillegg vil den ta bort noe av bekymringen.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Forberedelse til flytting<\/h1>\n<p><\/p>\n<p>Vi begynner med kravene til flyttingen:<\/p>\n<p><\/p>\n<ul>\n<li>Den m\u00e5 v\u00e6re s\u00f8ml\u00f8s. En total stopp av tjenesten i 5 minutter er uakseptabelt for oss.<\/li>\n<li>Den b\u00f8r v\u00e6re s\u00e5 sikker og gradvis som mulig. Vi \u00f8nsker \u00e5 ha kontroll over situasjonen. \u00c5 kaste alt p\u00e5 en gang og stole p\u00e5 nedgraderingsknappen er ikke noe vi \u00f8nsker.<\/li>\n<li>Minimale datatap under flyttingen. Vi forst\u00e5r at det vil v\u00e6re sv\u00e6rt vanskelig \u00e5 flytte atom\u00e6rt, s\u00e5 vi aksepterer en viss desynkronisering mellom dataene i vanlig og klynge Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Vedlikehold av klyngen<\/h1>\n<p><\/p>\n<p>F\u00f8r selve flyttingen, b\u00f8r vi vurdere om vi kan vedlikeholde klyngen:<\/p>\n<p><\/p>\n<ul>\n<li>Grafikk. Vi bruker Prometheus og Grafana for grafikk over CPU-bruk, minnebruk, antall klienter, antall GET, SET, AUTH-operasjoner, osv.<\/li>\n<li>Ekspertise. Tenk deg at i morgen vil du ha ansvaret for en enorm klynge. Hvis den krasjer, s\u00e5 er det ingen andre enn deg som kan fikse den. Hvis den begynner \u00e5 fungere sakte - vil alle komme til deg. Hvis ressurser m\u00e5 legges til eller belastning m\u00e5 omfordeles - igjen til deg. For \u00e5 unng\u00e5 \u00e5 bli gr\u00e5h\u00e5ret i en alder av 25, b\u00f8r man forutse disse situasjonene og teste p\u00e5 forh\u00e5nd hvordan teknologien vil oppf\u00f8re seg under ulike handlinger. Vi vil diskutere dette n\u00e6rmere i delen om 'Ekspertise'.<\/li>\n<li>Overv\u00e5kning og varsler. N\u00e5r klyngen krasjer, \u00f8nsker vi \u00e5 bli informert f\u00f8rst. Her har vi begrenset oss til varsler om at alle noder returnerer den samme informasjonen om klyngens tilstand (ja, det kan v\u00e6re annerledes). Andre problemer blir raskere oppdaget gjennom varsler fra Redis-klienttjenester.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Flytting<\/h1>\n<p><\/p>\n<p>Hvordan vi skal flytte:<\/p>\n<p><\/p>\n<ul>\n<li>F\u00f8rst m\u00e5 vi forberede biblioteket for \u00e5 arbeide med klyngen. Som grunnlag for versjonen i Go har vi tatt go-redis og tilpasset det litt. Vi implementerte Multi-metoder gjennom pipelines og justerte reglene for gjentakelse av foresp\u00f8rslene. Med PHP-versjonen oppsto det flere problemer, men til slutt har vi landet p\u00e5 php-redis. Nylig har de introdusert st\u00f8tte for klynger, og etter v\u00e5rt syn ser det bra ut.<\/li>\n<li>Deretter m\u00e5 vi sette opp selve klyngen. Dette gj\u00f8res bokstavelig talt med to kommandoer basert p\u00e5 konfigurasjonsfilen. Vi vil diskutere innstillingene mer detaljert nedenfor.<\/li>\n<li>For en gradvis overgang bruker vi dry-mode. Siden vi har to versjoner av biblioteket med identisk grensesnitt (en for vanlig versjon og en for klynge), er det enkelt \u00e5 lage en wrapper som jobber med den separate versjonen og samtidig dupliserer alle foresp\u00f8rslene til klyngen, sammenligner svarene og skriver avvikene i loggene (i v\u00e5rt tilfelle i NewRelic). Dermed, selv om klyngeversjonen bryter ved utrullingen, vil produksjonen v\u00e5r ikke bli ber\u00f8rt. <\/li>\n<li>N\u00e5r vi lanserer klyngen i dry-modus, kan vi rolig se p\u00e5 diagrammet over avvik i svarene. Hvis andelen feil sakte men sikkert beveger seg mot en liten konstant, betyr det at alt er i orden. Hvorfor er det fortsatt avvik? Fordi opptak i den separate versjonen skjer litt tidligere enn i klyngen, og p\u00e5 grunn av mikrologgene kan dataene avvike. Det gjenst\u00e5r bare \u00e5 se p\u00e5 avviksloggene, og hvis alle er forklarlige med hensyn til ikke-atomaritet i opptakene, kan vi g\u00e5 videre.<\/li>\n<li>N\u00e5 kan vi skifte dry-mode tilbake. Vi vil skrive og lese fra klyngen, samtidig som vi dupliserer til den separate versjonen. Hvorfor? I l\u00f8pet av den neste uken \u00f8nsker vi \u00e5 observere hvordan klyngen fungerer. Hvis det viser seg at det er problemer under h\u00f8y belastning, eller vi har oversett noe, har vi alltid en n\u00f8dprosess for \u00e5 g\u00e5 tilbake til gammel kode og aktuelle data takket v\u00e6re dry-mode.<\/li>\n<li>Det gjenst\u00e5r bare \u00e5 deaktivere dry-mode og demontere den separate versjonen. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Ekspertise<\/h1>\n<p><\/p>\n<p>F\u00f8rst en kort oversikt over hvordan klyngen er strukturert.<\/p>\n<p><\/p>\n<p>F\u00f8rst og fremst er Redis et key-value lagringssystem. Vilk\u00e5rlige strenger brukes som n\u00f8kler. Verdiene kan v\u00e6re tall, strenger og komplekse strukturer. Det finnes et stort antall av de siste, men for \u00e5 forst\u00e5 den generelle strukturen er dette ikke viktig.<br \/>\nDet neste niv\u00e5et av abstraksjon etter n\u00f8klene er slottene (SLOTS). Hver n\u00f8kkel tilh\u00f8rer en av 16 383 slots. Inne i hver slot kan det v\u00e6re s\u00e5 mange n\u00f8kler som \u00f8nskes. Dermed deles alle n\u00f8kler opp i 16 383 ikke-overlappende mengder.<br \/>\n<img decoding=\"async\" alt=\"Om flyttingen fra Redis til Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Videre m\u00e5 det v\u00e6re N master-noder i klyngen. Hver node kan betraktes som en separat Redis-instans som vet alt om de andre nodene inne i klyngen. Hver master-node inneholder et visst antall slots. Hver slot tilh\u00f8rer bare \u00e9n master-node. Alle slots m\u00e5 fordeles mellom nodene. Hvis noen slots ikke er fordelt, vil n\u00f8klene som lagres i dem v\u00e6re utilgjengelige. Hver master-node gir mening \u00e5 kj\u00f8re p\u00e5 en separat logisk eller fysisk maskin. Det er ogs\u00e5 viktig \u00e5 huske at hver node kun kj\u00f8rer p\u00e5 \u00e9n kjerne, og hvis du \u00f8nsker \u00e5 kj\u00f8re flere Redis-instanserer p\u00e5 en logisk maskin, m\u00e5 du s\u00f8rge for at de kj\u00f8rer p\u00e5 forskjellige kjerner (vi har ikke pr\u00f8vd dette, men i teorien skal det fungere). I hovedsak gir master-nodene vanlig sharding, og flere master-noder gj\u00f8r det mulig \u00e5 skalere b\u00e5de skrive- og leseforesp\u00f8rslene.<\/p>\n<p><\/p>\n<p>Etter at alle n\u00f8kler er fordelt p\u00e5 slots, og slots er fordelt p\u00e5 master-nodene, kan det legges til et vilk\u00e5rlig antall slave-noder til hver master-node. Inne i hver \u00abmaster-slave\u00bb kobling vil vanlig replikering fungere. Slaver er n\u00f8dvendige for \u00e5 skalere leseforesp\u00f8rslene og for failover i tilfelle masteren svikter.<br \/>\n<img decoding=\"async\" alt=\"Om flyttingen fra Redis til Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La oss n\u00e5 snakke om operasjonene vi helst b\u00f8r kunne utf\u00f8re.<\/p>\n<p><\/p>\n<p>Vi vil kontakte systemet via Redis-CLI. Siden Redis ikke har et enkelt tilgangspunkt, kan de f\u00f8lgende operasjonene utf\u00f8res p\u00e5 hvilken som helst av nodene. Jeg vil spesifisere hver enkelt operasjon med tanke p\u00e5 muligheten for \u00e5 utf\u00f8re den under belastning.<\/p>\n<p><\/p>\n<ul>\n<li>Det f\u00f8rste og viktigste vi trenger: operasjonen cluster nodes. Den returnerer tilstanden til klyngen, viser listen over noder, deres roller, fordelingen av slots osv. Ytterligere informasjon kan f\u00e5s ved hjelp av cluster info og cluster slots.<\/li>\n<li>Det ville v\u00e6re bra \u00e5 kunne legge til og fjerne noder. For dette finnes operasjonene cluster meet og cluster forget. V\u00e6r oppmerksom p\u00e5 at cluster forget m\u00e5 brukes p\u00e5 HVER node, b\u00e5de p\u00e5 mastere og replikaer. Og cluster meet trenger kun kalles p\u00e5 \u00e9n node. Denne forskjellen kan v\u00e6re forvirrende, s\u00e5 det er best \u00e5 bli klar over den f\u00f8r man setter klusteret i drift. \u00c5 legge til en node gj\u00f8res trygt i drift og p\u00e5virker ikke arbeidet til klusteret (noe som er logisk). Hvis du imidlertid planlegger \u00e5 fjerne en node fra klusteret, b\u00f8r du forsikre deg om at det ikke er noen slots igjen (ellers risikerer du \u00e5 miste tilgang til alle n\u00f8klene p\u00e5 denne noden). Fjern heller ikke masteren hvis den har slaver, ellers vil det bli un\u00f8dvendig avstemning for en ny master. Hvis det ikke er noen slots igjen p\u00e5 nodene, er det et lite problem, men hvorfor velge det un\u00f8dvendige, hvis man kan fjerne slavene f\u00f8rst.<\/li>\n<li>Hvis du m\u00e5 tvinge bytte mellom master og slave, kan kommandoen cluster failover brukes. N\u00e5r du kaller denne i drift, m\u00e5 du forst\u00e5 at masteren vil v\u00e6re utilgjengelig under operasjonen. Vanligvis skjer byttet p\u00e5 mindre enn et sekund, men det er ikke atomisk. Du kan forvente at deler av foresp\u00f8rslene til masteren vil feile i l\u00f8pet av denne tiden.<\/li>\n<li>F\u00f8r du fjerner en node fra klyngen, b\u00f8r det ikke v\u00e6re noen slots igjen p\u00e5 den. Det er best \u00e5 omfordele dem med kommandoen cluster reshard. Slots vil bli overf\u00f8rt fra en master til en annen. Hele operasjonen kan ta flere minutter, avhengig av mengden data som overf\u00f8res, men prosessen er trygg og p\u00e5virker ikke driften av klyngen. Dermed kan alle data overf\u00f8res fra en node til en annen selv under belastning, uten \u00e5 bekymre seg for tilgjengeligheten. Imidlertid er det visse nyanser. For det f\u00f8rste er dataoverf\u00f8ring forbundet med en viss belastning p\u00e5 b\u00e5de mottaker- og avsender-noden. Hvis mottakeren allerede er sterkt belastet p\u00e5 prosessoren, b\u00f8r du ikke belaste den med mottak av nye data. For det andre, s\u00e5 snart det ikke er noen slots igjen p\u00e5 master-avsenderen, vil alle dens slaves umiddelbart g\u00e5 over til den masteren hvor disse slotsene ble flyttet. Problemet er at alle disse slave-nodene vil \u00f8nske \u00e5 synkronisere dataene samtidig. Og du er heldig hvis dette er delvis, og ikke full synkronisering. Ta hensyn til dette, og kombiner operasjoner med flytting av slots med \u00e5 frakoble\/flytte slaves. Eller h\u00e5p at du har tilstrekkelig kapasitet.<\/li>\n<li>Hva gj\u00f8r du hvis du oppdager at du har mistet slots under overf\u00f8ringen? Jeg h\u00e5per dette problemet ikke vil ber\u00f8re deg, men hvis det skjer, finnes det en operasjon kalt cluster fix. Den vil tilfeldigvis fordele slotsene p\u00e5 nodene. Jeg anbefaler \u00e5 sjekke hvordan den fungerer ved \u00e5 fjerne en node med fordelte slots fra klyngen f\u00f8rst. Siden data i ufordelte slots allerede er utilgjengelige, er det for sent \u00e5 bekymre seg for tilgangen til disse slotsene. P\u00e5 sin side vil operasjonen ikke p\u00e5virke de fordelte slotsene.<\/li>\n<li>En annen nyttig operasjon er monitor. Den lar deg se hele listen over foresp\u00f8rslene som kommer til noden i sanntid. Dessuten kan du bruke grep p\u00e5 den for \u00e5 finne ut om det er \u00f8nsket trafikk.<\/li>\n<\/ul>\n<p><\/p>\n<p>Det er ogs\u00e5 viktig \u00e5 nevne prosedyren for n\u00f8dovergang til master. Kort sagt er det en prosedyre, og etter min mening fungerer den utmerket. Men man skal ikke tro at hvis man trekker ut stikkontakten fra maskinen med master-noden, vil Redis umiddelbart overta og kundene ikke vil merke noen avbrudd. Etter min erfaring tar det flere sekunder f\u00f8r overgangen skjer. I l\u00f8pet av denne tiden vil deler av dataene v\u00e6re utilgjengelige: masterens utilgjengelighet oppdages, nodene stemmer over ny, slaver byttes over, og data synkroniseres. Den beste m\u00e5ten \u00e5 sikre seg om at systemet fungerer, er \u00e5 gjennomf\u00f8re lokale \u00f8velser. Sett opp en klynge p\u00e5 din b\u00e6rbare PC, gi minimal last, simuler et nedbrudd (for eksempel ved \u00e5 blokkere porter), og evaluer overgangen. Etter min mening kan man f\u00f8rst v\u00e6re sikker p\u00e5 teknologiens funksjonalitet etter \u00e5 ha lekt med det i en dag eller to. Eller h\u00e5pe p\u00e5 at programvaren som brukes av halve internett, fungerer som den skal.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Konfigurasjon<\/h1>\n<p><\/p>\n<p>Som regel er konfigurasjonen det f\u00f8rste man trenger for \u00e5 begynne \u00e5 bruke verkt\u00f8yet. Og n\u00e5r alt er oppe og g\u00e5r, \u00f8nsker man ikke \u00e5 r\u00f8re konfigurasjonen. Det kreves spesifikke anstrengelser for \u00e5 tvinge seg selv tilbake til innstillingene og g\u00e5 dem grundig igjennom. Etter min erfaring har vi hatt minst to alvorlige feil p\u00e5 grunn av uoppmerksomhet mot konfigurasjonen. V\u00e6r spesielt oppmerksom p\u00e5 f\u00f8lgende punkter:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>Tiden det tar f\u00f8r inaktive forbindelser lukkes (i sekunder). 0 \u2014 lukkes ikke<\/em><br \/>\nIkke alle v\u00e5re biblioteker var i stand til \u00e5 lukke forbindelser riktig. Ved \u00e5 deaktivere denne innstillingen risikerer vi \u00e5 n\u00e5 grensen for antall klienter. P\u00e5 den annen side, hvis et slikt problem eksisterer, vil automatisk brudd av tapte forbindelser maskere det, og vi kan g\u00e5 glipp av det. Videre b\u00f8r man ikke aktivere denne innstillingen n\u00e5r man bruker persist-forbindelser.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Lagring av RDB-snapshot.<\/em><br \/>\nProblemer knyttet til RDB\/AOF vil vi diskutere i detalj nedenfor.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>Hvis aktivert, vil master slutte \u00e5 ta imot endringsforesp\u00f8rsel ved et RDB-snapshot-feil. Hvis forbindelsen til master er tapt, kan slaven fortsette \u00e5 svare p\u00e5 foresp\u00f8rsel (yes). Eller slutte \u00e5 svare (no)<\/em><br \/>\nVi er ikke komfortable med situasjonen der Redis blir til en gresskar.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>I l\u00f8pet av denne tidsperioden vil vi begynne \u00e5 bekymre oss for at masteren er brutt sammen og at vi b\u00f8r utf\u00f8re en failover-prosedyre.<\/em><br \/>\nVi m\u00e5 manuelt finne balansen mellom falske alarmer og utl\u00f8sing av failover. I v\u00e5r erfaring tar dette 5 sekunder.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>Slik mengde data kan vi lagre i bufferet for en avvikende replika. Hvis bufferet fylles opp, m\u00e5 vi synkronisere helt.<\/em><br \/>\nErfaringen tilsier at det er bedre \u00e5 sette verdien litt h\u00f8yere. Det finnes flere grunner til at en replika kan begynne \u00e5 henge etter. Hvis den henger etter, er det sannsynlig at masteren din allerede sliter, og full synkronisering vil bli dr\u00e5pen som f\u00e5r begeret til \u00e5 renne over.<\/li>\n<li>maxclients 10000<br \/>\n<em>Det maksimale antallet samtidige klienter.<\/em><br \/>\nIf\u00f8lge v\u00e5r erfaring er det bedre \u00e5 sette verdien h\u00f8yere. Redis klarer seg fint med 10 000 tilkoblinger. Bare s\u00f8rg for at systemet har nok sokler. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>Reglene for hvordan n\u00f8kler blir fjernet n\u00e5r grensen for tilgjengelig minne n\u00e5s.<\/em><br \/>\nHer er det viktigere ikke selve regelen, men forst\u00e5elsen av hvordan dette vil skje. Redis kan roses for dets evne til \u00e5 fungere godt n\u00e5r minnegrensen n\u00e5s. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">Problemer med RDB og AOF<\/h1>\n<p><\/p>\n<p>Selv om Redis lagrer all informasjon i RAM, finnes det ogs\u00e5 mekanismer for \u00e5 lagre data p\u00e5 disk. N\u00e6rmere bestemt finnes det tre mekanismer:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 et fullt snapshot av all data. Settes opp med konfigurasjonen SAVE X Y og leses som \"Lagre et fullstendig snapshot av alle data hvert X sekunder, hvis minst Y n\u00f8kler har blitt endret.\"<\/li>\n<li>Append-only file \u2014 en liste over operasjoner i rekkef\u00f8lge etter utf\u00f8relse. Legger til nye ankomne operasjoner til filen hvert X sekunder eller hver Y operasjoner.<\/li>\n<li>RDB og AOF \u2014 en kombinasjon av de to forrige.<\/li>\n<\/ul>\n<p><\/p>\n<p>Alle metodene har sine fordeler og ulemper, jeg vil ikke liste dem alle, men vil bare p\u00e5peke det som, etter min mening, ikke er s\u00e5 \u00e5penbare punkter.<\/p>\n<p><\/p>\n<p>For det f\u00f8rste, for \u00e5 lagre en RDB-snapshot kreves det \u00e5 kalle FORK. Hvis det er mye data, kan dette hengslet hele Redis i en periode fra noen millisekunder til ett sekund. I tillegg m\u00e5 systemet allokere minne til et slikt snapshot, noe som f\u00f8rer til behovet for \u00e5 ha en dobbel reserve av RAM p\u00e5 den logiske maskinen: hvis 8 GB er tildelt Redis, m\u00e5 det v\u00e6re tilgjengelig 16 GB p\u00e5 den virtuelle maskinen.<\/p>\n<p><\/p>\n<p>For det andre er det problemer med delvis synkronisering. I AOF-modus kan det, ved gjenoppretting av slave, utf\u00f8res en fullstendig synkronisering i stedet for delvis. Hvorfor dette skjer, klarte jeg ikke \u00e5 forst\u00e5. Men det er verdt \u00e5 huske p\u00e5.<\/p>\n<p><\/p>\n<p>Disse to punktene f\u00e5r oss allerede til \u00e5 tenke p\u00e5 om vi virkelig trenger disse dataene p\u00e5 disk, n\u00e5r de allerede er duplisert av slavene. Data kan bare g\u00e5 tapt dersom alle slavene svikter, og det er et problem av \"brann i datasenteret\"-niv\u00e5. Som et kompromiss kan man foresl\u00e5 \u00e5 lagre data kun p\u00e5 slavene, men i s\u00e5 fall m\u00e5 man s\u00f8rge for at disse slavene aldri blir master ved n\u00f8dgjenoppretting (det finnes en innstilling for prioritering av slaver i deres konfigurasjon). I hvert enkelt tilfelle vurderer vi om vi skal lagre data p\u00e5 disk, og vi svarer oftest \"nei\".<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Konklusjon<\/h1>\n<p><\/p>\n<p>Avslutningsvis h\u00e5per jeg jeg har gitt en generell oversikt over hvordan redis-cluster fungerer til de som aldri har h\u00f8rt om det, og ogs\u00e5 p\u00e5pekt noen ikke-\u00e5penbare punkter for de som allerede har brukt det en stund.<br \/>\nTakk for tiden din, og som alltid er kommentarer om emnet velkomne.<\/p>\n<p>Kilde: <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.5 - 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\/no\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\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\/no\/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\udd47Om flyttingen fra Redis til Redis-cluster | ProHoster","description":"Kommer inn i et produkt som utvikler seg mer.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}