{"id":21633,"date":"2026-09-21T22:06:16","date_gmt":"2026-09-21T20:06:16","guid":{"rendered":"https:\/\/webhosting.de\/?p=21633"},"modified":"2026-09-21T22:06:19","modified_gmt":"2026-09-21T20:06:19","slug":"de-replicatie-achterstand-van-redis-begrijpen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/redis-replication-backlog-verstehen\/","title":{"rendered":"Inzicht in de replicatie-achterstand van Redis: PSYNC, omvang en HA-beperkingen"},"content":{"rendered":"<div class=\"wh-article wh-editorial-21633\" data-editorial-words=\"2240\" style=\"max-width:820px;margin:0 auto;color:#243447;font-size:19px;line-height:1.8;overflow-wrap:anywhere;\"><p class=\"wh-lead\" style=\"margin:0 0 25px;font-size:21px;line-height:1.75;color:#243447;\">De <strong style=\"font-weight:700;color:#153e50;\">Redis-replicatieachterstand<\/strong> 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. <\/p><nav aria-label=\"Inhoud van dit artikel\" class=\"wh-toc\" style=\"margin:30px 0 42px;padding:24px;border:1px solid #dbe5eb;border-radius:18px;background:#f5f9fb;box-shadow:0 8px 24px rgba(15,35,55,.06);\"><p style=\"margin:0 0 14px;font-size:13px;font-weight:700;letter-spacing:.08em;text-transform:uppercase;color:#426477;\">Direct naar de paragraaf<\/p><div style=\"display:flex;flex-wrap:wrap;gap:10px;\"><a href=\"#grundprinzip\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Wat er daadwerkelijk in de backlog wordt opgeslagen<\/a>\n<a href=\"#psync\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Wanneer volstaat PSYNC en wanneer is een volledige resynchronisatie nodig?<\/a>\n<a href=\"#replikationsrate\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">De replicatiesnelheid meten in plaats van de databasegrootte te schatten<\/a>\n<a href=\"#dimensionierung\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">De omvang van de achterstand op een begrijpelijke manier berekenen<\/a>\n<a href=\"#konfiguration\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">De Redis-configuratie op een begrijpelijke en gecontroleerde manier wijzigen<\/a>\n<a href=\"#monitoring\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Monitoring: welke waarden horen bij elkaar<\/a>\n<a href=\"#speicherbudget\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Het opslagbudget en trage replica\u2019s op de juiste manier inschatten<\/a>\n<a href=\"#hochverfuegbarkeit\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Waarom een grote backlog nog geen hoge beschikbaarheid garandeert<\/a>\n<a href=\"#praxis\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Wijzigingen testen en terugkerende problemen opsporen<\/a><\/div><\/nav><h2 id=\"grundprinzip\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Wat er daadwerkelijk in de backlog wordt opgeslagen<\/h2><p style=\"margin:0 0 22px;\">Op <strong style=\"font-weight:700;color:#153e50;\">Redis-replicatie<\/strong> De primaire database verwerkt wijzigingen in de gegevensset en stuurt een doorlopende stroom van opdrachten naar zijn replica\u2019s. 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. <\/p><p style=\"margin:0 0 22px;\">Bij een storingsvrije werking volgen de replica\u2019s 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. <\/p><p style=\"margin:0 0 22px;\">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. <\/p><h2 id=\"psync\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Wanneer volstaat PSYNC en wanneer is een volledige resynchronisatie nodig?<\/h2><p style=\"margin:0 0 22px;\">A <strong style=\"font-weight:700;color:#153e50;\">gedeeltelijke resynchronisatie met PSYNC<\/strong> 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.  <\/p><p style=\"margin:0 0 22px;\">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 <strong style=\"font-weight:700;color:#153e50;\">Volledige hersynchronisatie<\/strong> 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.  <\/p><p style=\"margin:0 0 22px;\">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\u2019s 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.  <\/p><div aria-label=\"Een replica opnieuw verbinden: mogelijke uitkomsten\" class=\"wh-table-scroll\" role=\"region\" style=\"margin:30px 0 36px;overflow-x:auto;border:1px solid #dce5eb;border-radius:16px;box-shadow:0 12px 30px rgba(22,43,61,.09);background:#fff;\" tabindex=\"0\"><table style=\"width:100%;min-width:620px;border-collapse:collapse;margin:0;font-size:15px;line-height:1.65;\"><caption style=\"padding:18px 22px;text-align:left;font-size:16px;font-weight:700;color:#163649;background:#eef5f8;\">Een replica opnieuw verbinden: mogelijke uitkomsten<\/caption><thead><tr><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Situatie<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Voorwaarde<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Resultaat<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Korte onderbreking<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Juiste geschiedenis; benodigde bytes nog beschikbaar<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">PSYNC kan alleen de ontbrekende replicatiegegevens alsnog leveren.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">De oudste benodigde bytes zijn overschreven<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Het opgevraagde bereik valt buiten de beschikbare geschiedenis<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Volledige herijking in plaats van gedeeltelijke herhaling.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Onbekende replicatiegeschiedenis<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">De replicatie-ID wordt niet als geldig herkend<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Een grotere achterstand alleen lost het probleem niet op.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Failover met bekende ID van de voorganger<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Opgeslagen secundaire ID, geldig offsetbereik en voldoende geschiedenis<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Een gedeeltelijke resynchronisatie kan nog steeds mogelijk zijn.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Backlog vrijgegeven na het scheiden van alle replica's<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">TTL is verlopen; er blijft geen bruikbare geschiedenis over<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Voor de latere heraansluiting is een volledige afstemming nodig.<\/td><\/tr><\/tbody><\/table><\/div><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Een beperkt venster in de gegevensstroom laat zien welke ontbrekende replicatiegegevens na een onderbreking nog beschikbaar zijn.\" class=\"wp-image-21638\" decoding=\"async\" height=\"1024\" sizes=\"auto, (max-width: 820px) 100vw, 820px\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633.webp\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633.webp 1536w\" style=\"display:block;width:100%;height:auto;border-radius:16px;border:1px solid #e1e8ed;box-shadow:0 12px 30px rgba(23,43,62,.09);\" width=\"1536\"\/><figcaption style=\"margin-top:12px;font-size:14px;line-height:1.6;color:#607381;\">Schematische weergave: PSYNC kan alleen worden gekoppeld aan een geschikte en nog beschikbare replicatiegeschiedenis.<\/figcaption><\/figure><h2 id=\"replikationsrate\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">De replicatiesnelheid meten in plaats van de databasegrootte te schatten<\/h2><p style=\"margin:0 0 22px;\">Alleen al de omvang van de gegevensbestand is voldoende om <strong style=\"font-weight:700;color:#153e50;\">Dimensionering van de backlog<\/strong> 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.  <\/p><p style=\"margin:0 0 22px;\">Een praktisch bruikbare benadering volgt uit de toename in de tijd van <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master_repl_offset<\/code>. 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.  <\/p><p style=\"margin:0 0 22px;\">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 <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">redis-cli<\/code>; er moet uitdrukkelijk een andere host, poort of TLS-toegang worden ingesteld.  <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">Terminal &#183; Replikationsstatus lesen<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"Terminal &#183; Replikationsstatus lesen\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\">redis-cli INFO replication<\/pre><\/div><p style=\"margin:0 0 22px;\">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. <a href=\"https:\/\/webhosting.de\/nl\/redis-sleutel-vervaldatum-prestaties-analyseren-optimaliseren-cache\/\">De vervaldatum van Redis-sleutels analyseren<\/a>. Dit verband is belangrijk voor de planning, omdat niet elke relevante schrijfimpuls direct voortkomt uit een nieuwe gebruikersaanvraag.  <\/p><h2 id=\"dimensionierung\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">De omvang van de achterstand op een begrijpelijke manier berekenen<\/h2><p style=\"margin:0 0 22px;\">Als <strong style=\"font-weight:700;color:#153e50;\">planningsbenadering<\/strong> 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. <\/p><p style=\"margin:0 0 22px;\">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 <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">12 MiB\/s &#215; 120 s = 1.440 MiB<\/code>, 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. <\/p><figure class=\"wh-chart\"><figcaption>Benodigde backlog bij een veronderstelde snelheid van 12 MiB\/s<\/figcaption><p class=\"wh-chart-unit\" style=\"margin:0 0 22px;\">MiB<\/p><div class=\"wh-chart-bars\"><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">30 seconden<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:16.6667%\"><\/span><\/span><span class=\"wh-chart-number\">360<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">60 seconden<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:33.3333%\"><\/span><\/span><span class=\"wh-chart-number\">720<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">120 seconden<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:66.6667%\"><\/span><\/span><span class=\"wh-chart-number\">1440<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">180 seconden<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:100.0000%\"><\/span><\/span><span class=\"wh-chart-number\">2160<\/span><\/div><\/div><p style=\"margin:0 0 22px;\">Illustratief rekenvoorbeeld, geen meting: benodigde capaciteit = veronderstelde 12 MiB\/s \u00d7 gekozen totale duur. De 120 seconden in het tekstvoorbeeld omvatten 90 seconden onderbreking en 30 seconden tijdsreserve. Verdere reserves zijn hier niet meegerekend.<\/p><details><summary>Gegevenstabel bij de grafiek<\/summary><table><thead><tr><th scope=\"col\">Ingang<\/th><th scope=\"col\">MiB<\/th><\/tr><\/thead><tbody><tr><td>30 seconden<\/td><td>360<\/td><\/tr><tr><td>60 seconden<\/td><td>720<\/td><\/tr><tr><td>120 seconden<\/td><td>1440<\/td><\/tr><tr><td>180 seconden<\/td><td>2160<\/td><\/tr><\/tbody><\/table><\/details><\/figure><p style=\"margin:0 0 22px;\">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\u00ebren de snelheden echter. Een dergelijk bereik is daarom slechts een momentopname en geen garantie dat elke storing van deze duur gedeeltelijk kan worden gesynchroniseerd. <\/p><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Twee even grote historische vensters met gegevensstromen van verschillende dichtheid illustreren de invloed van de replicatiesnelheid.\" class=\"wp-image-21639\" decoding=\"async\" height=\"1024\" sizes=\"auto, (max-width: 820px) 100vw, 820px\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633.webp\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633.webp 1536w\" style=\"display:block;width:100%;height:auto;border-radius:16px;border:1px solid #e1e8ed;box-shadow:0 12px 30px rgba(23,43,62,.09);\" width=\"1536\"\/><figcaption style=\"margin-top:12px;font-size:14px;line-height:1.6;color:#607381;\">Conceptuele illustratie: bij een gelijke buffergrootte verkort een grotere replicatiestroom het tijdsbereik.<\/figcaption><\/figure><p style=\"margin:0 0 22px;\">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. <\/p><h2 id=\"konfiguration\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">De Redis-configuratie op een begrijpelijke en gecontroleerde manier wijzigen<\/h2><p style=\"margin:0 0 22px;\">De parameters <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-size<\/code> en <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-ttl<\/code> 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\u2019s de backlog kan worden vrijgegeven. Deze is <strong style=\"font-weight:700;color:#153e50;\">geen maximale onderbrekingsduur voor PSYNC<\/strong>. Zolang de buffer wordt overschreven of een andere voorwaarde niet is vervuld, helpt een lange TTL op zich niet.   <\/p><p style=\"margin:0 0 22px;\">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\u00ebren, worden er geen instellingen geactiveerd; bovendien vormen de genoemde waarden geen algemene aanbeveling voor de capaciteit van productiesystemen.   <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">redis.conf &#183; auskommentierte Vorlage<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"redis.conf &#183; auskommentierte Vorlage\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\"># Redis 7.2.0: auskommentierte Vorgaben aus redis.conf\n# repl-backlog-size 1mb\n# repl-backlog-ttl 3600<\/pre><\/div><p style=\"margin:0 0 22px;\">Met <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-ttl 0<\/code> wordt de tijdgestuurde vrijgave uitgeschakeld nadat alle replica\u2019s 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.   <\/p><p style=\"margin:0 0 22px;\">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.   <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">Terminal &#183; aktive Einstellungen abfragen<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"Terminal &#183; aktive Einstellungen abfragen\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\">redis-cli CONFIG GET repl-backlog-size\nredis-cli CONFIG GET repl-backlog-ttl<\/pre><\/div><p style=\"margin:0 0 22px;\">Bij Managed Redis kan de aanbieder de toegang tot <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">CONFIG<\/code> 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.   <\/p><h2 id=\"monitoring\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Monitoring: welke waarden horen bij elkaar<\/h2><p style=\"margin:0 0 22px;\">Voor de <strong style=\"font-weight:700;color:#153e50;\">Monitoring van de Redis-replicatie<\/strong> is \u00e9\u00e9n 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. <\/p><div aria-label=\"Redis-monitoring: waarden in hun onderlinge samenhang interpreteren\" class=\"wh-table-scroll\" role=\"region\" style=\"margin:30px 0 36px;overflow-x:auto;border:1px solid #dce5eb;border-radius:16px;box-shadow:0 12px 30px rgba(22,43,61,.09);background:#fff;\" tabindex=\"0\"><table style=\"width:100%;min-width:620px;border-collapse:collapse;margin:0;font-size:15px;line-height:1.65;\"><caption style=\"padding:18px 22px;text-align:left;font-size:16px;font-weight:700;color:#163649;background:#eef5f8;\">Redis-monitoring: waarden in hun onderlinge samenhang interpreteren<\/caption><thead><tr><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Veld<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Dat betekent<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Waar je op let<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">master_replid \/ master_repl_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Identiteit van de geschiedenis en huidige byte-offset op de primaire<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Vergelijk meetpunten alleen binnen dezelfde tijdreeks.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">repl_backlog_active<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Of de replicatieachterstand momenteel actief is<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Een geconfigureerde waarde op zich betekent nog niet dat er een geschiedenis beschikbaar is.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">repl_backlog_first_byte_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Offset van de eerste nog opgeslagen byte<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">De gegevens die nodig zijn voor de replica moeten passen binnen de beschikbare ruimte.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">repl_backlog_histlen \/ repl_backlog_size<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">De huidige lengte van de geschiedenis en de geconfigureerde grootte<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Een pas aangelegde buffer hoeft nog niet volledig gevuld te zijn.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">master_link_status \/ master_sync_in_progress<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Verbinding en voortdurende synchronisatie vanuit het perspectief van de replica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Het feit dat een link weer beschikbaar is, betekent op zich nog niet dat de vergelijking is voltooid.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">slave_repl_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Voortgang van de replicatie op een replica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Houd rekening met het tijdsverloop en de bijbehorende geschiedenis.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 22px;\">De velden van een <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">INFO<\/code>-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 <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master<\/code> en <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">slave<\/code> komen om compatibiliteitsredenen nog steeds voor in veldnamen; ze mogen in de uitvoerbare code niet vrij worden vertaald. <\/p><p style=\"margin:0 0 22px;\">Voor de interpretatie van de achterstand geldt de interne richtlijn <a href=\"https:\/\/webhosting.de\/nl\/redis-replicatie-offset-analyse-gegevensconsistentie-cluster\/\">De replicatie-offset van Redis analyseren<\/a> 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. <\/p><p style=\"margin:0 0 22px;\">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. <\/p><h2 id=\"speicherbudget\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Het opslagbudget en trage replica\u2019s op de juiste manier inschatten<\/h2><p style=\"margin:0 0 22px;\">De achterstand is slechts een deel van het geheel <strong style=\"font-weight:700;color:#153e50;\">Benodigde opslagruimte voor Redis<\/strong>. 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.  <\/p><p style=\"margin:0 0 22px;\">Sinds Redis 7.0 delen de replica-buffer en de replicatie-backlog geheugen. In de INFO-documentatie wordt daarom onder andere vermeld dat <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_clients_slaves<\/code> 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 <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_replication_backlog<\/code> en <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_total_replication_buffers<\/code> in de juiste context en tel overlappende grootheden niet zomaar bij elkaar op.  <\/p><p style=\"margin:0 0 22px;\">Een veelvoorkomende diagnosefout is dat elke afgebroken synchronisatie wordt toegeschreven aan een grote achterstand. Trage replica\u2019s, beperkte netwerkbandbreedte of overschreden limieten voor de uitvoerbuffer kunnen een andere oorzaak hebben. De parameter <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">client-output-buffer-limit replica<\/code> heeft betrekking op de betreffende clientklasse en mag niet worden verward met <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-size<\/code> op \u00e9\u00e9n lijn worden gesteld. Controleer, voordat je limieten wijzigt, de logbestanden, de versiedocumentatie en de te verwachten gevolgen voor andere verbindingen.  <\/p><h2 id=\"hochverfuegbarkeit\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Waarom een grote backlog nog geen hoge beschikbaarheid garandeert<\/h2><p style=\"margin:0 0 22px;\">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 <strong style=\"font-weight:700;color:#153e50;\">Risico op gegevensverlies bij een failover<\/strong> niet.   <\/p><p style=\"margin:0 0 22px;\">Ook <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">WAIT<\/code> maakt een Redis-topologie niet tot een systeem met gegarandeerde sterke consistentie. Het commando kan wachten op bevestigingen van replica\u2019s; de daadwerkelijke gegevensveiligheid blijft afhankelijk van andere omstandigheden, met name van het persistentie- en failover-gedrag. Evenzo beperken <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">min-replicas-to-write<\/code> en <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">min-replicas-max-lag<\/code> onder hun respectieve voorwaarden het accepteren van nieuwe schrijfbewerkingen, zonder elke afzonderlijke bewerking automatisch permanent op meerdere instanties op te slaan.   <\/p><aside class=\"wh-callout wh-callout-warning\" style=\"margin:28px 0;padding:24px 27px;background:#fff7eb;border:1px solid #ecd7b6;border-left:4px solid #bd8738;border-radius:12px;box-shadow:0 5px 18px rgba(45,36,20,.05);\"><p class=\"wh-callout-title\" style=\"margin:0 0 22px;\">Replicatie is geen back-up<\/p><p style=\"margin:0 0 22px;\">Als een primaire server zonder persistentie automatisch opnieuw opstart met een lege dataset, kunnen de replica\u2019s deze lege toestand overnemen. Een grote achterstand vormt geen belemmering voor dit scenario. Zorg daarom voor een gecombineerde beveiliging van herstart, persistentie en herstel; een replica op zich is geen vervanging voor een onafhankelijk bruikbare gegevensback-up.  <\/p><\/aside><p style=\"margin:0 0 22px;\">Voor <strong style=\"font-weight:700;color:#153e50;\">Hoge beschikbaarheid<\/strong> 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.   <\/p><h2 id=\"praxis\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Wijzigingen testen en terugkerende problemen opsporen<\/h2><p style=\"margin:0 0 22px;\">Start een gecontroleerde test in een ge\u00efsoleerde omgeving met een vergelijkbare Redis-versie en een voorspelbare schrijfbelasting. Noteer v\u00f3\u00f3r de onderbreking de replicatie-ID\u2019s, 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.  <\/p><p style=\"margin:0 0 22px;\">Verander per test bij voorkeur slechts \u00e9\u00e9n 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.  <\/p><p style=\"margin:0 0 22px;\">Bij herhaalde volledige resyncs controleer je eerst of de geschiedenis \u00fcberhaupt 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.  <\/p><p style=\"margin:0 0 22px;\">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.  <\/p><section class=\"wh-sources\" style=\"margin-top:50px;padding-top:25px;border-top:1px solid #dce6eb;font-size:14px;color:#607381;\"><h2>Bronnen en stand van zaken op vakgebied<\/h2><p style=\"margin:0 0 22px;\">Stand van het onderzoek: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p style=\"margin:0 0 22px;\">De configuratievoorbeelden zijn gebaseerd op de stabiele Redis-tag 7.2.0, niet op de ontwikkelingsbranch \u2018unstable\u2019. Het beschreven gedeelde geheugengebruik geldt volgens de INFO-documentatie vanaf Redis 7.0. De algemene mechanismen hebben betrekking op Redis Open Source; er worden geen standaardwaarden van Redis-software of de cloud overgenomen. Documentatievergelijking: 21-09-2026. Geen zelf uitgevoerde Redis-laboratoriumtests.<\/p><div class=\"wh-source-lines\" style=\"display:grid;gap:8px;\"><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/psync\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/raw.githubusercontent.com\/redis\/redis\/7.2.0\/redis.conf<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/info\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/config-get\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/config\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/wait\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/sentinel\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/<\/span><\/div><\/section><\/div>","protected":false},"excerpt":{"rendered":"<p>De Redis Replication Backlog houdt een beperkt deel van de replicatiestroom vast. Hierdoor is na korte verbindingsonderbrekingen vaak PSYNC mogelijk in plaats van een volledige resync, maar het is geen vervanging voor persistente gegevensopslag of een doordacht concept voor hoge beschikbaarheid.<\/p>","protected":false},"author":1,"featured_media":21637,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21633","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"surfer_file_name":null,"surfer_file_original_url":null,"_wp_attachment_image_alt":null,"litespeed-optimize-set":null,"litespeed-optimize-size":null,"_oembed_b5e1eb923ad3b086e579b1befcd4075c":null,"_elementor_source_image_hash":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"_source_url":null,"_elementor_migrations_state_8b2d":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":"781","_wh_make_key":"wh_a781989536a2355a2fb50457d779faf2","rank_math_internal_links_processed":"1","_wh_make_topic":"Redis Replication Backlog verstehen","_wh_make_input_keywords":["redis backlog","redis replication","high availability"],"_wh_make_config":{"research_model":"gpt-5.6-terra","writer_model":"gpt-5.6-terra","review_model":"gpt-5.6-sol","image_model":"gpt-image-2.5-flare","image_quality":"medium","image_format":"prefer_avif","final_status":"draft","charts_enabled":true},"_wh_make_links":{"I1":{"id":"I1","post_id":21475,"url":"https:\/\/webhosting.de\/redis-replication-offset-analyse-datenkonsistenz-cluster\/","title":"De replicatie-offset van Redis begrijpen en analyseren voor een hoge gegevensconsistentie","excerpt":"Ik laat zien hoe ik de Redis-offset doelgericht uitlees, analyseer en gebruik voor een hoge gegevensconsistentie. Zo signaleer ik replicatiegaten in een vroeg stadium, beoordeel ik failover-risico\u2019s en houd ik productieve clusters betrouwbaar gesynchroniseerd. Belangrijkste punten De volgende kernpunten bieden een gerichte inleiding tot het onderwerp, de terminologie en de praktische toepassing. De offset meet de voortgang van de replicatiestroom byte voor byte. Lag is het verschil tussen master_repl_offset en slave_repl_offset. ID+offset identificeert een exacte gegevensversie voor gedeeltelijke synchronisaties. Backlog voorkomt volledige synchronisaties bij korte verbindingsonderbrekingen. Monitoring met INFO\/cluster-metriek regelt alarmering en failover. Wat betekent de Redis-replicatie-offset? De replicatie-offset is een doorlopende 64-bits teller die elke overgedragen bytestroom tussen de primaire server en de replica weergeeft. Hieruit kan ik afleiden hoever de replicatie is gevorderd en of een replica nog werk te doen heeft. De `master_repl_offset` op de primaire server stijgt met elke nieuw gegenereerde byte, terwijl de replica haar eigen teller verhoogt zodra ze commando\u2019s heeft toegepast. Verschillen resulteren in een achterstand in bytes en geven aan of de replica achterloopt. Deze eenvoudige, maar effectieve werking maakt de offset tot het centrale getal voor synchronisatie, storingsanalyse en weloverwogen failover-beslissingen. Offsets uitlezen: INFO replication correct gebruiken Ik begin de diagnose bijna altijd met INFO replication, omdat het commando de relevante velden compact weergeeft. Op de primaire server controleer ik master_repl_offset en de status van gekoppelde replica\u2019s, inclusief hun offsets. Op een replica controleer ik bovendien master_link_status en synchronisatiestatus om lopende volledige synchronisaties of gedeeltelijke synchronisaties te herkennen. Voor een diepgaandere analyse maak ik gebruik van gestructureerde uitvoer en breng ik offsets in verband met CPU-, I\/O- en netwerkwaarden. Deze handleiding biedt mij een gedegen inleiding in het commando: Redis INFO voor monitoring. Replication ID + Offset: unieke gegevensversie Voor een unieke versie gebruik ik de combinatie van Replication ID en Offset. De ID markeert een geschiedenis, de offset een positie binnen de"},"I2":{"id":"I2","post_id":21597,"url":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":"De prestaties van de vervaldatum van Redis-sleutels analyseren en optimaliseren","excerpt":"Ik analyseer de prestaties van Redis Key Expiration doelgericht en optimaliseer deze met duidelijke, meetbare stappen. Zo verminder ik de latentie, vlak ik pieken in de belasting af en houd ik het geheugengebruik onder controle, zonder de doorvoer in gevaar te brengen. Kernpunten Ik vat de belangrijkste aspecten van de expiratieprestaties zo samen dat beginners direct aan de slag kunnen en gevorderden gericht kunnen finetunen. De volgende kernpunten richten zich op de meest effectieve instellingen en laten zien waar typische knelpunten ontstaan. Daarbij richt ik me op TTL-strategie\u00ebn, actieve en passieve opschoning en eviction-gedrag. Daarnaast introduceer ik monitoringkengetallen die problemen in een vroeg stadium zichtbaar maken. Zo kan de prestatie systematisch worden ge\u00ebvalueerd en duurzaam worden beheerd. Lazy versus actieve vervaltermijn: de wisselwerking begrijpen en meten TTL-spreiding: offsets tegen gelijktijdig verlopen hz-tuning: De frequentie van de achtergrondcycli in evenwicht brengen Eviction-beleid: allkeys-lru versus volatile-varianten Monitoring: verval-, eviction- en latentiewaarden observeren Ik zet in op consistente TTL\u2019s, adaptieve opschoning en duidelijke drempelwaarden. Op deze manier spreid ik vervaltijdstippen, voorkom ik onnodige verwijderingen en houd ik de responstijden betrouwbaar laag. Daarnaast gebruik ik statistieken die opvallende fasen onmiddellijk signaleren en nauwkeurige tegenmaatregelen mogelijk maken. Redis-sleutelvervaldatum: werking en invloed op de latentie Redis combineert \u2018lazy\u2019 en \u2018active\u2019 expiratie om hoge snelheid te combineren met een beperkte CPU-belasting. Bij \u2018lazy\u2019 expiratie verwijdert de server sleutels pas bij toegang, wanneer de TTL is verstreken. Daardoor zijn er geen extra achtergrondbewerkingen nodig voor gegevens die toch al regelmatig worden gelezen. Actieve vervaltermijn vult het model aan met korte, frequente scans van de sleutels waarvan de vervaltermijn afloopt, om vergeten vermeldingen te verwijderen. Deze architectuur houdt de latentie laag en maakt geheugen vrij zonder dure, permanente scans. Er ontstaat vooral merkbare latentie wanneer zeer veel vermeldingen binnen een kort tijdsbestek verlopen. Dan besteedt Redis meer CPU-capaciteit aan actieve opschoning, wat de capaciteit voor clientbewerkingen tijdelijk vermindert. Extra druk op het geheugen v"},"I3":{"id":"I3","post_id":21547,"url":"https:\/\/webhosting.de\/redis-expire-strategien-grosse-cache-systeme-cache-architektur\/","title":"Redis-vervaldatumstrategie\u00ebn voor grote cachesystemen: praktische gids voor prestatieoptimalisatie","excerpt":"Grote cacheclusters leiden zonder doordachte Redis-vervalstrategie\u00ebn al snel tot geheugenbottlenecks en schommelende latenties; ik laat je zien hoe je TTL, eviction en invalidatie zo kunt combineren dat piekbelastingen worden voorkomen. Ik geef concrete best practices voor sleutelontwerp, vervaltijden en monitoring die betrouwbaar werken in productieve omgevingen. Belangrijke punten: de scheiding tussen verval en verwijdering consequent begrijpen en configureren; overal TTL instellen, plus jitter combineren met ongeldigverklaring tegen het \u201ethundering herd\u201c-effect: Delete-on-write, tags, versiebeheer; het eviction-beleid bewust kiezen en testen met maxmemory; monitoring richten op verlopen\/verwijderde sleutels, hit-rate en latenties; verval versus eviction: Hoe Redis verwijdert In mijn planning maak ik altijd een duidelijk onderscheid tussen verval en verwijdering, omdat beide processen verschillende doelen nastreven. Verval verwijdert sleutels wanneer de TTL is verstreken, terwijl verwijdering alleen in werking treedt wanneer de geconfigureerde opslagruimte is opgebruikt. Bij elke toegang controleert Redis via Lazy-Expiration of een sleutel verlopen is, en ruimt daarnaast actief met tussenpozen willekeurig geselecteerde vermeldingen op. Deze gemengde aanpak voorkomt timer-overhead per sleutel en houdt de beheersinspanning laag. Wie dit mechanisme begrijpt, kan doelgericht bepalen hoeveel \u201edood\u201c geheugen op korte termijn wordt getolereerd, zonder onverwachte cache-misses te veroorzaken. TTL-ontwerp: tijden, jitter en tiering Ik geef elke cache-sleutel een TTL, zelfs als ik expliciete invalidatie gebruik, omdat een vervaltijd een belangrijk vangnet vormt. Voor gebruikersgerichte gegevens begin ik vaak met 5\u201315 minuten, maar pas het interval aan aan de wijzigingsfrequentie en de tolerantie voor \u2018stale reads\u2019. Sessies krijgen korte looptijden, productdetails eerder langere, configuraties nog meer speelruimte; zo spreid ik het risico en egaliseer ik de belasting. Daarnaast voeg ik een lichte jitter toe, bijvoorbeeld \u00b110 %, zodat niet duizenden sleutels tegelijkertijd aflopen. In caches met meerdere lagen laat ik het app-geheugen in seconden werken, Redis in minuten tot uren, en houd ik de bovenliggende lagen langer actief om dure reconstructies te vermijden. Expliciete ongeldigverklaring zonder neveneffecten T"}},"_wh_make_stage":"pruefung","_wh_make_research_date":"2026-09-21","_wh_make_sitemap_info":{"index":"https:\/\/webhosting.de\/sitemap_index.xml","sitemaps":["https:\/\/webhosting.de\/post-sitemap1.xml","https:\/\/webhosting.de\/post-sitemap2.xml","https:\/\/webhosting.de\/post-sitemap3.xml","https:\/\/webhosting.de\/post-sitemap4.xml"],"url_count":3091,"fetched_at":"2026-09-21T16:17:16+00:00","selected_ids":[21475,21597,21547]},"_wh_make_draft_hash":"cdd03f169db2ce62837f8c9e05cbc557528cf04eb9858b9669fb83ad3a8cf0e1","_wh_make_work":null,"_wh_make_research":"## Recherchebriefing: Redis Replication Backlog verstehen  \n**Kategorie:** Datenbanken \u00b7 **Recherchezeitpunkt:** 21. September 2026  \n**Keywords:** \u201eredis backlog\u201c, \u201eredis replication\u201c, \u201ehigh availability\u201c \u2013 alle drei passen fachlich direkt. Der Fokus sollte klar auf **Redis Open Source** liegen; Redis Software\/Cloud verwendet teils abweichende, shardbezogene Backlog-Mechanismen und Defaultwerte.\n\n### Leserfrage\n**Was speichert der Redis Replication Backlog, wann erm\u00f6glicht er eine partielle Resynchronisierung (PSYNC), wie wird seine Gr\u00f6\u00dfe sinnvoll bestimmt \u2013 und weshalb ist er ein HA-Baustein, aber keine Garantie gegen Datenverlust?**\n\n---\n\n## Gesicherte Aussagen\n\n1. **Der Replication Backlog ist ein Speicherpuffer f\u00fcr den Replikationsdatenstrom, nicht eine zweite Datenbankkopie.**  \n   Ein Primary erzeugt einen Replikationsstrom aus Datensatz\u00e4nderungen. Rei\u00dft die Verbindung zu einer Replica ab, kann diese beim Wiederverbinden \u00fcber `PSYNC` ihre bekannte Replikations-ID und ihren zuletzt verarbeiteten Offset mitteilen. Liegt der fehlende Abschnitt noch im Backlog und ist die Replikationshistorie g\u00fcltig, liefert Redis nur die fehlenden Daten nach (*partial resynchronization*). Andernfalls erfolgt ein Full Resync: Snapshot erzeugen, RDB \u00fcbertragen, danach zwischengespeicherte \u00c4nderungen nachliefern. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))\n\n2. **Der entscheidende Grenzwert ist nicht eine \u201emaximale Ausfallzeit\u201c an sich, sondern die w\u00e4hrend des Ausfalls erzeugte Menge des Replikationsstroms.**  \n   `repl-backlog-size` begrenzt die vorgehaltene Datenmenge. Ein gr\u00f6\u00dferer Backlog kann eine l\u00e4ngere oder schreibintensivere Unterbrechung \u00fcberbr\u00fccken; ist der erforderliche Offset \u00e4lter als `repl_backlog_first_byte_offset`, ist PSYNC nicht mehr m\u00f6glich. Redis dokumentiert daf\u00fcr die Statusfelder `repl_backlog_size`, `repl_backlog_first_byte_offset` und `repl_backlog_histlen`. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n3. **Replikations-ID und Offset geh\u00f6ren zusammen.**  \n   Der Offset steigt f\u00fcr jedes Byte des Replikationsstroms, auch wenn gerade keine Replica verbunden ist. Erst das Paar aus Replikations-ID und Offset kennzeichnet einen konkreten Stand einer Datenhistorie. Nach einem Failover bewahrt eine bef\u00f6rderte Replica zus\u00e4tzlich die vorherige ID als sekund\u00e4re ID auf. Das kann partielle Synchronisationen weiterer Replicas nach dem Failover erm\u00f6glichen. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))\n\n4. **Redis-Replikation ist standardm\u00e4\u00dfig asynchron; der Backlog macht daraus keine synchrone oder strikt konsistente Replikation.**  \n   Ein Backlog senkt vor allem die Wahrscheinlichkeit teurer Full Resyncs nach kurzzeitigen Unterbrechungen. Datenverlust bei Primary-Ausfall bleibt grunds\u00e4tzlich m\u00f6glich. `WAIT` kann Best\u00e4tigungen von Replicas anfordern, schafft aber laut Redis keine CP- bzw. Strong-Consistency-Garantie. F\u00fcr eine begrenzte Annahme von Writes lassen sich au\u00dferdem `min-replicas-to-write` und `min-replicas-max-lag` einsetzen; auch diese Einstellung garantiert nicht, dass die geforderte Zahl von Replicas den konkreten Write dauerhaft \u00fcbernommen hat. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai))\n\n5. **Die Beispielkonfiguration nennt f\u00fcr OSS einen Backlog von 1 MiB und eine TTL von 3.600 Sekunden \u2013 das sind nicht automatisch passende Produktionswerte.**  \n   Der Backlog wird laut Beispielkonfiguration auf einem Primary erst angelegt, wenn mindestens eine Replica verbunden ist. Nach Trennung der letzten Replica wird er nach `repl-backlog-ttl` freigegeben; `0` bedeutet, ihn nicht automatisch freizugeben. Replicas geben den Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter zum Primary bef\u00f6rdert werden k\u00f6nnten. Die offizielle Betriebsdokumentation empfiehlt nur qualitativ einen \u201enicht trivialen\u201c Backlog proportional zum Speicherbedarf \u2013 keine allgemeine Formel oder universelle Prozentzahl f\u00fcr Redis OSS. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))\n\n---\n\n## Vergleichstabelle als Datenbasis\n\n| Aspekt | Redis Open Source | Redis Software (Dokumentation 7.8) | Redaktionelle Einordnung |\n|---|---|---|---|\n| Einheit des Backlogs | Pro Redis-Instanz \/ Replikationsstrom | Pro Shard | Nicht vermischen: Architektur und Stellgr\u00f6\u00dfen unterscheiden sich. |\n| Konfiguration | `repl-backlog-size`, `repl-backlog-ttl` in `redis.conf` | `rladmin tune db \u2026 repl_backlog \u2026` bzw. `auto` | OSS-Konfigurationsbeispiele sind nicht auf Redis Software \u00fcbertragbar. |\n| Dokumentierter Default | Beispielwert: `1mb`; als auskommentierte Vorlage | `auto`: 1 % der DB-Gr\u00f6\u00dfe \/ Shardzahl, min. 1 MB, max. 250 MB pro Shard | Die 1-%-Regel gilt **nicht** als OSS-Empfehlung. |\n| Zweck | PSYNC nach kurzzeitiger Unterbrechung | Synchronisierung von Primary- und Replica-Shards | In beiden F\u00e4llen: Full Syncs vermeiden bzw. reduzieren. |\n| HA-Aussage | Asynchrone Replikation, keine automatische Konsistenzgarantie | Produkt-\/Plattformfunktion mit eigener Steuerung | Backlog ist nur ein Element eines HA-Konzepts. |\n\nOSS-Details und Konfigurationssemantik: ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf)) Redis-Software-Angaben, ausdr\u00fccklich versionsgebunden an die 7.8-Dokumentation: ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai))\n\n---\n\n## Belegtes Konfigurations- und Beobachtungsbeispiel\n\n```conf\n# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600\n```\n\nDiese Werte sind **Vorlagenwerte**, keine Kapazit\u00e4tsempfehlung. `repl-backlog-ttl 0` verhindert die automatische Freigabe nach dem Verlust aller Replicas. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))\n\nF\u00fcr das Monitoring ist die belastbare Basis:\n\n```text\nINFO replication\n```\n\nRelevante Felder:  \n- `master_repl_offset`: aktueller Offset des Primary,  \n- `repl_backlog_first_byte_offset`: \u00e4ltester noch vorgehaltener Byte-Offset,  \n- `repl_backlog_histlen`: aktuell bef\u00fcllte Historienl\u00e4nge,  \n- `repl_backlog_size`: konfigurierte Backlog-Gr\u00f6\u00dfe,  \n- auf einer Replica: `master_link_status`, `slave_repl_offset` und bei Unterbrechung `master_link_down_since_seconds`. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n---\n\n## Rechenbeispiel \u2013 als Planungsn\u00e4herung, nicht als Redis-Garantie\n\n**Annahme:** Der Replikationsstrom erzeugt im beobachteten Spitzenzeitraum durchschnittlich 12 MiB\/s. Eine Replica soll einen Netzwerkausfall von 90 Sekunden \u00fcberstehen; zus\u00e4tzlich werden 30 Sekunden Sicherheitsreserve eingeplant.\n\n\\[\n\\text{Backlog} \\ge 12\\ \\text{MiB\/s} \\times (90 + 30)\\ \\text{s} = 1{.}440\\ \\text{MiB}\n\\]\n\n**Ergebnis:** Mindestens rund **1,41 GiB** Backlog, zuz\u00fcglich einer betrieblich festzulegenden Reserve f\u00fcr Messungenauigkeit und Lastspitzen. Entscheidend ist, die Rate aus tats\u00e4chlich beobachteten Offsets \u00fcber Zeit abzuleiten, nicht aus Client-Operationen pro Sekunde: Replikationsdaten sind byteorientiert und Befehlsgr\u00f6\u00dfe, Werte, TTL-\/L\u00f6schoperationen sowie Pipelines beeinflussen das Volumen.\n\n---\n\n## Technische Stolperstellen\n\n- **Backlog \u2260 Replica-Output-Buffer.** W\u00e4hrend eines Full Sync kann die Replica den Replikationsstrom zus\u00e4tzlich puffern; `replica-full-sync-buffer-limit` und auf der Primary-Seite `client-output-buffer-limit replica` sind getrennte Schutzmechanismen. Ein gr\u00f6\u00dferer Backlog l\u00f6st kein Speicherproblem eines langsamen oder beim Full Sync \u00fcberforderten Replica-Knotens. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))  \n- **Full Resync ist teuer:** Er umfasst RDB-Erzeugung\/-Transfer und kann bei schreibintensiven Instanzen zus\u00e4tzlichen Speicherbedarf verursachen. Redis weist allgemein darauf hin, dass RDB-Save oder AOF-Rewrite in Write-lastigen Szenarien bis zu etwa dem Doppelten des regul\u00e4r genutzten Speichers beanspruchen kann; dies ist bei Kapazit\u00e4tsplanung von Replikation relevant. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/))  \n- **Keine Replica verbunden:** In OSS wird der Backlog erst bei mindestens einer verbundenen Replica angelegt. Nach Ablauf der TTL ohne Replicas fehlt somit Historie f\u00fcr eine sp\u00e4tere PSYNC-Anfrage. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))  \n- **Failover und Neustarts:** Redis 4.0+ unterst\u00fctzt Partial Sync nach Failover mithilfe der zweiten Replikations-ID. Ein sauber per `SHUTDOWN` mit RDB beendeter Replica-Neustart kann ebenfalls PSYNC beg\u00fcnstigen; ein Neustart \u00fcber AOF kann dies laut Redis nicht. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))  \n- **Memory Budget:** Seit Redis 7.0 teilen Replica-Buffer und Backlog Speicher; deshalb kann `mem_clients_slaves` trotz vorhandener Replicas null anzeigen. F\u00fcr die Gesamtbetrachtung sind auch `mem_replication_backlog` und `mem_total_replication_buffers` relevant. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n---\n\n## Chart-Vorschlag\n**Kein Chart** f\u00fcr eine pauschale Gr\u00f6\u00dfenempfehlung: Es existiert f\u00fcr Redis OSS keine belastbare, universelle Prozentregel. Sinnvoll w\u00e4re allenfalls eine installationsspezifische Zeitreihe \u201eReplikationsrate in MiB\/s\u201c gegen \u201eBacklog-Reichweite in Sekunden\u201c, sofern eigene Messdaten aus `master_repl_offset` vorliegen.\n\n## Offene Unsicherheiten\n- Die Dokumentation beschreibt aktuelle Redis-OSS-Funktionen, benennt aber keine feste Redis-Releaseversion f\u00fcr jede Konfigurationszeile; das konsultierte `redis.conf` stammt aus dem **unstable**-Branch und darf daher nur als aktuelle Vorlage, nicht als r\u00fcckwirkender Versionsbeleg verwendet werden.  \n- F\u00fcr eine konkrete Sollgr\u00f6\u00dfe fehlen Angaben zu Redis-Version, Write-Volumen in Bytes, maximal tolerierter Netzunterbrechung, Anzahl\/Topologie der Replicas, Persistence-Modus und verf\u00fcgbarem RAM.  \n- Falls der Beitrag Redis Cluster, Sentinel oder Managed-Angebote behandeln soll, m\u00fcssen deren Failover- und Backlog-Eigenschaften getrennt recherchiert werden; sie sind nicht identisch mit dem OSS-Primary\/Replica-Grundmodell.","_wh_make_sources":{"S1":{"id":"S1","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/","title":"Redis-replicatie | Documentatie"},"S2":{"id":"S2","url":"https:\/\/redis.io\/docs\/latest\/commands\/info\/","title":"INFO | Documenten"},"S3":{"id":"S3","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai","title":"Redis-replicatie | Documentatie"},"S4":{"id":"S4","url":"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf","title":"redis\/redis.conf op unstable \u00b7 redis\/redis \u00b7 GitHub"},"S5":{"id":"S5","url":"https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai","title":"Databasereplicatie | Documentatie"},"S6":{"id":"S6","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/","title":"Redis-beheer | Documentatie"}},"_wh_make_usage":{"research":{"input_tokens":33913,"output_tokens":2950,"response_id":"resp_05ee82f48a6cf6a8016ab1588e2d0887d2ade8a873a2317cd3","model":"gpt-5.6-terra","search_calls":4},"writer":{"input_tokens":6454,"output_tokens":4402,"response_id":"resp_0bb89d09c2020060016ab158bbc8b887d2a0f30d74eb8a02e2","model":"gpt-5.6-terra","search_calls":0},"review":{"input_tokens":38942,"output_tokens":1614,"response_id":"resp_03de38f1242fe83b016ab158f85b3487d29cb99dc36fa7d399","model":"gpt-5.6-sol","search_calls":3}},"_wh_make_last_error":null,"_wh_make_write_intent":null,"_wh_make_design_version":"2.0.4","rank_math_title":"Redis Replication Backlog verstehen und richtig planen","_wh_make_doc":{"title":"Inzicht in de replicatie-achterstand van Redis: PSYNC, omvang en HA-beperkingen","slug":"de-replicatie-achterstand-van-redis-begrijpen","excerpt":"De Redis Replication Backlog houdt een beperkt deel van de replicatiestroom vast. Hierdoor is na korte verbindingsonderbrekingen vaak PSYNC mogelijk in plaats van een volledige resync, maar het is geen vervanging voor persistente gegevensopslag of een doordacht concept voor hoge beschikbaarheid.","seo":{"title":"De replicatie-achterstand van Redis begrijpen en goed plannen","description":"Ontdek wat er in de Redis Replication Backlog wordt opgeslagen, hoe PSYNC werkt, hoe je de omvang kunt bepalen en welke beperkingen gelden voor hoge beschikbaarheid.","focus_keyword":"Redis Replication Backlog"},"lead":[{"kind":"text","text":"Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. ","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"text","text":"Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. ","ref":""},{"kind":"citation","text":"","ref":"S3"}],"sections":[{"id":"grundprinzip","heading":"Was der Backlog speichert \u2013 und was nicht","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"psync-grenze","heading":"Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auf dem Primary beschreibt ","ref":""},{"kind":"code","text":"repl_backlog_first_byte_offset","ref":""},{"kind":"text","text":" den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. ","ref":""},{"kind":"code","text":"repl_backlog_histlen","ref":""},{"kind":"text","text":" zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; ","ref":""},{"kind":"code","text":"repl_backlog_size","ref":""},{"kind":"text","text":" ist die konfigurierte Obergrenze. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"table","caption":"Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica","headers":["Situation","ID und Offset","Ergebnis","Betriebliche Folge"],"rows":[["Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog","Historie g\u00fcltig, Offset abgedeckt","Partielle Resynchronisierung per PSYNC","Nur die L\u00fccke wird \u00fcbertragen"],["Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite","Angeforderter Offset \u00e4lter als der erste Backlog-Offset","Full Resync","RDB-Transfer und Nachlieferung laufender \u00c4nderungen"],["Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie","Sekund\u00e4re Replikations-ID kann passen","PSYNC kann m\u00f6glich sein","Abh\u00e4ngig von Historie und vorgehaltenem Bereich"],["Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen","Kein nutzbarer Backlog vorhanden","Sp\u00e4tere Replica ben\u00f6tigt Full Resync","Historie wurde automatisch freigegeben"]],"source_ids":["S1","S2","S4"]}]},{"id":"groesse-planen","heading":"Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt ","ref":""},{"kind":"code","text":"master_repl_offset","ref":""},{"kind":"text","text":" und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet ","ref":""},{"kind":"code","text":"12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB","ref":""},{"kind":"text","text":". Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann ","ref":""},{"kind":"code","text":"mem_clients_slaves","ref":""},{"kind":"text","text":" trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere ","ref":""},{"kind":"code","text":"mem_replication_backlog","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"mem_total_replication_buffers","ref":""},{"kind":"text","text":" relevant. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]},{"id":"konfiguration","heading":"Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"code","language":"conf","code":"# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600","source_ids":["S4"]},{"type":"paragraph","runs":[{"kind":"text","text":"In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt ","ref":""},{"kind":"code","text":"repl-backlog-ttl","ref":""},{"kind":"text","text":" an, wann Redis ihn freigibt. Der Wert ","ref":""},{"kind":"code","text":"0","ref":""},{"kind":"text","text":" verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. ","ref":""},{"kind":"citation","text":"","ref":"S5"}]}]},{"id":"monitoring-und-grenzen","heading":"Monitoring und die Grenzen f\u00fcr High Availability","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Beginne die Diagnose mit folgendem Befehl:","ref":""}]},{"type":"code","language":"text","code":"INFO replication","source_ids":["S2"]},{"type":"paragraph","runs":[{"kind":"text","text":"Auf dem Primary pr\u00fcfst du ","ref":""},{"kind":"code","text":"master_repl_offset","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"repl_backlog_first_byte_offset","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"repl_backlog_histlen","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"repl_backlog_size","ref":""},{"kind":"text","text":". Auf einer Replica sind ","ref":""},{"kind":"code","text":"master_link_status","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"slave_repl_offset","ref":""},{"kind":"text","text":" sowie bei Unterbrechungen ","ref":""},{"kind":"code","text":"master_link_down_since_seconds","ref":""},{"kind":"text","text":" aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: ","ref":""},{"kind":"code","text":"replica-full-sync-buffer-limit","ref":""},{"kind":"text","text":" begrenzt den Puffer auf Replica-Seite, ","ref":""},{"kind":"code","text":"client-output-buffer-limit replica","ref":""},{"kind":"text","text":" betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. ","ref":""},{"kind":"citation","text":"","ref":"S3"},{"kind":"text","text":" ","ref":""},{"kind":"code","text":"WAIT","ref":""},{"kind":"text","text":" kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. ","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auch ","ref":""},{"kind":"code","text":"min-replicas-to-write","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"min-replicas-max-lag","ref":""},{"kind":"text","text":" begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden ","ref":""},{"kind":"internal_link","text":"Redis Replication Offset analysieren","ref":"I1"},{"kind":"text","text":" weiterhelfen.","ref":""}]}]}],"images":{"hero":{"prompt":"Editoriale, realistische technische Illustration f\u00fcr einen Fachartikel: ein Redis-Primary als zentraler Knoten links sendet einen leuchtenden Datenstrom zu zwei Replica-Knoten rechts. Im Datenstrom befindet sich ein deutlich erkennbarer ringf\u00f6rmiger Pufferspeicher, der j\u00fcngere Datenabschnitte h\u00e4lt; eine kurz getrennte Verbindung zu einer Replica wird wieder geschlossen und der fehlende Abschnitt flie\u00dft nach. Dunkler, ruhiger Serverraum-Hintergrund, klare r\u00e4umliche Trennung der Komponenten, Rot- und warme Akzentfarben, keine Markenlogos. Keine W\u00f6rter, Zahlen, Labels, Diagrammlegenden oder UI-Screenshots.","alt":"Illustration eines Primary mit ringf\u00f6rmigem Replikationspuffer und zwei wieder angebundenen Redis-Replicas.","caption":"Illustrative Darstellung: Der Backlog h\u00e4lt einen j\u00fcngeren Abschnitt des Replikationsstroms f\u00fcr wiederkehrende Replicas vor.","filename_base":"redis-backlog-psync","section_id":"","after_block":0},"detail1":{"prompt":"Klare konzeptionelle Illustration einer horizontalen Zeitachse f\u00fcr Redis-Replikation: links ein \u00e4lterer, verblassender Datenstrom, in der Mitte ein begrenzter ringf\u00f6rmiger Speicherbereich mit sichtbaren j\u00fcngeren Datenpaketen, rechts neue Datenpakete. Eine Replica-Verbindung setzt an einer Position innerhalb des Ringbereichs wieder ein, eine zweite gestrichelte Verbindung versucht weit links au\u00dferhalb des Ringbereichs anzusetzen und wird in einen vollst\u00e4ndigen Datentransfer \u00fcbergeleitet. Visuell intuitiv, technische Vektor-\u00c4sthetik, keine Beschriftungen, W\u00f6rter, Zahlen, Legenden oder Marken.","alt":"Zeitachsenillustration mit verf\u00fcgbarem Backlog-Bereich und einer zu alten Replikationsl\u00fccke.","caption":"Illustrative Darstellung: Ob PSYNC gelingt, h\u00e4ngt davon ab, ob der ben\u00f6tigte Offset noch im vorgehaltenen Bereich liegt.","filename_base":"redis-psync-offset-range","section_id":"psync-grenze","after_block":2},"detail2":{"prompt":"Technische konzeptionelle Illustration zur Speicherkapazit\u00e4tsplanung: ein Server-Speichercontainer ist in mehrere farbige, unterschiedlich gro\u00dfe Bereiche gegliedert, darunter ein wachsender Replikationspuffer und getrennte Puffer f\u00fcr Replica-Daten. Daneben flie\u00dft ein variabler Strom aus Datenpaketen in den Replikationspuffer; eine kurze Unterbrechung wird durch den gespeicherten Abschnitt \u00fcberbr\u00fcckt. Fokus auf Verh\u00e4ltnis von Datenrate, Unterbrechungsdauer und RAM-Budget, ohne exakte Messskalen. Sachliche isometrische Vektorillustration, keine W\u00f6rter, Zahlen, Labels, Legenden, Logos oder erfundene Dashboards.","alt":"Illustration eines Server-Speicherbudgets mit Replikationsbacklog und getrennten Replica-Puffern.","caption":"Illustrative Darstellung: Die Backlog-Gr\u00f6\u00dfe wird aus Datenrate und gew\u00fcnschter \u00dcberbr\u00fcckungszeit geplant und dem RAM-Budget gegen\u00fcbergestellt.","filename_base":"redis-backlog-memory-budget","section_id":"groesse-planen","after_block":3}},"chart":null,"social":{"facebook":"Redis Backlog richtig planen: Wann PSYNC gelingt und warum der Puffer keine Datenverlustgarantie ist.","instagram":"PSYNC statt Full Resync: So h\u00e4ngt die Redis-Backlog-Gr\u00f6\u00dfe von Byte-Rate und Ausfallzeit ab.","tiktok":"Redis Backlog erkl\u00e4rt: Warum Sekunden allein nicht entscheiden, ob PSYNC funktioniert.","youtube":"Redis Replication Backlog: PSYNC, Dimensionierung und Grenzen f\u00fcr HA verst\u00e4ndlich erkl\u00e4rt.","threads":"Der Redis Backlog puffert Replikationsbytes, nicht deine Datenbank. Entscheidend sind Offset, Historie und Schreibrate.","x":"Redis Replication Backlog: PSYNC klappt nur, wenn ID, Offset und vorgehaltener Bytebereich zusammenpassen. Gr\u00f6\u00dfe nach Replikationsrate und \u00dcberbr\u00fcckungszeit planen \u2013 nicht nach pauschalen Prozentwerten."},"avatar_script":"Der Redis Replication Backlog ist ein Speicherpuffer f\u00fcr einen begrenzten Teil des Replikationsstroms. F\u00e4llt die Verbindung einer Replica kurz aus, kann sie ihre Replikations-ID und ihren letzten Offset melden. Liegen die fehlenden Bytes noch im Backlog, liefert Redis sie per PSYNC nach. Andernfalls ist ein Full Resync mit RDB-\u00dcbertragung erforderlich. F\u00fcr die Gr\u00f6\u00dfe z\u00e4hlt nicht nur die Dauer einer Unterbrechung, sondern vor allem die dabei erzeugte Datenmenge. Miss deshalb den Offset-Zuwachs \u00fcber die Zeit und plane Reserve ein. Der Backlog reduziert teure Neuabgleiche, macht die asynchrone Replikation aber nicht verlustfrei. Pr\u00fcfe zus\u00e4tzlich Speicherbudget, Replica-Buffer, Persistenz und Failover-Abl\u00e4ufe.","version_note":"Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer."},"_wh_make_word_report":{"words":1011,"min":2000,"max":3000,"target":2500,"ok":false,"missing":989,"excess":0,"lead_words":55,"section_words":{"grundprinzip":166,"psync-grenze":256,"groesse-planen":192,"konfiguration":136,"monitoring-und-grenzen":206}},"_wh_make_review":{"verdict":"needs_review","issues":["Abschnitt \u201emonitoring-und-grenzen\u201c, Block 4: Die Aussage stellt `replica-full-sync-buffer-limit` als allgemein verf\u00fcgbaren Redis-OSS-Schutzmechanismus dar. Die zugeordnete Quelle S4 verweist jedoch auf den unversionierten Entwicklungszweig `unstable`; die Direktive ist dort belegt, aber damit nicht automatisch f\u00fcr alle vom Artikel abgedeckten Redis-Versionen. Korrekturrichtung: eine konkrete unterst\u00fctzte Redis-Version beziehungsweise einen stabilen Release-Beleg nennen oder die Direktive aus dem versions\u00fcbergreifenden Text entfernen und nur `client-output-buffer-limit replica` allgemein behandeln.","Abschnitt \u201ekonfiguration\u201c, Bl\u00f6cke 1\u20132: Der Text bezeichnet `repl-backlog-size 1mb` und `repl-backlog-ttl 3600` als Werte der mitgelieferten Vorlage, w\u00e4hrend S4 beide Zeilen auskommentiert zeigt. Der Codeblock stellt sie dagegen als aktive Konfiguration dar. Korrekturrichtung: die Kommentarzeichen aus der Vorlage \u00fcbernehmen oder ausdr\u00fccklich kennzeichnen, dass die Zeilen zur Demonstration aktiviert wurden. Au\u00dferdem sollte f\u00fcr produktbezogene Versionsaussagen statt des beweglichen `unstable`-Branches ein passender stabiler Release- oder Tag-Beleg verwendet werden.","Bild \u201edetail2\u201c zum Abschnitt \u201egroesse-planen\u201c: Prompt und Alt-Text visualisieren Backlog und Replica-Puffer als getrennte Speicherbereiche. Das kann der unmittelbar davor erl\u00e4uterten Redis-7.0+-Eigenschaft widersprechen, nach der Replica-Buffer Speicher mit dem Replication Backlog teilen. Korrekturrichtung: einen gemeinsam genutzten Replikationsspeicherbereich mit logisch unterscheidbaren Belegungen darstellen oder die Illustration ausdr\u00fccklich als versionsunabh\u00e4ngiges, rein logisches Modell kennzeichnen.","Artikelweite Versionsabgrenzung: Der Beitrag beansprucht Redis Open Source allgemein, kombiniert aber stabile, seit Redis 4.0 beziehungsweise 7.0 dokumentierte Eigenschaften mit einer Direktive aus `unstable`. Die `version_note` erw\u00e4hnt diese Einschr\u00e4nkung nicht. Korrekturrichtung: getesteten beziehungsweise dokumentierten Versionsbereich festlegen und entwicklungszweigspezifische Funktionen gesondert markieren. Die \u00fcbrigen Kernaussagen zu PSYNC, ID und Offset, Backlog-Feldern, asynchroner Replikation sowie Redis Software 7.8 werden von den gepr\u00fcften Quellen gest\u00fctzt; das Rechenbeispiel 1.440 MiB \u2248 1,41 GiB ist korrekt und als Planungsn\u00e4herung gekennzeichnet."],"checked_source_ids":["S1","S2","S3","S4","S5"],"summary":"Automatische Pr\u00fcfung: Die fachliche Kerndarstellung und die Gr\u00f6\u00dfenrechnung sind \u00fcberwiegend schl\u00fcssig. \u00dcberarbeitet werden m\u00fcssen vor allem die nicht versionsgebundene Verwendung einer nur \u00fcber `unstable` belegten Direktive, die Darstellung auskommentierter Vorlagenwerte als aktive Konfiguration und die missverst\u00e4ndliche Speicherillustration. Dieses Ergebnis ist keine Garantie auf Fehlerfreiheit."},"_wh_make_review_doc_hash":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"inline_featured_image":null,"_yoast_wpseo_linkdex":null,"_eael_widget_elements":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_trp_translated_slug_en_us":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_wh_make_writer_raw":"{\"title\":\"Redis Replication Backlog verstehen: PSYNC, Gr\u00f6\u00dfe und HA-Grenzen\",\"slug\":\"redis-replication-backlog-verstehen\",\"excerpt\":\"Der Redis Replication Backlog h\u00e4lt einen begrenzten Ausschnitt des Replikationsstroms vor. Er erm\u00f6glicht nach kurzen Verbindungsabbr\u00fcchen oft PSYNC statt Full Resync, ersetzt aber weder persistente Datenhaltung noch ein durchdachtes Hochverf\u00fcgbarkeitskonzept.\",\"seo\":{\"title\":\"Redis Replication Backlog verstehen und richtig planen\",\"description\":\"Erfahre, was der Redis Replication Backlog speichert, wie PSYNC funktioniert, wie du die Gr\u00f6\u00dfe planst und welche Grenzen f\u00fcr High Availability gelten.\",\"focus_keyword\":\"Redis Replication Backlog\"},\"lead\":[{\"kind\":\"text\",\"text\":\"Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. \" ,\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"},{\"kind\":\"text\",\"text\":\"Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"}],\"sections\":[{\"id\":\"grundprinzip\",\"heading\":\"Was der Backlog speichert \u2013 und was nicht\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]}]},{\"id\":\"psync-grenze\",\"heading\":\"Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.\",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auf dem Primary beschreibt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_first_byte_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_histlen\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_size\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" ist die konfigurierte Obergrenze. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"table\",\"caption\":\"Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica\",\"headers\":[\"Situation\",\"ID und Offset\",\"Ergebnis\",\"Betriebliche Folge\"],\"rows\":[[\"Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog\",\"Historie g\u00fcltig, Offset abgedeckt\",\"Partielle Resynchronisierung per PSYNC\",\"Nur die L\u00fccke wird \u00fcbertragen\"],[\"Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite\",\"Angeforderter Offset \u00e4lter als der erste Backlog-Offset\",\"Full Resync\",\"RDB-Transfer und Nachlieferung laufender \u00c4nderungen\"],[\"Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie\",\"Sekund\u00e4re Replikations-ID kann passen\",\"PSYNC kann m\u00f6glich sein\",\"Abh\u00e4ngig von Historie und vorgehaltenem Bereich\"],[\"Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen\",\"Kein nutzbarer Backlog vorhanden\",\"Sp\u00e4tere Replica ben\u00f6tigt Full Resync\",\"Historie wurde automatisch freigegeben\"]],\"source_ids\":[\"S1\",\"S2\",\"S4\"]}]},{\"id\":\"groesse-planen\",\"heading\":\"Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.\",\"ref\":\"\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\". Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.\",\"ref\":\"\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_clients_slaves\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_replication_backlog\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_total_replication_buffers\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" relevant. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]}]},{\"id\":\"konfiguration\",\"heading\":\"Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"code\",\"language\":\"conf\",\"code\":\"# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\\nrepl-backlog-size 1mb\\nrepl-backlog-ttl 3600\",\"source_ids\":[\"S4\"]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl-backlog-ttl\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" an, wann Redis ihn freigibt. Der Wert \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"0\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S5\"}]}]},{\"id\":\"monitoring-und-grenzen\",\"heading\":\"Monitoring und die Grenzen f\u00fcr High Availability\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Beginne die Diagnose mit folgendem Befehl:\",\"ref\":\"\"}]},{\"type\":\"code\",\"language\":\"text\",\"code\":\"INFO replication\",\"source_ids\":[\"S2\"]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auf dem Primary pr\u00fcfst du \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_first_byte_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_histlen\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_size\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\". Auf einer Replica sind \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_link_status\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"slave_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" sowie bei Unterbrechungen \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_link_down_since_seconds\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"replica-full-sync-buffer-limit\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" begrenzt den Puffer auf Replica-Seite, \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"client-output-buffer-limit replica\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"},{\"kind\":\"text\",\"text\":\" \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"WAIT\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auch \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"min-replicas-to-write\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"min-replicas-max-lag\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden \",\"ref\":\"\"},{\"kind\":\"internal_link\",\"text\":\"Redis Replication Offset analysieren\",\"ref\":\"I1\"},{\"kind\":\"text\",\"text\":\" weiterhelfen.\",\"ref\":\"\"}]}]}],\"images\":{\"hero\":{\"prompt\":\"Editoriale, realistische technische Illustration f\u00fcr einen Fachartikel: ein Redis-Primary als zentraler Knoten links sendet einen leuchtenden Datenstrom zu zwei Replica-Knoten rechts. Im Datenstrom befindet sich ein deutlich erkennbarer ringf\u00f6rmiger Pufferspeicher, der j\u00fcngere Datenabschnitte h\u00e4lt; eine kurz getrennte Verbindung zu einer Replica wird wieder geschlossen und der fehlende Abschnitt flie\u00dft nach. Dunkler, ruhiger Serverraum-Hintergrund, klare r\u00e4umliche Trennung der Komponenten, Rot- und warme Akzentfarben, keine Markenlogos. Keine W\u00f6rter, Zahlen, Labels, Diagrammlegenden oder UI-Screenshots.\",\"alt\":\"Illustration eines Primary mit ringf\u00f6rmigem Replikationspuffer und zwei wieder angebundenen Redis-Replicas.\",\"caption\":\"Illustrative Darstellung: Der Backlog h\u00e4lt einen j\u00fcngeren Abschnitt des Replikationsstroms f\u00fcr wiederkehrende Replicas vor.\",\"filename_base\":\"redis-backlog-psync\",\"section_id\":\"\",\"after_block\":0},\"detail1\":{\"prompt\":\"Klare konzeptionelle Illustration einer horizontalen Zeitachse f\u00fcr Redis-Replikation: links ein \u00e4lterer, verblassender Datenstrom, in der Mitte ein begrenzter ringf\u00f6rmiger Speicherbereich mit sichtbaren j\u00fcngeren Datenpaketen, rechts neue Datenpakete. Eine Replica-Verbindung setzt an einer Position innerhalb des Ringbereichs wieder ein, eine zweite gestrichelte Verbindung versucht weit links au\u00dferhalb des Ringbereichs anzusetzen und wird in einen vollst\u00e4ndigen Datentransfer \u00fcbergeleitet. Visuell intuitiv, technische Vektor-\u00c4sthetik, keine Beschriftungen, W\u00f6rter, Zahlen, Legenden oder Marken.\",\"alt\":\"Zeitachsenillustration mit verf\u00fcgbarem Backlog-Bereich und einer zu alten Replikationsl\u00fccke.\",\"caption\":\"Illustrative Darstellung: Ob PSYNC gelingt, h\u00e4ngt davon ab, ob der ben\u00f6tigte Offset noch im vorgehaltenen Bereich liegt.\",\"filename_base\":\"redis-psync-offset-range\",\"section_id\":\"psync-grenze\",\"after_block\":2},\"detail2\":{\"prompt\":\"Technische konzeptionelle Illustration zur Speicherkapazit\u00e4tsplanung: ein Server-Speichercontainer ist in mehrere farbige, unterschiedlich gro\u00dfe Bereiche gegliedert, darunter ein wachsender Replikationspuffer und getrennte Puffer f\u00fcr Replica-Daten. Daneben flie\u00dft ein variabler Strom aus Datenpaketen in den Replikationspuffer; eine kurze Unterbrechung wird durch den gespeicherten Abschnitt \u00fcberbr\u00fcckt. Fokus auf Verh\u00e4ltnis von Datenrate, Unterbrechungsdauer und RAM-Budget, ohne exakte Messskalen. Sachliche isometrische Vektorillustration, keine W\u00f6rter, Zahlen, Labels, Legenden, Logos oder erfundene Dashboards.\",\"alt\":\"Illustration eines Server-Speicherbudgets mit Replikationsbacklog und getrennten Replica-Puffern.\",\"caption\":\"Illustrative Darstellung: Die Backlog-Gr\u00f6\u00dfe wird aus Datenrate und gew\u00fcnschter \u00dcberbr\u00fcckungszeit geplant und dem RAM-Budget gegen\u00fcbergestellt.\",\"filename_base\":\"redis-backlog-memory-budget\",\"section_id\":\"groesse-planen\",\"after_block\":3}},\"chart\":null,\"social\":{\"facebook\":\"Redis Backlog richtig planen: Wann PSYNC gelingt und warum der Puffer keine Datenverlustgarantie ist.\",\"instagram\":\"PSYNC statt Full Resync: So h\u00e4ngt die Redis-Backlog-Gr\u00f6\u00dfe von Byte-Rate und Ausfallzeit ab.\",\"tiktok\":\"Redis Backlog erkl\u00e4rt: Warum Sekunden allein nicht entscheiden, ob PSYNC funktioniert.\",\"youtube\":\"Redis Replication Backlog: PSYNC, Dimensionierung und Grenzen f\u00fcr HA verst\u00e4ndlich erkl\u00e4rt.\",\"threads\":\"Der Redis Backlog puffert Replikationsbytes, nicht deine Datenbank. Entscheidend sind Offset, Historie und Schreibrate.\",\"x\":\"Redis Replication Backlog: PSYNC klappt nur, wenn ID, Offset und vorgehaltener Bytebereich zusammenpassen. Gr\u00f6\u00dfe nach Replikationsrate und \u00dcberbr\u00fcckungszeit planen \u2013 nicht nach pauschalen Prozentwerten.\"},\"avatar_script\":\"Der Redis Replication Backlog ist ein Speicherpuffer f\u00fcr einen begrenzten Teil des Replikationsstroms. F\u00e4llt die Verbindung einer Replica kurz aus, kann sie ihre Replikations-ID und ihren letzten Offset melden. Liegen die fehlenden Bytes noch im Backlog, liefert Redis sie per PSYNC nach. Andernfalls ist ein Full Resync mit RDB-\u00dcbertragung erforderlich. F\u00fcr die Gr\u00f6\u00dfe z\u00e4hlt nicht nur die Dauer einer Unterbrechung, sondern vor allem die dabei erzeugte Datenmenge. Miss deshalb den Offset-Zuwachs \u00fcber die Zeit und plane Reserve ein. Der Backlog reduziert teure Neuabgleiche, macht die asynchrone Replikation aber nicht verlustfrei. Pr\u00fcfe zus\u00e4tzlich Speicherbudget, Replica-Buffer, Persistenz und Failover-Abl\u00e4ufe.\",\"version_note\":\"Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer.\"}","_wh_make_design_backup_204":{"post_content":"<!-- wp:html -->\n<div class=\"wh-article\"><p class=\"wh-lead\">Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup>Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup><\/p><h2 id=\"grundprinzip\">Was der Backlog speichert \u2013 und was nicht<\/h2><p>Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><p>Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><p>Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><h2 id=\"psync-grenze\">Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird<\/h2><p>Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.<sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Auf dem Primary beschreibt <code data-no-translation>repl_backlog_first_byte_offset<\/code> den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. <code data-no-translation>repl_backlog_histlen<\/code> zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; <code data-no-translation>repl_backlog_size<\/code> ist die konfigurierte Obergrenze. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><div class=\"wh-table-scroll\" tabindex=\"0\"><table><caption>Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica<\/caption><thead><tr><th scope=\"col\">Situation<\/th><th scope=\"col\">ID und Offset<\/th><th scope=\"col\">Ergebnis<\/th><th scope=\"col\">Betriebliche Folge<\/th><\/tr><\/thead><tbody><tr><td>Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog<\/td><td>Historie g\u00fcltig, Offset abgedeckt<\/td><td>Partielle Resynchronisierung per PSYNC<\/td><td>Nur die L\u00fccke wird \u00fcbertragen<\/td><\/tr><tr><td>Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite<\/td><td>Angeforderter Offset \u00e4lter als der erste Backlog-Offset<\/td><td>Full Resync<\/td><td>RDB-Transfer und Nachlieferung laufender \u00c4nderungen<\/td><\/tr><tr><td>Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie<\/td><td>Sekund\u00e4re Replikations-ID kann passen<\/td><td>PSYNC kann m\u00f6glich sein<\/td><td>Abh\u00e4ngig von Historie und vorgehaltenem Bereich<\/td><\/tr><tr><td>Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen<\/td><td>Kein nutzbarer Backlog vorhanden<\/td><td>Sp\u00e4tere Replica ben\u00f6tigt Full Resync<\/td><td>Historie wurde automatisch freigegeben<\/td><\/tr><\/tbody><\/table><\/div><sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><h2 id=\"groesse-planen\">Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten<\/h2><p>F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.<\/p><p>Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt <code data-no-translation>master_repl_offset<\/code> und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet <code data-no-translation>12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB<\/code>. Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.<\/p><p>Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann <code data-no-translation>mem_clients_slaves<\/code> trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere <code data-no-translation>mem_replication_backlog<\/code> und <code data-no-translation>mem_total_replication_buffers<\/code> relevant. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><h2 id=\"konfiguration\">Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen<\/h2><p>Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><pre class=\"wh-code\" data-no-translation><code class=\"language-conf\"># redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600<\/code><\/pre><sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><p>In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt <code data-no-translation>repl-backlog-ttl<\/code> an, wann Redis ihn freigibt. Der Wert <code data-no-translation>0<\/code> verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><p>Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S5\">[S5]<\/a><\/sup><\/p><h2 id=\"monitoring-und-grenzen\">Monitoring und die Grenzen f\u00fcr High Availability<\/h2><p>Beginne die Diagnose mit folgendem Befehl:<\/p><pre class=\"wh-code\" data-no-translation><code class=\"language-text\">INFO replication<\/code><\/pre><sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><p>Auf dem Primary pr\u00fcfst du <code data-no-translation>master_repl_offset<\/code>, <code data-no-translation>repl_backlog_first_byte_offset<\/code>, <code data-no-translation>repl_backlog_histlen<\/code> und <code data-no-translation>repl_backlog_size<\/code>. Auf einer Replica sind <code data-no-translation>master_link_status<\/code>, <code data-no-translation>slave_repl_offset<\/code> sowie bei Unterbrechungen <code data-no-translation>master_link_down_since_seconds<\/code> aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: <code data-no-translation>replica-full-sync-buffer-limit<\/code> begrenzt den Puffer auf Replica-Seite, <code data-no-translation>client-output-buffer-limit replica<\/code> betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><p>F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup> <code data-no-translation>WAIT<\/code> kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup><\/p><p>Auch <code data-no-translation>min-replicas-to-write<\/code> und <code data-no-translation>min-replicas-max-lag<\/code> begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden <a href=\"https:\/\/webhosting.de\/redis-replication-offset-analyse-datenkonsistenz-cluster\/\">Redis Replication Offset analysieren<\/a> weiterhelfen.<\/p><section class=\"wh-sources\"><h2>Quellen und fachlicher Stand<\/h2><p>Recherche-Stand: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p>Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer.<\/p><ul><li id=\"wh-source-S1\">[S1] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/\" rel=\"noopener\">Redis replication | Docs<\/a><\/li><li id=\"wh-source-S3\">[S3] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai\" rel=\"noopener\">Redis replication | Docs<\/a><\/li><li id=\"wh-source-S2\">[S2] <a href=\"https:\/\/redis.io\/docs\/latest\/commands\/info\/\" rel=\"noopener\">INFO | Docs<\/a><\/li><li id=\"wh-source-S4\">[S4] <a href=\"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf\" rel=\"noopener\">redis\/redis.conf at unstable \u00b7 redis\/redis \u00b7 GitHub<\/a><\/li><li id=\"wh-source-S5\">[S5] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai\" rel=\"noopener\">Database replication | Docs<\/a><\/li><\/ul><\/section><\/div>\n<!-- \/wp:html -->","draft_hash":"20de282ac96cd1ec48634882871b2d6afea498967024969c8e6059074271ce5e","created_at":"2026-09-21T18:27:55+00:00","helper_version":"2.0.4"},"_wp_desired_post_slug":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":"1","_edit_lock":"1790049167:1","_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"464","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":"73","rank_math_contentai_score":null,"ilj_limitincominglinks":"","ilj_maxincominglinks":"1","ilj_limitoutgoinglinks":"","ilj_maxoutgoinglinks":"1","ilj_limitlinksperparagraph":"","ilj_linksperparagraph":"1","ilj_blacklistdefinition":[],"ilj_linkdefinition":[],"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Replication Backlog","rank_math_og_content_image":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21637","_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":"Erfahre, was der Redis Replication Backlog speichert, wie PSYNC funktioniert, wie du die Gr\u00f6\u00dfe planst und welche Grenzen f\u00fcr High Availability gelten.","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21633"}],"version-history":[{"count":5,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21633\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21633\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21637"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}