Inzicht in de replicatie-achterstand van Redis: PSYNC, omvang en HA-beperkingen

De Redis-replicatieachterstand bepaalt mede of een replica na een verbroken verbinding alleen de ontbrekende wijzigingen bijwerkt of de volledige dataset opnieuw moet ontvangen. Wie de buffer afstemt op het daadwerkelijke replicatievolume, kan onnodige volledige synchronisaties voorkomen. Hiervoor moeten echter ook de replicatiegeschiedenis, het opslagbudget en de bedrijfsprocessen op elkaar zijn afgestemd: een grote achterstand is geen vervanging voor persistentie of een robuust failover-concept.

Wat er daadwerkelijk in de backlog wordt opgeslagen

Op Redis-replicatie De primaire database verwerkt wijzigingen in de gegevensset en stuurt een doorlopende stroom van opdrachten naar zijn replica’s. Dit omvat niet alleen waarden die rechtstreeks door clients worden geschreven. Ook verlopen of verdrongen sleutels kunnen wijzigingen teweegbrengen die moeten worden doorgegeven. De backlog houdt een beperkt, recent deel van deze replicatiestroom in het werkgeheugen bij. Hij bevat daarom geen extra volledige kopie van de database en is ook geen archief van willekeurig oude schrijfbewerkingen.

Bij een storingsvrije werking volgen de replica’s de lopende stroom. Als een verbinding wordt onderbroken, groeit de geschiedenis op de primaire server verder. Nadat de verbinding is hersteld, probeert de replica verder te gaan vanaf het punt waar deze was gebleven. Het is dan van cruciaal belang of de benodigde bytes nog beschikbaar zijn. Als dat het geval is en de replicatiegeschiedenis klopt, kan Redis het gat opvullen. De reeds aanwezige gegevens van de replica hoeven hiervoor niet volledig te worden vervangen.

Het voordeel komt vooral tot uiting bij korte netwerkstoringen, wisselingen van verbinding en geplande onderhoudswerkzaamheden. Een volledige synchronisatie van een grote gegevensbestand vraagt veel overdrachtscapaciteit en rekenkracht; afhankelijk van de configuratie komen daar nog extra belastingen op opslag en gegevensdragers bij. De backlog kan deze inspanning verminderen, maar niet elke vorm van onderbreking opvangen. Een herstart van het proces of een gewijzigde geschiedenis vereist een andere benadering dan een kortstondig verbroken TCP-verbinding.

Wanneer volstaat PSYNC en wanneer is een volledige resynchronisatie nodig?

A gedeeltelijke resynchronisatie met PSYNC vereist twee bij elkaar horende gegevens: de replicatie-ID en de offset. De ID verwijst naar een bepaalde gegevensgeschiedenis. De offset beschrijft een bytepositie binnen de replicatiestroom. Twee offsets van gelijke grootte uit verschillende geschiedenissen zijn daarom niet automatisch vergelijkbaar. Omgekeerd kan een kleine achterstand in dezelfde geschiedenis al buiten de beschikbare backlog vallen, als de capaciteit daarvan krap is.

Eenvoudig gezegd meldt de Replica bij het opnieuw verbinden tot welk punt zij is gekomen. De Primary controleert of hij de vervolgens benodigde gegevens kan leveren. Als de geschiedenis onbekend is of als het benodigde gedeelte ontbreekt, wordt een Volledige hersynchronisatie noodzakelijk. Daarbij ontvangt de replica een volledige dataset en vervolgens de wijzigingen die tijdens de synchronisatie zijn opgetreden. Afhankelijk van de configuratie kan de overdracht plaatsvinden met een RDB-tussenstap naar een opslagmedium of zonder deze tussenstap.

Na een failover is een volledige resynchronisatie niet in alle gevallen onvermijdelijk. Een verplaatste replica kan bovendien het vorige replicatie-ID en het bijbehorende geldige offsetbereik onthouden. Hierdoor kunnen andere replica’s onder de juiste omstandigheden aansluiten op de bekende geschiedenis. Voor de planning biedt dit echter geen garantie: het relevante bereik moet nog steeds beschikbaar zijn en de daadwerkelijke herverbinding moet overeenkomen met de opgeslagen ID's.

De replicatiesnelheid meten in plaats van de databasegrootte te schatten

Alleen al de omvang van de gegevensbestand is voldoende om Dimensionering van de backlog niet. Een grote database die voornamelijk wordt gelezen, genereert weinig replicatieverkeer. Een kleine cache met vaak wisselende waarden en veel vervalgebeurtenissen kan daarentegen voortdurend aanzienlijke hoeveelheden gegevens overdragen. Ook een vast aantal bewerkingen per seconde geeft onvoldoende inzicht in de benodigde opslagruimte: kleine wijzigingen in sleutels en het overschrijven van grote waarden leiden niet tot dezelfde hoeveelheid bytes.

Een praktisch bruikbare benadering volgt uit de toename in de tijd van master_repl_offset. Meet de waarde twee keer op dezelfde primaire server en deel het verschil door het aantal verstreken seconden. Controleer daarbij ook de replicatie-ID. Na een rolwisseling of een herstart mag je twee niet-bij elkaar horende meetpunten niet zomaar van elkaar aftrekken. Een enkel meetinterval levert bovendien alleen een gemiddelde snelheid binnen dat interval op, geen permanent gegarandeerde bovengrens.

De volgende query leest diagnose-informatie. Deze wijzigt de Redis-configuratie niet. Voer deze uit met de verbindings- en authenticatieopties die in jouw omgeving vereist zijn. De hieronder weergegeven aanroep maakt gebruik van de standaardverbinding van redis-cli; er moet uitdrukkelijk een andere host, poort of TLS-toegang worden ingesteld.

redis-cli INFO replication

Meet de belasting tijdens verschillende belastingfasen, bijvoorbeeld tijdens de normale dagelijkse werkzaamheden, bij importen en tijdens grotere cachevernieuwingen. Leg zowel de typische waarden als korte pieken vast. Als er veel wijzigingen optreden door het verlopen van sleutels, biedt het interne artikel verdere thematische verdieping. De vervaldatum van Redis-sleutels analyseren. Dit verband is belangrijk voor de planning, omdat niet elke relevante schrijfimpuls direct voortkomt uit een nieuwe gebruikersaanvraag.

De omvang van de achterstand op een begrijpelijke manier berekenen

Als planningsbenadering Je kunt de relevante replicatiesnelheid vermenigvuldigen met de duur van de te overbruggen onderbreking en vervolgens een gemotiveerde reserve toevoegen. Bij de duur moet niet alleen rekening worden gehouden met de daadwerkelijke netwerkonderbreking. Ook het detecteren van de storing, pogingen om opnieuw verbinding te maken en het herstellen van de verbinding kunnen tijd kosten. Welke reserve passend is, hangt af van waargenomen schommelingen en de gewenste bedrijfsdoelstelling, niet van een universeel percentage.

Een bewust vereenvoudigd rekenvoorbeeld: voor een bepaalde belastingsfase ga je uit van 12 MiB per seconde. De verbinding zou 90 seconden kunnen uitvallen; er wordt nog eens 30 seconden als tijdsreserve ingecalculeerd. Hieruit volgt 12 MiB/s × 120 s = 1.440 MiB, dus ongeveer 1,41 GiB. Deze cijfers zijn aannames ter verduidelijking en geen Redis-benchmark. Voordat je de instellingen in productie neemt, moeten ze worden vervangen door meetwaarden van je applicatie.

De omgekeerde berekening helpt bij het inschatten van een bestaande buffer. Een volledig gevulde backlog van 256 MiB komt, bij een constante snelheid van 12 MiB per seconde, rekenkundig gezien overeen met ongeveer 21 seconden geschiedenis. Bij 2 MiB per seconde zou dat ongeveer 128 seconden zijn. In de praktijk variëren de snelheden echter. Een dergelijk bereik is daarom slechts een momentopname en geen garantie dat elke storing van deze duur gedeeltelijk kan worden gesynchroniseerd.

Controleer bovendien of de replica, nadat de verbinding is hersteld, sneller kan bijpraten dan dat er nieuwe wijzigingen ontstaan. Het verwijderen van meer geschiedenis lost noch een permanent te traag netwerk, noch een permanent overbelaste ontvanger op. Als de achterstand blijft bestaan of verder toeneemt, moet de oorzaak worden onderzocht. Steeds meer opslagruimte inplannen verschuift het probleem anders alleen maar en kan het hele systeem onder opslagdruk zetten.

De Redis-configuratie op een begrijpelijke en gecontroleerde manier wijzigen

De parameters repl-backlog-size en repl-backlog-ttl bepalen verschillende zaken. De eerste beschrijft de beoogde omvang van de backlog. De tweede bepaalt op de primaire server na hoeveel tijd zonder verbonden replica’s de backlog kan worden vrijgegeven. Deze is geen maximale onderbrekingsduur voor PSYNC. Zolang de buffer wordt overschreven of een andere voorwaarde niet is vervuld, helpt een lange TTL op zich niet.

De volgende regels zijn uitgeschakelde standaardinstellingen uit het configuratiesjabloon van Redis 7.2.0. De commentaartekens zijn bewust behouden. Door deze regels simpelweg te kopiëren, worden er geen instellingen geactiveerd; bovendien vormen de genoemde waarden geen algemene aanbeveling voor de capaciteit van productiesystemen.

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

Met repl-backlog-ttl 0 wordt de tijdgestuurde vrijgave uitgeschakeld nadat alle replica’s zijn losgekoppeld. Hierdoor wordt geen onbeperkte geschiedenis bewaard: de bestaande buffer kan nog steeds worden overschreven door nieuwe replicatiegegevens. Ook ontstaat hierdoor geen persistentie bij willekeurige herstarts van het proces. Beoordeel daarom zorgvuldig of het extra geheugenverbruik in verhouding staat tot het verwachte herverbindingsgedrag.

Voordat je een wijziging doorvoert, moet je de daadwerkelijk geldende waarden opvragen en de implementatieprocedure verduidelijken. Een containeromgevingsvariabele, een beheerd configuratiebestand en een instelling die tijdens de uitvoering wordt gewijzigd, zijn niet hetzelfde. Als een instantie later opnieuw wordt aangemaakt, kunnen uitsluitend de aanpassingen die tijdens de uitvoering zijn aangebracht, verloren gaan. De volgende query's zijn alleen-lezen; toch heb je hiervoor de juiste toegangsrechten nodig.

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

Bij Managed Redis kan de aanbieder de toegang tot CONFIG beperken of instellingen via een eigen interface beheren. Dat is geen reden om beveiligingsmechanismen te omzeilen. Maak in dat geval gebruik van de goedgekeurde beheerkanalen en documenteer de gekozen omvang samen met het onderliggende replicatievolume. In het wijzigingsplan moeten bovendien de huidige waarden en een realistische terugkeeroptie worden vastgelegd.

Monitoring: welke waarden horen bij elkaar

Voor de Monitoring van de Redis-replicatie is één enkele groene verbindingsstatus onvoldoende. Een verbinding kan alweer tot stand zijn gebracht terwijl de replica nog een achterstand aan het inhalen is of juist een volledige dataset aan het laden is. Omgekeerd hoeft een korte onderbreking van de verbinding niet meteen kritiek te zijn, mits de geschiedenis en de inhaalcapaciteit toereikend zijn. Beoordeel daarom de verbinding, de synchronisatiestatus, de ontwikkeling van de offset en de beschikbare geschiedenis gezamenlijk.

De velden van een INFO-Antwoorden kunnen verschillen tussen Redis-versies en tussen primary en replica. Een analyse moet daarom expliciet rekening houden met ontbrekende velden, in plaats van deze stilzwijgend te interpreteren als null of als een foutloze toestand. Ook de benamingen master en slave komen om compatibiliteitsredenen nog steeds voor in veldnamen; ze mogen in de uitvoerbare code niet vrij worden vertaald.

Voor de interpretatie van de achterstand geldt de interne richtlijn De replicatie-offset van Redis analyseren een passende aanvulling. Bij de lopende monitoring moet je naar historische trends kijken, en niet alleen naar twee handmatig afgelezen cijfers. Een groeiende afstand vraagt om een andere reactie dan een kloof die na een korte uitval gestaag kleiner wordt.

Zinvolle waarschuwingen zijn afgestemd op je bedrijfsdoelstellingen: hoe lang mag een replica onbereikbaar zijn? Hoe snel moet deze weer bijpraten? Welke frequentie van volledige synchronisaties is ongebruikelijk? Starre drempelwaarden zonder rekening te houden met het belastingsprofiel en de gegevenshoeveelheid leiden vaak tot onnodige meldingen of zorgen ervoor dat echte verslechteringen over het hoofd worden gezien. Houd naast replicatiestatistieken ook het RAM-gebruik, het netwerkgebruik en aanwijzingen voor het opnieuw opstarten van processen in de gaten.

Het opslagbudget en trage replica’s op de juiste manier inschatten

De achterstand is slechts een deel van het geheel Benodigde opslagruimte voor Redis. Daarbij komen nog de gegevensbestanden, beheerstructuren, clientbuffers en, afhankelijk van de bedrijfstoestand, extra geheugen tijdens de persistentie- of synchronisatietaken. Plan daarom niet het volledige beschikbare werkgeheugen in voor gebruiksgegevens plus een exact berekende backlog. De benodigde reserve moet worden afgeleid uit de concrete omgeving en de daar voorkomende piekbelastingen.

Sinds Redis 7.0 delen de replica-buffer en de replicatie-backlog geheugen. In de INFO-documentatie wordt daarom onder andere vermeld dat mem_clients_slaves null kan zijn als de replicabuffers de backlog-bezetting niet overschrijden. Hieruit volgt niet dat replicatie geen geheugen in beslag neemt. Beschouw de daarvoor bestemde waarden als mem_replication_backlog en mem_total_replication_buffers in de juiste context en tel overlappende grootheden niet zomaar bij elkaar op.

Een veelvoorkomende diagnosefout is dat elke afgebroken synchronisatie wordt toegeschreven aan een grote achterstand. Trage replica’s, beperkte netwerkbandbreedte of overschreden limieten voor de uitvoerbuffer kunnen een andere oorzaak hebben. De parameter client-output-buffer-limit replica heeft betrekking op de betreffende clientklasse en mag niet worden verward met repl-backlog-size op één lijn worden gesteld. Controleer, voordat je limieten wijzigt, de logbestanden, de versiedocumentatie en de te verwachten gevolgen voor andere verbindingen.

Waarom een grote backlog nog geen hoge beschikbaarheid garandeert

De backlog verbetert de herverbinding, maar maakt de standaard asynchrone replicatie niet verliesvrij. Een primaire server kan een schrijfbewerking al aan de client hebben bevestigd voordat een replica deze heeft verwerkt. Als de primaire server in deze periode uitvalt, is de betreffende bewerking mogelijk niet aanwezig op het later geselecteerde vervangende systeem. De buffergrootte alleen lost dit niet op Risico op gegevensverlies bij een failover niet.

Ook WAIT maakt een Redis-topologie niet tot een systeem met gegarandeerde sterke consistentie. Het commando kan wachten op bevestigingen van replica’s; de daadwerkelijke gegevensveiligheid blijft afhankelijk van andere omstandigheden, met name van het persistentie- en failover-gedrag. Evenzo beperken min-replicas-to-write en min-replicas-max-lag onder hun respectieve voorwaarden het accepteren van nieuwe schrijfbewerkingen, zonder elke afzonderlijke bewerking automatisch permanent op meerdere instanties op te slaan.

Voor Hoge beschikbaarheid Daarom moet je een samenhangend besluit nemen: aanvaardbaar gegevensverlies, toegestane uitvaltijd, persistentie, detectie van storingen, selectie van de nieuwe primaire server en herstel. Sentinel of Redis Cluster kunnen daarbij andere taken op zich nemen dan de backlog. Wie alleen de grootte van een buffer vergroot en alle overige aannames ongewijzigd laat, heeft nog geen robuust herstelplan.

Wijzigingen testen en terugkerende problemen opsporen

Start een gecontroleerde test in een geïsoleerde omgeving met een vergelijkbare Redis-versie en een voorspelbare schrijfbelasting. Noteer vóór de onderbreking de replicatie-ID’s, offsets, backlog-bezetting en het geheugengebruik. Simuleer vervolgens een beperkte verbroken verbinding, zonder ongecontroleerde wijzigingen aan te brengen in productieve firewalls of processen. Nadat de verbinding is hersteld, kijk je of er een gedeeltelijke of volledige synchronisatie plaatsvindt en hoe lang het duurt om de achterstand in te halen.

Verander per test bij voorkeur slechts één relevante variabele. Als de backlog, de schrijfbelasting en de netwerkomstandigheden tegelijkertijd veranderen, is het effect nauwelijks te achterhalen. Herhaal de test met verschillende onderbrekingsduur en verschillende belastingfasen. Zo leidt een enkele succesvolle herverbinding tot een begrijpelijke inschatting van het gedrag. De waargenomen grenzen moeten worden gedocumenteerd, zonder daaruit een garantie voor elke toekomstige storing af te leiden.

Bij herhaalde volledige resyncs controleer je eerst of de geschiedenis überhaupt compatibel is. Daarna volgen de nog aanwezige bytes, de tijd zonder replica, aanwijzingen voor herstarts en de daadwerkelijke inhaalsnelheid. Een te kleine buffer is een mogelijke oorzaak, maar niet de enige. Het is vooral belangrijk om onderscheid te maken tussen een eenmalige, te lange onderbreking en een replica die, zelfs bij een bestaande verbinding, voortdurend achterblijft.

De juiste instelling is uiteindelijk degene die je gedefinieerde uitvalvenster bij een realistische belasting dekt en voldoende geheugen overlaat voor de overige activiteiten. Leg de meetbasis, de configuratiebron en de controledatum samen vast. Na grotere wijzigingen in het schrijfgedrag, de topologie of de Redis-versie moet de dimensionering opnieuw worden getoetst. Zo blijft de backlog een onderbouwde operationele beslissing in plaats van een eenmalig vastgelegd cijfer.