{"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\/da\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"Om overgangen fra Redis til Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Om overgangen 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 tr\u00e6der ind i et produkt, der har udviklet sig i mere end ti \u00e5r, er det ikke overraskende at m\u00f8de for\u00e6ldede teknologier. Men hvad nu hvis du om et halvt \u00e5r skal h\u00e5ndtere en belastning, der er ti gange h\u00f8jere, og omkostningerne ved nedbrud stiger hundredevis af gange? I s\u00e5 fald har du brug for en dygtig Highload Engineer. Men i mangel af en kvalificeret person, blev problemet mig overdraget. I den f\u00f8rste del af artiklen vil jeg fort\u00e6lle, hvordan vi flyttede fra Redis til Redis-cluster, og i den anden del vil jeg give r\u00e5d om, hvordan man begynder at bruge clusteren, og hvad man skal v\u00e6re opm\u00e6rksom p\u00e5 ved driften.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Valg af teknologi<\/h1>\n<p><\/p>\n<p>Er standalone Redis s\u00e5 d\u00e5rlig? <em>(standalone redis) i konfigurationen 1 master og N slaver? Hvorfor kalder jeg det for en for\u00e6ldet teknologi?<\/em> Nej, Redis er ikke s\u00e5 d\u00e5rligt\u2026 Men der er nogle mangler, som man ikke kan ignorere.<\/p>\n<p><\/p>\n<blockquote><p>For det f\u00f8rste underst\u00f8tter Redis ikke mekanismer til katastrofegenopretning efter nedbrud af masteren. For at l\u00f8se dette problem brugte vi en konfiguration med automatisk omdirigering af VIP'er til en ny master, skift af rolle for en af slaverne, og skift af de \u00f8vrige. Denne mekanisme fungerede, men det kunne ikke kaldes en p\u00e5lidelig l\u00f8sning. For det f\u00f8rste opstod der falske alarmer, og for det andet var den engangsbrug, og efter aktivering kr\u00e6vedes der manuelle handlinger for at nulstille systemet.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>For det andet f\u00f8rte det at have kun \u00e9n master til et sharding-problem. Man var n\u00f8dt til at oprette flere uafh\u00e6ngige klynger med '1 master og N slaver', derefter manuelt fordele databaserne p\u00e5 disse maskiner og h\u00e5be, at en af databaserne ikke ville vokse s\u00e5 meget n\u00e6ste dag, at den skulle flyttes til en separat instans.<\/p>\n<p>\n<\/li>\n<li>\n<p>Hvilke muligheder er der?<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Den dyreste og mest omfattende l\u00f8sning er Redis-Enterprise. Dette er en pakkel\u00f8sning med fuld teknisk support. Selvom det ser ideelt ud fra en teknisk synsvinkel, var det ikke passende for os af ideologiske \u00e5rsager.<\/p>\n<p><\/p>\n<ul>\n<li>Redis-cluster. Der er indbygget support til katastrofeomskiftning af masteren og sharding. Gr\u00e6nsefladen adskiller sig n\u00e6sten ikke fra den almindelige version. Det ser lovende ud, vi vil tale om faldgruberne senere. <\/li>\n<li>Redis-cluster. Der er indbygget underst\u00f8ttelse af failover og sharding. Gr\u00e6nsefladen adskiller sig n\u00e6sten ikke fra den almindelige version. Det ser lovende ud; vi vil tale om faldgruberne senere.<\/li>\n<li>Tarantool, Memcache, Aerospike og andre. Alle disse v\u00e6rkt\u00f8jer g\u00f8r stort set det samme. Men hver har sine egne ulemper. Vi har besluttet ikke at l\u00e6gge alle \u00e6ggene i \u00e9n kurv. Memcache og Tarantool bruger vi til andre opgaver, og jeg vil sige p\u00e5 forh\u00e5nd, at vi har haft flere problemer med dem i vores erfaring.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Specifikationen af anvendelse<\/h1>\n<p><\/p>\n<p>Lad os se p\u00e5, hvilke opgaver vi historisk har l\u00f8st med Redis og hvilken funktionalitet vi har brugt:<\/p>\n<p><\/p>\n<ul>\n<li>Cache f\u00f8r foresp\u00f8rgsler til eksterne tjenester som 2GIS | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"V\u00c6LG DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cache f\u00f8r MYSQL | PHP<br \/>\n<blockquote><p>GET SET MGET MSET SCAN \"N\u00d8GLE EFTER M\u00d8NSTER\" \"V\u00c6LG DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Prim\u00e6rt lager for tjenester, der arbejder med sessioner og chauff\u00f8rers koordinater | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"V\u00c6LG DB\" \"TILF\u00d8J GEO N\u00d8GLE\" \"HENT GEO N\u00d8GLE\" SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Som du kan se, ingen avanceret matematik. Hvad er s\u00e5 kompleksiteten? Lad os se n\u00e6rmere p\u00e5 hver metode.<\/p>\n<p><\/p>\n<p>Metoden<br \/>\nDescription<br \/>\nEgenskaber ved Redis-cluster<br \/>\nL\u00f8sning<\/p>\n<p>GET SET<br \/>\nSkrive\/l\u00e6se n\u00f8gle<\/p>\n<p>MGET MSET<br \/>\nSkrive\/l\u00e6se flere n\u00f8gler<br \/>\nN\u00f8glerne vil v\u00e6re placeret p\u00e5 forskellige noder. F\u00e6rdige biblioteker kan kun udf\u00f8re multi-operationer inden for \u00e9n node.<br \/>\nErstat MGET med pipeline af N GET-operationer<\/p>\n<p>SELECT DB<br \/>\nV\u00e6lg den database, vi vil arbejde med<br \/>\nUnderst\u00f8tter ikke flere databaser<br \/>\nL\u00e6g alt i \u00e9n database. Tilf\u00f8j pr\u00e6fikser til n\u00f8glerne.<\/p>\n<p>SCAN<br \/>\nGennemg\u00e5 alle n\u00f8gler i databasen<br \/>\nDa vi har \u00e9n database, er det for omkostningsfuldt at gennemg\u00e5 alle n\u00f8gler i klyngen.<br \/>\nOprethold invariant inden for \u00e9n n\u00f8gle og udf\u00f8r HSCAN p\u00e5 denne n\u00f8gle. Eller drop helt.<\/p>\n<p>GEO<br \/>\nOperationer med geon\u00f8gle<br \/>\nGeon\u00f8gle bliver ikke sharderet<\/p>\n<p>KEY BY PATTERN<br \/>\nS\u00f8g n\u00f8gle efter m\u00f8nster<br \/>\nDa vi har \u00e9n database, vil vi s\u00f8ge blandt alle n\u00f8gler i klyngen. Meget omkostningsfuldt.<br \/>\nDrop eller oprethold invariant, ligesom i tilf\u00e6lde af SCAN.<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-cluster<\/h1>\n<p><\/p>\n<p>Hvad mister vi, og hvad f\u00e5r vi ved at overg\u00e5 til en klynge?<\/p>\n<p><\/p>\n<ul>\n<li>Ulemper: mister funktionaliteten af flere databaser. \n<ul>\n<li>Hvis vi \u00f8nsker at opbevare logisk ikke-relaterede data i \u00e9n klynge, bliver vi n\u00f8dt til at lave l\u00f8sninger med pr\u00e6fikser. <\/li>\n<li>Mister alle operationer \"pr. database\", som SCAN, DBSIZE, CLEAR DB osv.<\/li>\n<li>Multi-operationer er blevet betydeligt mere komplekse at implementere, da det kan kr\u00e6ve adgang til flere noder.<\/li>\n<\/ul>\n<\/li>\n<li>Fordele: \n<ul>\n<li>Fejltolerance i form af failover til master.<\/li>\n<li>Shardering p\u00e5 Redis-siden.<\/li>\n<li>Atomar dataoverf\u00f8rsel mellem noder uden driftsstop.<\/li>\n<li>Tilf\u00f8jelse og redistribution af kapaciteter og belastninger uden driftsstop.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Jeg vil konkludere, at hvis du ikke har brug for at sikre et h\u00f8jt niveau af fejlretningskapacitet, s\u00e5 er det ikke v\u00e6rd at flytte til et cluster, da det kan v\u00e6re en ikke-triviel opgave. Men hvis man fra starten skal v\u00e6lge mellem en separat version og en cluster-version, s\u00e5 b\u00f8r man v\u00e6lge cluster, da det ikke er ringere og i till\u00e6g vil fjerne en del af dit besv\u00e6r.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Forberedelse til flytning<\/h1>\n<p><\/p>\n<p>Lad os starte med kravene til flytningen:<\/p>\n<p><\/p>\n<ul>\n<li>Den skal v\u00e6re s\u00f8ml\u00f8s. En total nedlukning af servicen i 5 minutter er vi ikke tilfredse med.<\/li>\n<li>Den skal v\u00e6re s\u00e5 sikker og gradvis som muligt. Vi \u00f8nsker at have en vis kontrol over situationen. Vi vil ikke bare smide alt ud p\u00e5 en gang og bede til en tilbageslagsknap.<\/li>\n<li>Minimale datatab under flytningen. Vi forst\u00e5r, at det vil v\u00e6re meget sv\u00e6rt at flytte atomart, s\u00e5 vi accepterer en vis desynkronisering mellem dataene i den normale og cluster-Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Vedligeholdelse af clustret<\/h1>\n<p><\/p>\n<p>F\u00f8r selve flytningen b\u00f8r vi overveje, om vi kan vedligeholde clustret:<\/p>\n<p><\/p>\n<ul>\n<li>Grafer. Vi bruger Prometheus og Grafana til grafikker over CPU-belastning, hukommelsesforbrug, antal klienter, antal GET-, SET-, AUTH-operationer osv.<\/li>\n<li>Ekspertise. Forestil dig, at der i morgen vil v\u00e6re et enormt cluster under dit ansvar. Hvis det g\u00e5r i stykker, kan ingen, undtagen dig, reparere det. Hvis det begynder at h\u00e6nge, vil alle komme til dig. Hvis der skal tilf\u00f8jes ressourcer eller omfordeles belastninger, igen til dig. For ikke at blive gr\u00e5h\u00e5ret ved 25, er det klogt at forudse disse scenarier og teste p\u00e5 forh\u00e5nd, hvordan teknologien vil reagere p\u00e5 forskellige handlinger. Det vil vi tale mere om i afsnittet \u201eEkspertise\u201c.<\/li>\n<li>Overv\u00e5gning og advarsler. N\u00e5r clustret g\u00e5r i stykker, vil man gerne vide det f\u00f8rst. Her har vi begr\u00e6nset os til at advare om, at alle noder returnerer ens oplysninger om clusterets tilstand (ja, der kan v\u00e6re andre tilf\u00e6lde). De \u00f8vrige problemer opdages hurtigere gennem advarsler fra Redis-klientservices.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Flytning<\/h1>\n<p><\/p>\n<p>Hvordan vil vi flytte:<\/p>\n<p><\/p>\n<ul>\n<li>F\u00f8rst og fremmest skal vi forberede biblioteket til at arbejde med klyngen. Som grundlag for versionen i Go har vi taget go-redis og tilpasset den til vores behov. Vi har implementeret Multi-metoder via pipelines, og desuden har vi justeret reglerne for gentagelse af foresp\u00f8rgsler. Med versionen til PHP opstod der flere problemer, men i sidste ende endte vi med php-redis. For nylig implementerede de klyngest\u00f8tte, og efter vores mening ser det godt ud.<\/li>\n<li>Derefter skal klyngen ops\u00e6ttes. Dette g\u00f8res bogstaveligt talt med to kommandoer baseret p\u00e5 konfigurationsfilen. Vi vil diskutere ops\u00e6tningen n\u00e6rmere nedenfor.<\/li>\n<li>Til den gradvise migration bruger vi dry-mode. Da vi har to versioner af biblioteket med samme interface (\u00e9n til den almindelige version, den anden til klyngen), er det ikke sv\u00e6rt at lave en wrapper, der arbejder med den separate version og samtidig dublere alle foresp\u00f8rgsler til klyngen, sammenligne svarene og logge uoverensstemmelser (i vores tilf\u00e6lde i NewRelic). Dermed, selvom klyngeversionen fejler ved udrulning, vil vores produktion ikke blive ramt. <\/li>\n<li>N\u00e5r vi ruller klyngen ud i dry-mode, kan vi roligt se p\u00e5 grafen for uoverensstemmelser i svarene. Hvis fejlprocenten langsomt, men sikkert bev\u00e6ger sig mod en lille konstant, er alt i orden. Hvorfor er der stadig uoverensstemmelser? Fordi optegnelsen i den separate version sker lidt tidligere end i klyngen, og p\u00e5 grund af mikrolag kan dataene divergere. Vi skal blot se p\u00e5 loggene for uoverensstemmelser, og hvis alle kan forklares med ikke-atomariteten af optegnelsen, kan vi g\u00e5 videre.<\/li>\n<li>Nu kan vi skifte dry-mode tilbage. Vi vil skrive og l\u00e6se fra klyngen og dublere til den separate version. Hvorfor? I l\u00f8bet af den kommende uge \u00f8nsker vi at observere klyngens drift. Hvis det viser sig, at der er problemer ved spidsbelastning, eller hvis vi har overset noget, har vi altid en n\u00f8dnedrulning til den gamle kode og aktuelle data takket v\u00e6re dry-mode.<\/li>\n<li>Til sidst skal vi deaktivere dry-mode og afmontere den separate version. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Ekspertise<\/h1>\n<p><\/p>\n<p>F\u00f8rst en kort beskrivelse af klyngens opbygning.<\/p>\n<p><\/p>\n<p>F\u00f8rst og fremmest er Redis et key-value lager. Som n\u00f8gle anvendes vilk\u00e5rlige strenge. Som v\u00e6rdier kan der anvendes tal, strenge og hele strukturer. Der er et v\u00e6ld af sidstn\u00e6vnte, men for at forst\u00e5 den overordnede struktur er det ikke vigtigt.<br \/>\nDet n\u00e6ste abstraheringsniveau efter n\u00f8glerne er slots (SLOTS). Hvert slot tilh\u00f8rer en af de 16.383 slots. Inden for hvert slot kan der v\u00e6re et vilk\u00e5rligt antal n\u00f8gler. Dermed opdeles alle n\u00f8gler i 16.383 ikke-overlappende m\u00e6ngder.<br \/>\n<img decoding=\"async\" alt=\"Om overgangen 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>Derudover skal der v\u00e6re N master-noder i klyngen. Hver node kan betragtes som en separat Redis-instans, der kender alt til de andre noder i klyngen. Hver master-node indeholder et bestemt antal slots. Hvert slot tilh\u00f8rer kun \u00e9n master-node. Alle slots skal fordeles mellem noderne. Hvis nogle slots ikke er fordelt, vil de n\u00f8gler, der er gemt i dem, v\u00e6re utilg\u00e6ngelige. Det giver mening at k\u00f8re hver master-node p\u00e5 en separat logisk eller fysisk maskine. Det er ogs\u00e5 v\u00e6rd at huske, at hver node kun k\u00f8rer p\u00e5 \u00e9n kerne, og hvis du vil k\u00f8re flere Redis-instanser p\u00e5 \u00e9n logisk maskine, s\u00e5 s\u00f8rg for, at de k\u00f8rer p\u00e5 forskellige kerner (vi har ikke pr\u00f8vet dette, men i teorien skulle det fungere). Grundl\u00e6ggende sikrer master-noder almindelig sharding, og et st\u00f8rre antal master-noder muligg\u00f8r skalering af skrive- og l\u00e6seanmodninger.<\/p>\n<p><\/p>\n<p>N\u00e5r alle n\u00f8gler er fordelt p\u00e5 slots, og slots er fordelt p\u00e5 master-noder, kan der tilf\u00f8jes et vilk\u00e5rligt antal slave-noder til hver master-node. Inden for hver s\u00e5dan \u2018master-slave\u2019-binding vil der v\u00e6re normal replikation. Slaverne er n\u00f8dvendige for at skalere l\u00e6seanmodninger og til failover i tilf\u00e6lde af, at masteren fejler.<br \/>\n<img decoding=\"async\" alt=\"Om overgangen 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>Lad os nu tale om de operationer, som vi helst skal kunne udf\u00f8re.<\/p>\n<p><\/p>\n<p>Vi vil have adgang til systemet gennem Redis-CLI. Da Redis ikke har et enkelt indgangspunkt, kan de f\u00f8lgende operationer udf\u00f8res p\u00e5 hvilken som helst af noderne. I hvert punkt vil jeg specifikt p\u00e5pege muligheden for at udf\u00f8re operationen under belastning.<\/p>\n<p><\/p>\n<ul>\n<li>Den f\u00f8rste og vigtigste, vi har brug for: operationen cluster nodes. Den returnerer tilstanden af klyngen, viser listen over noder, deres roller, fordelingen af slots osv. Yderligere oplysninger kan f\u00e5s med cluster info og cluster slots.<\/li>\n<li>Det ville v\u00e6re godt at kunne tilf\u00f8je og fjerne noder. Dette kan g\u00f8res med operationerne cluster meet og cluster forget. Bem\u00e6rk, at cluster forget skal anvendes p\u00e5 HVER nod, b\u00e5de mestre og replikaer. Cluster meet skal derimod kun kaldes p\u00e5 \u00e9n nod. Denne forskel kan v\u00e6re forvirrende, s\u00e5 det er bedst at l\u00e6re om den, f\u00f8r man s\u00e6tter klyngen i drift. At tilf\u00f8je en nod kan udf\u00f8res sikkert under drift og p\u00e5virker ikke klyngens funktion (hvilket giver mening). Hvis du derimod planl\u00e6gger at fjerne en nod fra klyngen, skal du sikre dig, at der ikke er resterende slots p\u00e5 den (ellers risikerer du at miste adgangen til alle n\u00f8gler p\u00e5 den nod). Fjern heller ikke en master, der har slaves, ellers vil der blive gennemf\u00f8rt en un\u00f8dvendig afstemning om en ny master. Hvis der ikke allerede er slots p\u00e5 noderne, er det et lille problem, men hvorfor tage un\u00f8dvendige valg, hvis man f\u00f8rst kan fjerne slaves.<\/li>\n<li>Hvis du n\u00f8dvendigvis skal bytte master og slave, kan du bruge kommandoen cluster failover. N\u00e5r du kalder den under drift, skal du v\u00e6re opm\u00e6rksom p\u00e5, at mesteren vil v\u00e6re utilg\u00e6ngelig under operationens udf\u00f8relse. Normalt sker skiftet p\u00e5 mindre end et sekund, men ikke atomart. Du kan forvente, at nogle foresp\u00f8rgsler til mesteren i denne periode vil fejle.<\/li>\n<li>F\u00f8r du fjerner en node fra klyngen, m\u00e5 der ikke v\u00e6re nogen slots tilbage. Det er bedst at omfordele dem med kommandoen cluster reshard. Slots vil blive flyttet fra en master til en anden. Hele operationen kan tage flere minutter, afh\u00e6ngigt af m\u00e6ngden af flyttede data; men overf\u00f8rselsprocessen er sikker og p\u00e5virker ikke klyngens drift. P\u00e5 den m\u00e5de kan alle data flyttes fra \u00e9n node til en anden, selv under belastning, og der beh\u00f8ver ikke v\u00e6re bekymringer om deres tilg\u00e6ngelighed. Der er dog nogle detaljer. For det f\u00f8rste medf\u00f8rer dataoverf\u00f8rslen en vis belastning p\u00e5 b\u00e5de afsender- og modtager-noden. Hvis modtager-noden allerede er meget belastet CPU-m\u00e6ssigt, b\u00f8r du ikke belaste den yderligere med modtagelse af nye data. For det andet, s\u00e5 snart der ikke er nogen slots tilbage p\u00e5 afsender-masteren, vil alle dens slaver straks skifte til den master, som disse slots er blevet flyttet til. Problemet er, at alle disse slaver vil fors\u00f8ge at synkronisere data p\u00e5 \u00e9n gang. Du kan v\u00e6re heldig, hvis det kun er en delvis og ikke en fuld synkronisering. Tag dette i betragtning, og kombiner operationer for slotflytning og slaver-afbrydelse\/flytning. Eller h\u00e5b p\u00e5, at du har en tilstr\u00e6kkelig buffer.<\/li>\n<li>Hvad skal du g\u00f8re, hvis du under flytningen opdager, at du har mistet slots? Jeg h\u00e5ber, dette problem ikke rammer dig, men hvis det g\u00f8r, findes der en operation cluster fix. Den vil fordele slots over noderne i tilf\u00e6ldig r\u00e6kkef\u00f8lge. Jeg anbefaler at teste dens funktion ved f\u00f8rst at fjerne en node med fordelte slots fra klyngen. Da dataene i de ufordelte slots allerede ikke er tilg\u00e6ngelige, er det for sent at bekymre sig om tilg\u00e6ngelighedsproblemer med disse slots. P\u00e5 den anden side vil operationen ikke p\u00e5virke de fordelte slots.<\/li>\n<li>En anden nyttig operation er monitor. Den giver dig mulighed for i realtid at se hele listen over anmodninger, der g\u00e5r til noden. Desuden kan du lave grep p\u00e5 den og finde ud af, om den \u00f8nskede trafik er til stede.<\/li>\n<\/ul>\n<p><\/p>\n<p>Det er ogs\u00e5 v\u00e6rd at n\u00e6vne proceduren for fejloverf\u00f8rsel af masteren. Kort sagt, den findes, og efter min mening fungerer den glimrende. Men man skal ikke tro, at hvis man tager stikket ud af stikkontakten p\u00e5 en maskine med master-noden, s\u00e5 vil Redis straks skifte, og kunderne vil ikke bem\u00e6rke tabet. I min erfaring tager det nogle sekunder at skifte. I denne periode vil nogle data v\u00e6re utilg\u00e6ngelige: masterens utilg\u00e6ngelighed opdages, noderne stemmer om en ny, slavene skifter, data synkroniseres. Den bedste m\u00e5de at sikre sig selv, at skemaet fungerer, er at gennemf\u00f8re lokale \u00f8velser. Ops\u00e6t et klynge p\u00e5 din b\u00e6rbare computer, giv minimal belastning, simul\u00e9r et nedbrud (for eksempel ved at blokere porte), og vurd\u00e9r skiftets hastighed. Efter min mening kan man kun v\u00e6re sikker p\u00e5 teknologiens funktion ved at eksperimentere p\u00e5 denne m\u00e5de i en dag eller to. Eller man kan h\u00e5be, at softwaren, som halvdelen af internettet bruger, helt sikkert fungerer.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Konfiguration<\/h1>\n<p><\/p>\n<p>Ofte er konfigurationen det f\u00f8rste, man skal have p\u00e5 plads for at begynde at arbejde med v\u00e6rkt\u00f8jet. N\u00e5r alt virker, er det fristende ikke at r\u00f8re ved konfigurationen. Der kr\u00e6ves en bestemt indsats for at tvinge sig selv til at vende tilbage til indstillingerne og grundigt gennemg\u00e5 dem. Efter min hukommelse har vi haft mindst to alvorlige fiaskoer p\u00e5 grund af uforsigtighed med konfigurationen. V\u00e6r is\u00e6r opm\u00e6rksom p\u00e5 f\u00f8lgende punkter:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>Den tid, hvorefter inaktive forbindelser lukkes (i sekunder). 0 \u2014 lukker ikke.<\/em><br \/>\nIkke hver af vores biblioteker kunne korrekt lukke forbindelser. Ved at deaktivere denne indstilling risikerer vi at ramme gr\u00e6nsen for antallet af klienter. P\u00e5 den anden side, hvis der er et s\u00e5dant problem, vil automatisk afslutning af tabte forbindelser skjule det, s\u00e5 vi kan overse det. Desuden b\u00f8r man ikke aktivere denne indstilling ved brug af persist-forbindelser.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Gem RDB-snapshot.<\/em><br \/>\nVi vil diskutere problemerne med RDB\/AOF n\u00e6rmere nedenfor.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>Hvis det er aktiveret, stopper masteren med at modtage \u00e6ndringsforesp\u00f8rgsler ved en fejl i RDB-snapshotet. Hvis forbindelsen til masteren g\u00e5r tabt, kan slaven forts\u00e6tte med at svare p\u00e5 foresp\u00f8rgsler (yes). Eller stoppe med at svare (no).<\/em><br \/>\nVi er ikke tilfredse med en situation, hvor Redis bliver til et gr\u00e6skar.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>Efter denne periode begynder vi at bekymre os om, at masteren er g\u00e5et ned, og det er p\u00e5 tide at udf\u00f8re failover-proceduren.<\/em><br \/>\nVi skal manuelt finde balancen mellem falske alarmer og aktivering af failover. I vores praksis er det 5 sekunder.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>Lige s\u00e5 mange data kan vi opbevare i bufferen for den nedlagte replika. Hvis bufferen er fyldt, skal vi synkronisere fuldst\u00e6ndigt.<\/em><br \/>\nPraksis viser, at det er bedre at s\u00e6tte v\u00e6rdien st\u00f8rre. Der er mange grunde til, at replikaen kan begynde at h\u00e6nge bagud. Hvis den h\u00e6nger bagud, er det sandsynligt, at din master allerede har sv\u00e6rt ved at klare sig, og en fuldst\u00e6ndig synkronisering vil v\u00e6re dr\u00e5ben, der f\u00e5r b\u00e6geret til at flyde over.<\/li>\n<li>maxclients 10000<br \/>\n<em>Det maksimale antal samtidige kunder.<\/em><br \/>\nEfter vores erfaring er det bedre at s\u00e6tte v\u00e6rdien h\u00f8jere. Redis h\u00e5ndterer fint 10.000 forbindelser. S\u00f8rg bare for, at der er nok sockets i systemet. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>Reglen for, hvordan n\u00f8gler slettes, n\u00e5r gr\u00e6nsen for tilg\u00e6ngelig hukommelse n\u00e5s.<\/em><br \/>\nDet vigtige her er ikke selve reglen, men forst\u00e5elsen af, hvordan dette vil ske. Redis kan roses for sin evne til at fungere korrekt, n\u00e5r hukommelsesgr\u00e6nsen 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>Selvom Redis selv opbevarer al information i hukommelsen, er der ogs\u00e5 en mekanisme til at gemme data p\u00e5 disk. Mere specifikt er der tre mekanismer:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 et komplet snapshot af alle data. Dette indstilles via konfigurationen SAVE X Y og l\u00e6ses som \"Gem et fuldt snapshot af alle data hver X sekunder, hvis mindst Y n\u00f8gler er \u00e6ndret.\"<\/li>\n<li>Append-only file \u2014 en liste over operationer i den r\u00e6kkef\u00f8lge, de udf\u00f8res. Tilf\u00f8jer nye operationer til filen hver X sekunder eller hver Y operationer.<\/li>\n<li>RDB og AOF \u2014 en kombination af de to tidligere.<\/li>\n<\/ul>\n<p><\/p>\n<p>Alle metoder har deres fordele og ulemper; jeg vil ikke n\u00e6vne dem alle, men jeg vil gerne p\u00e5pege nogle af de mindre oplagte punkter, efter min mening.<\/p>\n<p><\/p>\n<p>For det f\u00f8rste kr\u00e6ver det at gemme et RDB-snapshot, at der kaldes FORK. Hvis der er mange data, kan dette f\u00e5 hele Redis til at fryse i en periode fra nogle millisekunder til et sekund. Desuden kr\u00e6ver systemet hukommelse til et s\u00e5dant snapshot, hvilket betyder, at man skal have dobbelt s\u00e5 meget RAM til Redis: hvis der er afsat 8 GB til Redis, skal der v\u00e6re 16 GB tilg\u00e6ngeligt p\u00e5 den virtuelle maskine.<\/p>\n<p><\/p>\n<p>For det andet er der problemer med delvis synkronisering. I AOF-tilstand kan der ved genopkobling af en slave udf\u00f8res en fuld synkronisering i stedet for en delvis. Hvorfor dette sker, har jeg ikke kunnet forst\u00e5. Men det er v\u00e6rd at huske p\u00e5.<\/p>\n<p><\/p>\n<p>Disse to punkter f\u00e5r allerede en til at t\u00e6nke over, hvorvidt vi virkelig har brug for disse data p\u00e5 disken, hvis de allerede er duplikeret af slaverne. Man kan kun miste data, hvis alle slaverne fejler, og det er et problem af niveauet 'brand i datacenteret'. Som et kompromis kan man overveje kun at gemme data p\u00e5 slaverne, men i s\u00e5 fald skal man sikre sig, at disse slaver aldrig bliver master ved fejlgendannelse (til dette er der en indstilling for prioritering af slaver i deres konfiguration). I hvert enkelt tilf\u00e6lde overvejer vi, om vi skal gemme data p\u00e5 disken, og vi svarer oftest 'nej'.<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Konklusion<\/h1>\n<p><\/p>\n<p>Afslutningsvis h\u00e5ber jeg, at jeg har givet et overordnet indblik i arbejdet med redis-cluster til dem, der ikke har h\u00f8rt om det f\u00f8r, samt at jeg har p\u00e5peget nogle uvurderlige punkter for dem, der har brugt det i lang tid.<br \/>\nTak for din tid, og som altid 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.3 - 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\/da\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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 overgangen fra Redis til Redis-cluster | ProHoster","description":"Ved at komme ind i et produkt, der udvikler sig mere.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}