Sådan forstår du Redis-replikationsbacklog: PSYNC, størrelse og HA-grænser

Der Redis-replikationsbacklog er med til at bestemme, om en replika efter et forbindelsesbrud kun henter de manglende ændringer eller får overført hele datamængden på ny. Hvis man dimensionerer bufferen efter det faktiske replikeringsvolumen, kan man undgå unødvendige fuldstændige synkroniseringer. Til gengæld skal replikeringshistorikken, lagerbudgettet og driftsprocesserne også passe sammen: Et stort efterslæb kan hverken erstatte persistens eller et robust failover-koncept.

Hvad backloggen rent faktisk gemmer

Med Redis-replikering Primærserveren behandler ændringer i databasen og sender en løbende strøm af kommandoer til sine replikaer. Dette omfatter ikke kun værdier, der skrives direkte fra klienter. Også udløbne eller overskrevne nøgler kan udløse ændringer, som skal videregives. Backloggen opbevarer et begrænset, nyere udsnit af denne replikeringsstrøm i arbejdshukommelsen. Den indeholder derfor ingen yderligere fuldstændig kopi af databasen og er heller ikke et arkiv over vilkårligt gamle skriveoperationer.

Under problemfri drift følger replikaerne den løbende strøm. Hvis en forbindelse afbrydes, vokser historikken på primærserveren videre. Når forbindelsen er genoprettet, forsøger replikaen at fortsætte fra det sted, den var nået til. Det afgørende er da, om de nødvendige bytes stadig er gemt. Er det tilfældet, og stemmer replikeringshistorikken overens, kan Redis udfylde hullet. De data, der allerede findes på replikaen, behøver ikke at blive erstattet fuldstændigt.

Fordelen kommer især til udtryk ved korte netværksforstyrrelser, skift af forbindelse og planlagte vedligeholdelsesarbejder. En fuldstændig synkronisering af en stor datamængde kræver overførselskapacitet og regnekraft; afhængigt af konfigurationen kommer der yderligere belastninger på lagerplads og datamedier oveni. Backloggen kan reducere denne arbejdsbyrde, men kan ikke opfange alle former for afbrydelser. En genstart af processen eller en ændret historik kræver en anden tilgang end en kortvarigt afbrudt TCP-forbindelse.

Hvornår er PSYNC tilstrækkeligt, og hvornår er en fuld resync nødvendig?

En Delvis resynkronisering med PSYNC kræver to oplysninger, der hører sammen: replikerings-ID’et og offset. ID’et identificerer en bestemt datahistorik. Offset beskriver en byteposition inden for replikeringsstrømmen. To offsets af samme størrelse fra forskellige historikker er derfor ikke automatisk sammenlignelige. Omvendt kan et lille efterslæb i den samme historik allerede ligge uden for den tilgængelige backlog, hvis dens kapacitet er begrænset.

Kort sagt meddeler replikaen ved genopkoblingen, hvor langt den er nået. Primærserveren kontrollerer, om den kan levere de data, der derefter er nødvendige. Hvis historikken er ukendt, eller hvis den nødvendige del mangler, oprettes der en Fuld synkronisering nødvendigt. Her modtager replikaen en komplet datamængde og derefter de ændringer, der er opstået under synkroniseringen. Overførslen kan, afhængigt af konfigurationen, foregå med et mellemliggende RDB-trin til et datamedie eller uden dette mellemliggende trin.

Efter en failover er en fuld resynkronisering ikke altid uundgåelig. En flyttet replika kan desuden huske det tidligere replikerings-ID og dets gyldige offset-interval. Dermed kan yderligere replikaer, under de rette forudsætninger, fortsætte fra den kendte historik. Dette giver dog ingen garanti i forbindelse med planlægningen: Det relevante område skal fortsat være tilgængeligt, og den konkrete genopkobling skal stemme overens med de gemte ID'er.

Måling af replikeringshastighed i stedet for at estimere databasestørrelsen

Alene datamængden er tilstrækkelig til at Dimensionering af ordrebeholdningen ikke. En stor database, der hovedsageligt læses, genererer kun lidt replikeringstrafik. En lille cache med hyppigt skiftende værdier og mange udløsningshændelser kan derimod løbende overføre betydelige datamængder. Selv et fast antal operationer pr. sekund beskriver ikke den nødvendige lagerplads tilstrækkeligt: Små nøgleændringer og store værdioverskrivninger medfører ikke samme byteomfang.

En praktisk anvendelig tilnærmelse kan udledes af den tidsmæssige stigning i master_repl_offset. Registrer værdien to gange på den samme primærserver, og divider forskellen med det forløbne antal sekunder. Kontroller samtidig replikerings-ID’et. Efter et rolleskift eller en genstart må du ikke blot trække to uafhængige målepunkter fra hinanden. Et enkelt måleinterval giver desuden kun en gennemsnitlig hastighed inden for dette interval, ikke en permanent garanteret øvre grænse.

Følgende forespørgsel læser diagnostiske oplysninger. Den ændrer ikke Redis-konfigurationen. Udfør den med de forbindelses- og godkendelsesindstillinger, der kræves i dit miljø. Det nedenfor viste opkald bruger standardforbindelsen fra redis-cli; en anden host, port eller TLS-adgang skal udtrykkeligt indstilles.

redis-cli INFO replication

Mål belastningen på tværs af forskellige belastningsfaser, f.eks. i den daglige drift, ved import og under større cache-opdateringer. Dokumenter både typiske værdier og korte spidsbelastninger. Hvis der opstår mange ændringer som følge af udløbne nøgler, kan den interne artikel give en mere dybdegående indsigt i emnet Analyse af udløb af Redis-nøgler. Denne sammenhæng er vigtig for planlægningen, fordi ikke alle relevante skriveimpulser umiddelbart udspringer af en ny brugerforespørgsel.

Beregne størrelsen af ordrebestanden på en gennemsigtig måde

Som Planlægningsmetode kan du gange den relevante replikeringshastighed med den afbrydelsestid, der skal dækkes, og derefter tilføje en rimelig reserve. Varigheden bør ikke kun tage højde for selve netværksafbrydelsen. Også detektering, genopkoblingsforsøg og genoprettelse af forbindelsesvejen kan tage tid. Hvilken reserve der er passende, afhænger af observerede udsving og det ønskede driftsmål, ikke af en universel procentdel.

Et bevidst forenklet regneeksempel: For en given belastningsfase antager du 12 MiB pr. sekund. Forbindelsen kan være nede i 90 sekunder; der indregnes yderligere 30 sekunder som tidsreserve. Heraf følger 12 MiB/s × 120 s = 1.440 MiB, altså cirka 1,41 GiB. Disse tal er kun eksempler til forklaring og ikke en Redis-benchmark. Inden idriftsættelse skal de erstattes med måleværdier fra din applikation.

Den omvendte beregning hjælper med at vurdere en eksisterende buffer. En fuldt fyldt backlog på 256 MiB svarer teoretisk set til ca. 21 sekunders historik, hvis hastigheden forbliver konstant på 12 MiB pr. sekund. Ved 2 MiB pr. sekund ville det være ca. 128 sekunder. I en reel anvendelse varierer hastighederne dog. En sådan rækkevidde er derfor et øjebliksbillede og ikke en garanti for, at enhver forstyrrelse af denne varighed kan synkroniseres delvist.

Kontroller desuden, om replikaen efter genopkoblingen kan indhente forsinkelsen hurtigere, end der opstår nye ændringer. Mere historik løser hverken et vedvarende for langsomt netværk eller en vedvarende overbelastet modtager. Hvis forsinkelsen fortsætter eller vokser yderligere, skal årsagen undersøges. At afsætte stadig mere lagerplads vil ellers blot udskyde problemet og kan sætte hele systemet under pres med hensyn til lagerplads.

Sådan ændrer du Redis-konfigurationen på en forståelig og kontrolleret måde

Parametrene repl-backlog-size og repl-backlog-ttl styrer forskellige ting. Den første beskriver den forventede størrelse af backloggen. Den anden bestemmer på primærserveren, efter hvor lang tid uden tilsluttede replikaer backloggen kan frigives. Den er ingen maksimal afbrydelsestid for PSYNC. Så længe bufferen overskrives, eller en anden forudsætning ikke er opfyldt, hjælper en lang TTL i sig selv ikke.

De følgende linjer stammer fra den kommenterede standardkonfiguration i Redis 7.2.0. Kommentartegnene er bevidst bibeholdt. En simpel kopiering af disse linjer aktiverer ikke nogen indstillinger; desuden udgør de angivne værdier ikke en generel kapacitetsanbefaling til produktionssystemer.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

Med repl-backlog-ttl 0 Deaktiveres den tidsstyrede frigivelse, når alle replikaer er afbrudt. Dette bevarer ikke en ubegrænset historik: Den eksisterende buffer kan fortsat overskrives af nye replikeringsdata. Det medfører heller ikke nogen persistens på tværs af eventuelle genstarter af processen. Vurder derfor nøje, om det ekstra hukommelsesforbrug passer til den forventede genforbindelsesadfærd.

Inden du foretager en ændring, bør du kontrollere de faktisk gældende værdier og afklare implementeringsproceduren. En container-miljøvariabel, en administreret konfigurationsfil og en indstilling, der ændres under kørsel, er ikke det samme. Hvis en instans senere genoprettes, kan kun de justeringer, der er foretaget under kørsel, gå tabt. Følgende forespørgsler er skrivebeskyttede; de kræver dog stadig de relevante adgangsrettigheder.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

Med Managed Redis kan udbyderen begrænse adgangen til CONFIG begrænse eller administrere indstillinger via en egen brugergrænseflade. Det er ingen grund til at omgå beskyttelsesmekanismerne. Brug i så fald de godkendte administrationsveje, og dokumentér den valgte størrelse sammen med det underliggende replikeringsvolumen. I ændringsplanen bør desuden de hidtidige værdier og en realistisk tilbageførsel fastlægges.

Overvågning: Hvilke værdier hører sammen

For Overvågning af Redis-replikering Er en enkelt grøn forbindelsesstatus ikke tilstrækkelig. En forbindelse kan være genoprettet, mens replikaen stadig er i gang med at indhente forsinkelsen eller netop er ved at indlæse et komplet datasæt. Omvendt behøver et kortvarigt forbindelsesafbrud ikke umiddelbart at være kritisk, hvis historikken og indhentningskapaciteten er tilstrækkelig. Vurder derfor forbindelsen, synkroniseringsstatus, udviklingen i forsinkelsen og den tilgængelige historik samlet.

Felterne i en INFO-Svarene kan variere mellem forskellige Redis-versioner og mellem primær og replika. En analyse bør derfor udtrykkeligt tage højde for manglende felter i stedet for stiltiende at fortolke dem som null eller som en fejlfri tilstand. Også betegnelserne master og slave forekommer fortsat i feltnavne af kompatibilitetshensyn; de må ikke oversættes frit i den eksekverbare kode.

Den interne vejledning er afgørende for fortolkningen af restmængden Analyse af Redis-replikeringsoffset et passende supplement. I den løbende overvågning bør du se på historiske forløb, ikke blot to tal, der er aflæst manuelt. En voksende afstand kræver en anden reaktion end et hul, der stadigt mindskes efter et kort udfald.

Meningsfulde alarmer tager udgangspunkt i dine driftsmål: Hvor længe må en replika være utilgængelig? Hvor hurtigt skal den indhente det forsømte? Hvilken hyppighed af fuldstændige synkroniseringer er usædvanlig? Faste grænseværdier uden hensyn til belastningsprofil og datamængde fører ofte til unødvendige alarmer eller overser reelle forringelser. Hold ud over replikeringsmetrikker også øje med RAM-udnyttelse, netværksudnyttelse og tegn på procesgenstarter.

Hvordan man korrekt vurderer lagerbudget og langsomme replikaer

Ordrereserven udgør kun en del af det samlede Redis-hukommelsesbehov. Hertil kommer datamængden, administrationsstrukturerne, klientbufferen og, afhængigt af driftsstatus, yderligere hukommelse under persistens- eller synkroniseringsopgaverne. Planlæg derfor ikke hele den tilgængelige arbejdshukommelse til brugerdata plus et nøjagtigt beregnet efterslæb. Den nødvendige reserve skal udledes af det konkrete miljø og de belastningsspidser, der opstår der.

Siden Redis 7.0 deler replikabufferen og replikeringsbackloggen hukommelse. INFO-dokumentationen påpeger derfor blandt andet, at mem_clients_slaves kan være nul, hvis replikabufferne ikke overskrider backlog-belægningen. Det betyder dog ikke, at replikering ikke optager hukommelse. Betragt de værdier, der er angivet til dette formål, som mem_replication_backlog og mem_total_replication_buffers i sammenhængen, og lad være med at lægge overlappende størrelser sammen uden at tænke over det.

En hyppig fejl i diagnosticeringen er at antage, at enhver afbrudt synkronisering skyldes et større efterslæb. Langsomme replikaer, begrænset netværksbåndbredde eller overskredne output-buffergrænser kan have en anden årsag. Parameteren client-output-buffer-limit replica gælder den pågældende klientklasse og må ikke forveksles med repl-backlog-size skal sidestilles. Inden du ændrer grænseværdier, skal du gennemgå logfiler, versionsdokumentation og de forventede konsekvenser for andre forbindelser.

Hvorfor en stor backlog ikke i sig selv garanterer høj tilgængelighed

Backloggen forbedrer genopkoblingen, men gør den som standard asynkrone replikering ikke tabfri. En primærserver kan allerede have bekræftet en skriveoperation over for klienten, før en replik har behandlet den. Hvis den primære server går ned i dette tidsrum, findes den pågældende operation muligvis ikke på det senere valgte erstatningssystem. Bufferstørrelsen alene løser ikke dette problem Risiko for datatab ved failover ikke.

Også WAIT omdanner ikke en Redis-topologi til et system med garanteret stærk konsistens. Kommandoen kan afvente bekræftelser fra replikaer; den faktiske datasikkerhed afhænger fortsat af andre omstændigheder, især af persistens- og failover-adfærd. Ligeledes begrænser min-replicas-to-write og min-replicas-max-lag under deres respektive betingelser at acceptere nye skriveoperationer uden automatisk at gemme hver enkelt operation permanent på flere instanser.

Til Høj tilgængelighed Derfor skal du træffe en samlet beslutning: acceptabelt datatab, tilladt nedetid, persistens, fejldetektion, valg af den nye primære server og gendannelse. Sentinel eller Redis Cluster kan i denne sammenhæng varetage andre opgaver end backloggen. Hvis man blot øger størrelsen på en buffer og lader alle øvrige antagelser forblive uændrede, har man endnu ikke en robust genopstartsplan.

Teste ændringer og indkredse tilbagevendende problemer

Start en kontrolleret test i et isoleret miljø med en tilsvarende Redis-version og en forudsigelig skrivebelastning. Notér replikations-ID’er, offsets, backlog-belægning og hukommelsesforbrug inden afbrydelsen. Simuler derefter en begrænset forbindelsesafbrydelse uden at ændre produktive firewalls eller processer uden forudgående kontrol. Efter genopkoblingen observerer du, om der finder en delvis eller fuldstændig synkronisering sted, og hvor lang tid det tager at indhente det forsømte.

Ændr om muligt kun én relevant variabel pr. forsøg. Hvis backlog, skrivebelastning og netværksforhold ændrer sig samtidigt, er det næsten umuligt at fastslå årsagen til effekten. Gentag forsøget med forskellige afbrydelsestider og forskellige belastningsfaser. På den måde bliver en enkelt vellykket genopkobling til en forståelig vurdering af systemets adfærd. De observerede grænser bør dokumenteres, uden at man udleder en garanti for enhver fremtidig forstyrrelse heraf.

Ved gentagne fuldstændige resynkroniseringer skal du først kontrollere, om historikken overhovedet er kompatibel. Derefter følger de resterende bytes, tiden uden replika, oplysninger om genstarter og den faktiske indhentningshastighed. En for lille buffer er en mulig årsag, men ikke den eneste. Det er især vigtigt at skelne mellem et engangsafbrud, der varer for længe, og en replika, der konstant halter bagefter, selv når der er forbindelse.

Den rigtige indstilling er i sidste ende den, der dækker dit definerede nedbrudsvindue under realistisk belastning og efterlader tilstrækkelig hukommelse til den øvrige drift. Notér målegrundlaget, konfigurationskilden og testdatoen samlet. Efter større ændringer i skriveadfærd, topologi eller Redis-version bør dimensioneringen tages op til fornyet vurdering. På den måde forbliver backloggen en velbegrundet driftsbeslutning i stedet for et tal, der blot er blevet vedtaget én gang.