Att förstå Redis-replikeringens backlog: PSYNC, storlek och HA-gränser

Der Redis-replikeringens eftersläpning avgör bland annat om en replik, efter ett avbrott i anslutningen, endast hämtar saknade ändringar eller får hela datamängden överförd på nytt. Den som dimensionerar bufferten efter den faktiska replikeringsvolymen kan undvika onödiga fullständiga synkroniseringar. För detta måste dock även replikeringshistoriken, lagringsbudgeten och driftsrutinerna stämma överens: en stor eftersläpning ersätter varken datapersistens eller ett robust failover-koncept.

Vad backloggen faktiskt lagrar

Med Redis-replikering Primärservern bearbetar ändringar i datamängden och skickar en kontinuerlig ström av kommandon till sina repliker. Detta omfattar inte bara värden som skrivs direkt av klienter. Även utgångna eller ersatta nycklar kan utlösa ändringar som måste vidarebefordras. Backloggen lagrar en begränsad, nyare del av denna replikeringsström i arbetsminnet. Den innehåller därför ingen ytterligare fullständig kopia av databasen och är inte heller ett arkiv för hur gamla skrivoperationer som helst.

Vid störningsfri drift följer replikerna den aktuella strömmen. Om en anslutning bryts fortsätter historiken att växa på primärservern. När anslutningen återupprättas försöker repliken ansluta till sin tidigare position. Avgörande är då om de nödvändiga byte fortfarande finns kvar. Om så är fallet och replikeringshistoriken stämmer kan Redis fylla i luckan. De data som redan finns på repliken behöver inte ersättas helt för detta.

Fördelarna är särskilt tydliga vid korta nätverksstörningar, byten av anslutning och planerade underhållsarbeten. En fullständig synkronisering av en stor datamängd kräver överföringskapacitet och datorkraft; beroende på konfigurationen tillkommer dessutom ytterligare belastning på lagringsutrymme och datamedier. Backloggen kan minska denna arbetsinsats, men kan inte hantera alla typer av avbrott. En omstart av processen eller en ändrad historik kräver en annan hantering än en kortvarigt avbruten TCP-anslutning.

När räcker det med PSYNC och när krävs en fullständig synkronisering?

En partiell resynkronisering med PSYNC kräver två uppgifter som hör ihop: replikerings-ID:t och offset. ID:t identifierar en viss datahistorik. Offsetet beskriver en byteposition inom replikeringsströmmen. Två offset av samma storlek från olika historiker är därför inte automatiskt jämförbara. Omvänt kan en liten eftersläpning i samma historik redan ligga utanför den tillgängliga backloggen om dess kapacitet är begränsad.

Enkelt uttryckt rapporterar repliken vid återanslutningen hur långt den har hunnit. Primärservern kontrollerar om den kan tillhandahålla de data som behövs därefter. Om historiken är okänd eller om den nödvändiga delen saknas, sker en Fullständig synkronisering nödvändigt. Replikan får då en fullständig datamängd och därefter de ändringar som skett under synkroniseringen. Överföringen kan, beroende på konfigurationen, ske med ett mellanliggande RDB-steg till datamediet eller utan detta mellanliggande steg.

Efter en failover är en fullständig synkronisering inte alltid oundviklig. En flyttad replik kan dessutom spara det tidigare replikerings-ID:t och dess giltiga offsetintervall. På så sätt kan ytterligare repliker, under lämpliga förutsättningar, ansluta sig till den kända historiken. Detta innebär dock ingen garanti för planeringen: det relevanta området måste fortfarande vara tillgängligt, och den konkreta återanslutningen måste stämma överens med de lagrade ID:n.

Mäta replikeringshastigheten istället för att uppskatta databasens storlek

Enbart datamängdens storlek räcker för att Dimensionering av orderstock inte. En stor databas som huvudsakligen används för läsning kan generera mycket lite replikeringstrafik. En liten cache med värden som ofta ändras och många utgångshändelser kan däremot kontinuerligt överföra betydande datamängder. Även ett fast antal operationer per sekund ger en otillräcklig beskrivning av det minne som krävs: små nyckeländringar och stora värdeskrivningar ger inte samma bytevolym.

En praktiskt användbar approximation kan härledas ur den tidsmässiga ökningen av master_repl_offset. Mät värdet två gånger på samma primärserver och dela skillnaden med antalet förflutna sekunder. Kontrollera även replikerings-ID:t. Efter ett rollbyte eller en omstart får du inte bara subtrahera två mätpunkter som inte hör ihop från varandra. Ett enskilt mätintervall ger dessutom endast en genomsnittlig hastighet inom detta intervall, inte en permanent garanterad övre gräns.

Följande fråga läser ut diagnostisk information. Den ändrar inte Redis-konfigurationen. Kör den med de anslutnings- och autentiseringsinställningar som krävs i din miljö. Anropet nedan använder standardanslutningen från redis-cli; en annan värd, port eller TLS-anslutning måste anges uttryckligen.

redis-cli INFO replication

Mät över olika belastningsfaser, till exempel under den normala dagliga driften, vid import och under större cache-uppdateringar. Dokumentera både typiska värden och korta toppar. Om många ändringar uppstår på grund av nycklar som löper ut kan den interna artikeln vara till hjälp för en djupare inblick i ämnet. Analysera utgångsdatum för Redis-nycklar. Detta sammanhang är viktigt för planeringen, eftersom inte varje relevant skrivimpuls direkt härrör från en ny användarförfrågan.

Beräkna storleken på orderstocken på ett överskådligt sätt

Som Planeringsmetod Du kan multiplicera den relevanta replikeringsfrekvensen med den avbrottsperiod som ska överbryggas och därefter lägga till en rimlig reserv. Varaktigheten bör inte endast ta hänsyn till själva nätverksavbrottet. Även upptäckt, återanslutningsförsök och återställning av anslutningsvägen kan ta tid. Vilken reserv som är lämplig beror på observerade fluktuationer och det önskade driftsmålet, inte på en universell procentsats.

Ett medvetet förenklat räkneexempel: För en viss belastningsfas antar du 12 MiB per sekund. Anslutningen kan vara borta i 90 sekunder; ytterligare 30 sekunder planeras in som tidsreserv. Av detta följer 12 MiB/s × 120 s = 1.440 MiB, det vill säga cirka 1,41 GiB. Dessa siffror är antaganden som används för att förklara och utgör inte någon Redis-prestandatest. Innan de tas i drift måste de ersättas med mätvärden från din applikation.

Den omvända beräkningen hjälper till att sätta in en befintlig buffert i sitt sammanhang. En fullständigt fylld backlog på 256 MiB motsvarar, vid en konstant hastighet på 12 MiB per sekund, teoretiskt sett ungefär 21 sekunders historik. Vid 2 MiB per sekund skulle det vara ungefär 128 sekunder. I en verklig tillämpning varierar dock hastigheterna. En sådan räckvidd är därför en ögonblicksbild och ingen garanti för att varje störning av denna varaktighet kan synkroniseras delvis.

Kontrollera dessutom om repliken, efter att återanslutningen skett, kan hinna ikapp snabbare än nya ändringar uppstår. Att rensa bort mer historik löser varken problemet med ett nätverk som är permanent för långsamt eller en mottagare som är permanent överbelastad. Om eftersläpningen kvarstår eller fortsätter att växa måste orsaken utredas. Att bara tilldela mer lagringsutrymme skjuter bara upp problemet och kan utsätta hela systemet för lagringspress.

Ändra Redis-konfigurationen på ett begripligt och kontrollerat sätt

Parametrarna repl-backlog-size och repl-backlog-ttl styr olika saker. Den första beskriver den avsedda storleken på backloggen. Den andra bestämmer på primärservern efter hur lång tid utan anslutna repliker backloggen kan frigöras. Den är ingen maximal avbrottslängd för PSYNC. Så länge bufferten skrivs över eller någon annan förutsättning saknas, hjälper en lång TTL i sig inte.

Följande rader är utkommenterade standardinställningar från konfigurationsmallen för Redis 7.2.0. Kommentarstecknen har medvetet behållits. Enbart genom att kopiera dessa rader aktiveras inga inställningar; dessutom utgör de angivna värdena inte någon allmän kapacitetsrekommendation för produktionssystem.

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

Med repl-backlog-ttl 0 inaktiveras den tidsstyrda frigivningen efter att alla repliker har kopplats bort. Detta bevarar inte en obegränsad historik: den befintliga bufferten kan fortfarande skrivas över av nya replikeringsdata. Det medför inte heller någon beständighet över eventuella omstarter av processen. Värdera därför noga om den extra minnesförbrukningen stämmer överens med det förväntade beteendet vid återanslutning.

Innan du gör en ändring bör du kontrollera de faktiskt gällande värdena och klargöra hur driftsättningen går till. En miljövariabel i en container, en hanterad konfigurationsfil och en inställning som ändras under körning är inte samma sak. Om en instans skapas på nytt senare kan endast de justeringar som gjorts under körning gå förlorade. Följande förfrågningar är läsbara; de kräver ändå lämpliga åtkomsträttigheter.

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

Med Managed Redis kan leverantören begränsa åtkomsten till CONFIG begränsa eller hantera inställningarna via ett eget gränssnitt. Det är ingen anledning att kringgå skyddsmekanismerna. Använd i så fall de godkända administrationsvägarna och dokumentera den valda storleken tillsammans med den underliggande replikeringsvolymen. I ändringsplanen bör dessutom de tidigare värdena och en realistisk återgångsplan anges.

Övervakning: Vilka värden hör ihop

För Övervakning av Redis-replikering En enskild grön anslutningsstatus räcker inte. En länk kan vara återansluten medan repliken fortfarande håller på att komma ikapp eller just laddar en fullständig datamängd. Omvänt behöver ett kortvarigt avbrott i anslutningen inte omedelbart vara kritiskt om historiken och kapaciteten att komma ikapp är tillräckliga. Utvärdera därför anslutningen, synkroniseringsstatus, förskjutningsutvecklingen och tillgänglig historik tillsammans.

Fälten i en INFO-Svar kan variera mellan olika Redis-versioner och mellan primärserver och replik. En utvärdering bör därför uttryckligen ta hänsyn till saknade fält, i stället för att tyst tolka dem som noll eller som ett felfritt tillstånd. Även benämningarna master och slave förekommer fortfarande i fältnamn av kompatibilitetsskäl; de får inte översättas fritt i den körbara koden.

För tolkningen av eftersläpningen gäller den interna riktlinjen Analysera Redis-replikeringens offset ett lämpligt komplement. Vid den löpande övervakningen bör du beakta historiska trender, inte bara två manuellt avlästa siffror. Ett växande avstånd kräver en annan reaktion än ett gap som stadigt minskar efter ett kort avbrott.

Meningsfulla larm utgår från dina driftsmål: Hur länge får en replik vara otillgänglig? Hur snabbt måste den komma ikapp? Vilken frekvens av fullständiga synkroniseringar är onormal? Fasta gränsvärden utan hänsyn till belastningsprofil och datamängd leder ofta till onödiga meddelanden eller att verkliga försämringar förbises. Håll förutom replikeringsmått även koll på RAM-utnyttjande, nätverksbelastning och indikationer på processomstarter.

Att korrekt tolka lagringsbudget och långsamma repliker

Orderstocken är bara en del av det totala Redis-minnesbehov. Till detta kommer datamängden, administrationsstrukturerna, klientbuffertar och, beroende på driftstatus, ytterligare lagringsutrymme under persistens- eller synkroniseringsarbetet. Planera därför inte att använda hela det tillgängliga arbetsminnet för användardata plus en exakt beräknad backlog. Den nödvändiga reserven måste fastställas utifrån den konkreta miljön och de belastningstoppar som uppstår där.

Sedan Redis 7.0 delar Replica-Buffer och Replication Backlog på samma minne. I INFO-dokumentationen påpekas därför bland annat att mem_clients_slaves kan vara noll om replikbuffertarna inte överskrider backlog-beläggningen. Detta innebär dock inte att replikeringen inte tar upp något minne. Betrakta de värden som är avsedda för detta som mem_replication_backlog och mem_total_replication_buffers i sitt sammanhang och räknar inte ihop överlappande storheter utan att tänka efter.

Ett vanligt diagnostiskt misstag är att man försöker hantera varje avbruten synkronisering som om det vore ett större eftersläpning. Långsamma repliker, begränsad nätverksbandbredd eller överskridna gränser för utdatabuffertar kan ha andra orsaker. Parametern client-output-buffer-limit replica gäller den aktuella klientklassen och får inte användas tillsammans med repl-backlog-size ska betraktas som likvärdiga. Innan du ändrar gränsvärdena bör du granska loggar, versionsdokumentation och de förväntade effekterna på andra anslutningar.

Varför en stor backlog inte garanterar hög tillgänglighet

Backloggen förbättrar återanslutningen, men gör inte den som standard asynkrona replikeringen förlustfri. En primärserver kan redan ha bekräftat en skrivoperation gentemot klienten innan en replik har bearbetat den. Om den primära servern går ner under denna tidsperiod finns den aktuella operationen eventuellt inte på det ersättningssystem som senare väljs ut. Buffertstorleken i sig löser inte detta problem Risken för dataförlust vid failover inte.

Dessutom WAIT förvandlar inte en Redis-topologi till ett system med garanterad stark konsistens. Kommandot kan vänta på bekräftelser från repliker; den faktiska datasäkerheten beror fortfarande på andra omständigheter, framför allt på persistens- och failover-beteendet. På samma sätt begränsar min-replicas-to-write och min-replicas-max-lag att, enligt sina respektive villkor, ta emot nya skrivoperationer utan att automatiskt spara varje enskild operation permanent på flera instanser.

För Hög tillgänglighet Därför behöver du ett sammanhängande beslut: acceptabel dataförlust, tillåten driftstoppstid, datapersistens, upptäckt av störningar, val av ny primärinstans och återställning. Sentinel eller Redis Cluster kan i detta sammanhang ta över andra uppgifter än backloggen. Den som endast ökar storleken på en buffert och lämnar alla övriga antaganden oförändrade har ännu inte en tillförlitlig återställningsplan.

Testa ändringar och identifiera återkommande problem

Inled ett kontrollerat test i en isolerad miljö med en jämförbar Redis-version och en förutsägbar skrivbelastning. Dokumentera replikerings-ID:n, offsetvärdena, backlog-beläggningen och minnesanvändningen innan avbrottet. Simulera därefter ett begränsat avbrott i anslutningen utan att ändra produktiva brandväggar eller processer som inte har testats. Efter återanslutningen observerar du om en partiell eller fullständig synkronisering sker och hur lång tid det tar att komma ikapp.

Försök att endast ändra en relevant variabel per test. Om backlog, skrivbelastning och nätverksförhållanden ändras samtidigt blir det svårt att fastställa orsaken till effekten. Upprepa testet med olika avbrottslängder och olika belastningsfaser. På så sätt blir en enskild lyckad återanslutning till en begriplig bedömning av beteendet. De observerade gränserna bör dokumenteras, utan att man därav drar slutsatsen att detta gäller för alla framtida störningar.

Vid upprepade fullständiga synkroniseringar ska du först kontrollera om historiken överhuvudtaget är kompatibel. Därefter följer de återstående byten, tiden utan replik, indikationer på omstarter och den faktiska återhämtningshastigheten. En för liten buffert är en möjlig orsak, men inte den enda. Det är särskilt viktigt att skilja mellan ett engångsavbrott som varar för länge och en replik som ständigt hamnar efter, även när anslutningen är aktiv.

Den rätta inställningen är i slutändan den som täcker det av dig definierade avbrottsfönstret vid realistisk belastning och lämnar tillräckligt med minne för den övriga driften. Dokumentera mätunderlag, konfigurationskälla och testdatum tillsammans. Efter större ändringar av skrivbeteendet, topologin eller Redis-versionen bör dimensioneringen ses över på nytt. På så sätt förblir backloggen ett välgrundat driftsbeslut istället för ett värde som en gång fastställts.