{"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":"comprendere-il-backlog-di-replica-di-redis","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/redis-replication-backlog-verstehen\/","title":{"rendered":"Comprendere il backlog di replica di Redis: PSYNC, dimensioni e limiti di alta disponibilit\u00e0"},"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;\">Il sito <strong style=\"font-weight:700;color:#153e50;\">Backlog di replica di Redis<\/strong> determina se, in seguito a un\u2019interruzione della connessione, una replica debba recuperare solo le modifiche mancanti oppure ricevere nuovamente l\u2019intero set di dati. Chi dimensiona il buffer in base al volume effettivo di replica pu\u00f2 evitare inutili sincronizzazioni complete. A tal fine, tuttavia, anche la cronologia delle repliche, il budget di memoria e i processi operativi devono essere coordinati: un backlog di grandi dimensioni non sostituisce n\u00e9 la persistenza n\u00e9 un solido concetto di failover. <\/p><nav aria-label=\"Contenuto di questo articolo\" 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;\">Vai direttamente alla sezione<\/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;\">Cosa contiene effettivamente il backlog<\/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;\">Quando \u00e8 sufficiente un PSYNC e quando \u00e8 necessaria una sincronizzazione completa<\/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;\">Misurare il tasso di replica anzich\u00e9 stimare le dimensioni del database<\/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;\">Calcolare in modo trasparente l'entit\u00e0 del backlog<\/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;\">Modificare la configurazione di Redis in modo chiaro e controllato<\/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;\">Monitoraggio: quali valori vanno considerati insieme<\/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;\">Come valutare correttamente il budget di archiviazione e le repliche lente<\/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;\">Perch\u00e9 un backlog consistente non garantisce ancora un\u2019elevata disponibilit\u00e0<\/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;\">Testare le modifiche e individuare i problemi ricorrenti<\/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;\">Cosa contiene effettivamente il backlog<\/h2><p style=\"margin:0 0 22px;\">All'indirizzo <strong style=\"font-weight:700;color:#153e50;\">Replica di Redis<\/strong> Il primario elabora le modifiche al database e trasmette un flusso continuo di comandi alle proprie repliche. Ci\u00f2 non comprende solo i valori scritti direttamente dai client; anche le chiavi scadute o sovrascritte possono innescare modifiche che devono essere trasmesse. Il backlog conserva in memoria una porzione limitata e recente di questo flusso di replica. Non contiene quindi una copia completa aggiuntiva del database n\u00e9 costituisce un archivio di operazioni di scrittura di qualsiasi et\u00e0. <\/p><p style=\"margin:0 0 22px;\">In condizioni di funzionamento regolare, le repliche seguono il flusso corrente. Se una connessione viene interrotta, la cronologia sul primario continua ad aumentare. Dopo il ripristino della connessione, la replica cerca di allinearsi allo stato precedente. A quel punto \u00e8 fondamentale verificare se i byte necessari siano ancora disponibili. Se cos\u00ec fosse e la cronologia di replica corrispondesse, Redis pu\u00f2 colmare il divario. A tal fine non \u00e8 necessario sostituire completamente i dati gi\u00e0 presenti nella replica. <\/p><p style=\"margin:0 0 22px;\">I vantaggi sono particolarmente evidenti in caso di brevi interruzioni di rete, cambi di connessione e interventi di manutenzione programmati. Una sincronizzazione completa di un ampio volume di dati richiede capacit\u00e0 di trasmissione e potenza di calcolo; a seconda della configurazione, si aggiungono ulteriori carichi sulla memoria e sui supporti dati. Il backlog pu\u00f2 ridurre questo carico, ma non \u00e8 in grado di compensare ogni tipo di interruzione. Un riavvio del processo o una cronologia modificata richiedono un approccio diverso rispetto a una connessione TCP interrotta per un breve periodo. <\/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;\">Quando \u00e8 sufficiente un PSYNC e quando \u00e8 necessaria una sincronizzazione completa<\/h2><p style=\"margin:0 0 22px;\">A <strong style=\"font-weight:700;color:#153e50;\">Risincronizzazione parziale con PSYNC<\/strong> richiede due dati correlati: l\u2019ID di replica e l\u2019offset. L\u2019ID identifica una specifica cronologia di dati. L\u2019offset descrive una posizione in byte all\u2019interno del flusso di replica. Due offset di uguale dimensione provenienti da cronologie diverse non sono quindi automaticamente comparabili. Al contrario, un leggero ritardo all\u2019interno della stessa cronologia pu\u00f2 gi\u00e0 trovarsi al di fuori del backlog disponibile, se la sua capacit\u00e0 \u00e8 limitata.  <\/p><p style=\"margin:0 0 22px;\">In parole semplici, al momento della riconnessione la replica comunica fino a quale punto \u00e8 arrivata. Il primario verifica se \u00e8 in grado di fornire i dati necessari per proseguire. Se la cronologia \u00e8 sconosciuta o manca la sezione richiesta, viene generato un <strong style=\"font-weight:700;color:#153e50;\">Sincronizzazione completa<\/strong> necessario. In questo modo la replica riceve un set completo di dati e, successivamente, le modifiche apportate durante la sincronizzazione. A seconda della configurazione, il trasferimento pu\u00f2 avvenire con una fase intermedia RDB su supporto dati oppure senza tale fase intermedia.  <\/p><p style=\"margin:0 0 22px;\">Dopo un failover, una risincronizzazione completa non \u00e8 inevitabile in ogni caso. Una replica trasferita pu\u00f2 inoltre memorizzare l\u2019ID di replica precedente e il relativo intervallo di offset valido. In questo modo, altre repliche possono, a determinate condizioni, allinearsi alla cronologia nota. Per la pianificazione, tuttavia, ci\u00f2 non costituisce una garanzia: l\u2019intervallo pertinente deve continuare a essere disponibile e il ricollegamento effettivo deve corrispondere agli ID memorizzati.  <\/p><div aria-label=\"Riconnessione di una replica: possibili esiti\" 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;\">Riconnessione di una replica: possibili risultati<\/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;\">Situazione<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Prerequisito<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Risultato<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Breve interruzione<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Cronologia corrispondente; i byte necessari sono ancora disponibili<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">PSYNC pu\u00f2 fornire solo i dati di replica mancanti.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">I byte pi\u00f9 vecchi necessari sono stati sovrascritti<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">L'intervallo richiesto non rientra nella cronologia disponibile<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Una ricalibrazione completa anzich\u00e9 una ripresa parziale.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Cronologia di replica sconosciuta<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">L'ID di replica non viene riconosciuto come valido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Un aumento del volume di lavoro arretrato, di per s\u00e9, non risolve il problema.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Failover con ID del predecessore noto<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">ID secondario memorizzato, intervallo di offset valido e cronologia sufficiente<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Potrebbe comunque essere possibile una risincronizzazione parziale.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Backlog rilasciato dopo la separazione di tutte le repliche<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Il TTL \u00e8 scaduto; non rimane alcuna cronologia utilizzabile<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Il successivo ricollegamento richiede una calibrazione completa.<\/td><\/tr><\/tbody><\/table><\/div><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Una finestra limitata nel flusso di dati mostra chiaramente quali dati di replica mancanti sono ancora disponibili dopo un&#039;interruzione.\" 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;\">Illustrazione schematica: PSYNC pu\u00f2 collegarsi solo a una cronologia di replica compatibile e ancora disponibile.<\/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;\">Misurare il tasso di replica anzich\u00e9 stimare le dimensioni del database<\/h2><p style=\"margin:0 0 22px;\">La semplice mole dei dati \u00e8 sufficiente per <strong style=\"font-weight:700;color:#153e50;\">Dimensionamento del backlog<\/strong> non \u00e8 sufficiente. Un database di grandi dimensioni, utilizzato prevalentemente per la lettura, pu\u00f2 generare un traffico di replica limitato. Una cache di piccole dimensioni con valori che cambiano frequentemente e molti eventi di scadenza, invece, pu\u00f2 trasferire continuamente notevoli quantit\u00e0 di dati. Anche un numero fisso di operazioni al secondo descrive in modo insufficiente la memoria necessaria: piccole modifiche alle chiavi e grandi sovrascritture di valori non generano lo stesso volume di byte.  <\/p><p style=\"margin:0 0 22px;\">Un\u2019approssimazione utilizzabile nella pratica si ricava dall\u2019incremento temporale di <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>. Rileva il valore due volte sullo stesso primario e dividi la differenza per i secondi trascorsi. Verifica anche l\u2019ID di replica. Dopo un cambio di ruolo o un riavvio, non devi semplicemente sottrarre tra loro due punti di misurazione non correlati. Inoltre, un singolo intervallo di misurazione fornisce solo una frequenza media all\u2019interno di quell\u2019intervallo, non un limite massimo garantito in modo permanente.  <\/p><p style=\"margin:0 0 22px;\">La query seguente legge le informazioni di diagnostica. Non modifica alcuna configurazione di Redis. Eseguila utilizzando le opzioni di connessione e autenticazione richieste dal tuo ambiente. La chiamata riportata di seguito utilizza la connessione predefinita di <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">redis-cli<\/code>; \u00e8 necessario impostare espressamente un altro host, porta o accesso TLS.  <\/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;\">Effettua misurazioni nelle diverse fasi di carico, ad esempio durante le normali attivit\u00e0 quotidiane, in caso di importazioni e durante i ricarichi della cache su larga scala. Documenta sia i valori tipici che i brevi picchi. Se si verificano molte modifiche dovute alla scadenza delle chiavi, l\u2019articolo interno pu\u00f2 essere utile per approfondire l\u2019argomento. <a href=\"https:\/\/webhosting.de\/it\/redis-analisi-delle-prestazioni-scadenza-delle-chiavi-ottimizzazione-cache\/\">Analisi della scadenza delle chiavi Redis<\/a>. Questo nesso \u00e8 importante ai fini della pianificazione, poich\u00e9 non tutti gli spunti di scrittura rilevanti derivano direttamente da una nuova richiesta dell'utente.  <\/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;\">Calcolare in modo trasparente l'entit\u00e0 del backlog<\/h2><p style=\"margin:0 0 22px;\">Come <strong style=\"font-weight:700;color:#153e50;\">Approssimazione di progettazione<\/strong> puoi moltiplicare la frequenza di replica pertinente per la durata dell'interruzione da colmare e poi aggiungere una riserva adeguata. La durata non dovrebbe tenere conto solo dell'interruzione effettiva della rete. Anche il rilevamento, i tentativi di ricollegamento e il ripristino del percorso di connessione possono richiedere tempo. Quale riserva sia adeguata dipende dalle fluttuazioni osservate e dall'obiettivo operativo desiderato, non da una percentuale universale. <\/p><p style=\"margin:0 0 22px;\">Un esempio di calcolo volutamente semplificato: per una fase di carico considerata, si ipotizzano 12 MiB al secondo. La connessione potrebbe essere assente per 90 secondi; si prevedono altri 30 secondi come riserva di tempo. Ne conseguono <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>, ovvero circa 1,41 GiB. Questi numeri sono valori ipotetici forniti a titolo illustrativo e non costituiscono un benchmark di Redis. Prima di un'implementazione in produzione, devono essere sostituiti dai valori effettivi rilevati dalla tua applicazione. <\/p><figure class=\"wh-chart\"><figcaption>Fabbisogno di backlog ipotizzando 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 secondi<\/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 secondi<\/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 secondi<\/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 secondi<\/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;\">Esempio di calcolo illustrativo, non si tratta di una misurazione: fabbisogno = 12 MiB\/s ipotizzati \u00d7 durata totale selezionata. I 120 secondi indicati nell'esempio testuale comprendono 90 secondi di interruzione e 30 secondi di riserva di tempo. Non sono incluse ulteriori riserve.<\/p><details><summary>Tabella dei dati relativa al grafico<\/summary><table><thead><tr><th scope=\"col\">Ingresso<\/th><th scope=\"col\">MiB<\/th><\/tr><\/thead><tbody><tr><td>30 secondi<\/td><td>360<\/td><\/tr><tr><td>60 secondi<\/td><td>720<\/td><\/tr><tr><td>120 secondi<\/td><td>1440<\/td><\/tr><tr><td>180 secondi<\/td><td>2160<\/td><\/tr><\/tbody><\/table><\/details><\/figure><p style=\"margin:0 0 22px;\">Il calcolo inverso aiuta a valutare la capacit\u00e0 di un buffer esistente. Un backlog completamente pieno di 256 MiB corrisponde, a una velocit\u00e0 costante di 12 MiB al secondo, a circa 21 secondi di cronologia. A una velocit\u00e0 di 2 MiB al secondo, sarebbero circa 128 secondi. In un'applicazione reale, tuttavia, le velocit\u00e0 variano. Tale intervallo rappresenta quindi un'istantanea e non una garanzia che ogni evento di questa durata possa essere parzialmente sincronizzato. <\/p><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Due finestre storiche di uguali dimensioni, con flussi di dati di densit\u00e0 diversa, illustrano l\u2019influenza della frequenza di replica.\" 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;\">Illustrazione concettuale: a parit\u00e0 di dimensione del buffer, un flusso di replica pi\u00f9 ampio riduce la portata temporale.<\/figcaption><\/figure><p style=\"margin:0 0 22px;\">Verifica inoltre se, una volta ristabilita la connessione, la replica riesca a recuperare il ritardo pi\u00f9 velocemente di quanto ne vengano generate di nuove. Aumentare la cronologia non risolve n\u00e9 il problema di una rete costantemente troppo lenta n\u00e9 quello di un destinatario costantemente sovraccarico. Se il ritardo persiste o continua ad aumentare, \u00e8 necessario individuarne la causa. Limitarvisi ad aumentare la memoria disponibile non fa altro che rimandare il problema e pu\u00f2 mettere a dura prova l'intero sistema in termini di memoria. <\/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;\">Modificare la configurazione di Redis in modo chiaro e controllato<\/h2><p style=\"margin:0 0 22px;\">I parametri <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> e <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> controllano aspetti diversi. Il primo descrive la dimensione prevista del backlog. Il secondo determina, sul server primario, dopo quanto tempo senza repliche connesse il backlog possa essere rilasciato. Esso \u00e8 <strong style=\"font-weight:700;color:#153e50;\">nessuna durata massima di interruzione per PSYNC<\/strong>. Finch\u00e9 il buffer viene sovrascritto o manca un altro requisito, un TTL lungo da solo non \u00e8 sufficiente.   <\/p><p style=\"margin:0 0 22px;\">Le righe seguenti sono impostazioni commentate tratte dal modello di configurazione di Redis 7.2.0. I simboli di commento sono stati mantenuti intenzionalmente. La semplice copia di queste righe non attiva alcuna impostazione; inoltre, i valori indicati non costituiscono una raccomandazione generale in termini di capacit\u00e0 per i sistemi di produzione.   <\/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;\">Con <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> la abilitazione temporizzata viene disattivata dopo la disconnessione di tutte le repliche. Ci\u00f2 non garantisce la conservazione di una cronologia illimitata: il buffer esistente pu\u00f2 comunque essere sovrascritto da nuovi dati di replica. Inoltre, ci\u00f2 non garantisce la persistenza in caso di eventuali riavvii del processo. Valuta quindi attentamente se il consumo di memoria aggiuntivo \u00e8 compatibile con il comportamento di riconnnessione previsto.   <\/p><p style=\"margin:0 0 22px;\">Prima di apportare una modifica, dovresti verificare i valori effettivamente in vigore e chiarire la procedura di distribuzione. Una variabile d'ambiente del container, un file di configurazione gestito e un'impostazione modificata in fase di esecuzione non sono la stessa cosa. Se in seguito viene ricreata un'istanza, solo le modifiche apportate in fase di esecuzione potrebbero andare perse. Le seguenti query sono di sola lettura; richiedono comunque i diritti di accesso appropriati.   <\/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;\">Con Managed Redis, il fornitore pu\u00f2 limitare l'accesso a <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">CONFIG<\/code> limitare o gestire le impostazioni tramite un'interfaccia dedicata. Questo non \u00e8 un motivo per aggirare i meccanismi di protezione. Utilizza quindi i canali di gestione autorizzati e documenta la dimensione scelta insieme al volume di replica sottostante. Nel piano di modifica dovrebbero inoltre essere riportati i valori precedenti e un percorso di ritorno realistico.   <\/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;\">Monitoraggio: quali valori vanno considerati insieme<\/h2><p style=\"margin:0 0 22px;\">Per la <strong style=\"font-weight:700;color:#153e50;\">Monitoraggio della replica di Redis<\/strong> Un singolo indicatore verde dello stato della connessione non \u00e8 sufficiente. Una connessione pu\u00f2 essere stata ripristinata mentre la replica sta ancora recuperando il ritardo o sta caricando un set completo di dati. Al contrario, una breve interruzione della connessione non deve necessariamente essere considerata critica se la cronologia e la capacit\u00e0 di recupero sono sufficienti. Valuta quindi congiuntamente la connessione, lo stato di sincronizzazione, l\u2019andamento dell\u2019offset e la cronologia disponibile. <\/p><div aria-label=\"Monitoraggio di Redis: interpretare i valori nel loro contesto\" 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;\">Monitoraggio di Redis: interpretare i valori nel loro contesto<\/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;\">Campo<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Significato<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">A cosa devi prestare attenzione<\/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;\">Identit\u00e0 della cronologia e offset in byte attuale sul disco primario<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Confrontare i punti di misurazione solo all\u2019interno della stessa cronologia.<\/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;\">Se il backlog di replica \u00e8 attualmente attivo<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Un valore configurato di per s\u00e9 non implica ancora la disponibilit\u00e0 di un storico.<\/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 del primo byte ancora memorizzato<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">I dati necessari per la replica devono rientrare nell'area disponibile.<\/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;\">Lunghezza della cronologia esistente e dimensione configurata<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Un buffer appena creato non deve necessariamente essere gi\u00e0 completamente riempito.<\/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;\">Connessione e sincronizzazione in tempo reale dal punto di vista della replica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Il fatto che un collegamento sia nuovamente disponibile non \u00e8 di per s\u00e9 prova che la sincronizzazione sia stata completata.<\/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;\">Stato di avanzamento della replica su una replica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Tenere conto della cronologia e della storia correlata.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 22px;\">I campi di una <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">INFO<\/code>-Le risposte possono variare a seconda delle versioni di Redis e tra primario e replica. Un\u2019analisi dovrebbe quindi trattare espressamente i campi mancanti, anzich\u00e9 interpretarli tacitamente come nulli o come uno stato privo di errori. Anche le denominazioni <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master<\/code> e <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">slave<\/code> per motivi di compatibilit\u00e0 continuano a comparire nei nomi dei campi; non devono essere tradotti liberamente nel codice eseguibile. <\/p><p style=\"margin:0 0 22px;\">Per l'interpretazione del ritardo, si fa riferimento alla guida interna <a href=\"https:\/\/webhosting.de\/it\/redis-replica-offset-analisi-coerenza-dei-dati-cluster\/\">Analisi dell'offset di replica di Redis<\/a> un complemento adeguato. Nel monitoraggio continuo dovresti considerare l'andamento storico, non solo due valori rilevati manualmente. Una distanza crescente richiede una reazione diversa rispetto a un divario che si riduce costantemente dopo un breve crollo. <\/p><p style=\"margin:0 0 22px;\">Gli allarmi efficaci devono essere in linea con i tuoi obiettivi operativi: per quanto tempo una replica pu\u00f2 rimanere irraggiungibile? Entro quanto tempo deve recuperare il ritardo? Qual \u00e8 la frequenza insolita delle sincronizzazioni complete? I valori limite rigidi, senza alcun riferimento al profilo di carico e al volume dei dati, spesso generano segnalazioni inutili o trascurano effettivi peggioramenti. Oltre alle metriche di replica, tieni sotto controllo anche l\u2019utilizzo della RAM, il carico di rete e gli indizi relativi ai riavvii dei processi. <\/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;\">Come valutare correttamente il budget di archiviazione e le repliche lente<\/h2><p style=\"margin:0 0 22px;\">Il backlog \u00e8 solo una parte del totale <strong style=\"font-weight:700;color:#153e50;\">Requisiti di memoria di Redis<\/strong>. A ci\u00f2 si aggiungono il volume dei dati, le strutture amministrative, i buffer dei client e, a seconda delle condizioni operative, memoria aggiuntiva durante le operazioni di persistenza o sincronizzazione. Pertanto, non destinare l\u2019intera memoria di lavoro disponibile ai dati utente pi\u00f9 un backlog calcolato con precisione. La riserva necessaria deve essere determinata in base all\u2019ambiente specifico e ai picchi di carico che vi si verificano.  <\/p><p style=\"margin:0 0 22px;\">A partire da Redis 7.0, il buffer di replica e il backlog di replica condividono la memoria. La documentazione INFO sottolinea quindi, tra l\u2019altro, che <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> pu\u00f2 essere pari a zero se i buffer di replica non superano la capacit\u00e0 del backlog. Ci\u00f2 non significa per\u00f2 che la replica non occupi memoria. Considera i valori previsti a tale scopo come <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> e <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> nel contesto e non sommare ciecamente le grandezze che si sovrappongono.  <\/p><p style=\"margin:0 0 22px;\">Un errore diagnostico comune consiste nel considerare ogni sincronizzazione interrotta come il risultato di un accumulo di dati in sospeso. Repliche lente, larghezza di banda di rete limitata o limiti del buffer di output superati possono avere altre cause. Il parametro <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> si riferisce alla classe client in questione e non deve essere confusa con <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> devono essere considerati equivalenti. Prima di modificare i limiti, controlla i log, la documentazione relativa alle versioni e le possibili ripercussioni sulle altre connessioni.  <\/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;\">Perch\u00e9 un backlog consistente non garantisce ancora un\u2019elevata disponibilit\u00e0<\/h2><p style=\"margin:0 0 22px;\">Il backlog migliora il ripristino della connessione, ma non rende la replica, di default asincrona, priva di perdite. Un primario pu\u00f2 aver gi\u00e0 confermato un'operazione di scrittura al client prima che una replica l'abbia elaborata. Se il primario si guasta in questo lasso di tempo, l'operazione in questione potrebbe non essere presente sul sistema di riserva selezionato in seguito. La dimensione del buffer da sola non risolve questo <strong style=\"font-weight:700;color:#153e50;\">Rischio di perdita dei dati in caso di failover<\/strong> no.   <\/p><p style=\"margin:0 0 22px;\">Anche <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">WAIT<\/code> non trasforma una topologia Redis in un sistema con forte coerenza garantita. Il comando pu\u00f2 attendere le conferme dalle repliche; l'effettiva sicurezza dei dati continua a dipendere da ulteriori fattori, in particolare dal comportamento in termini di persistenza e failover. Allo stesso modo, limitano <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> e <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> accettare nuove operazioni di scrittura alle rispettive condizioni, senza salvare automaticamente e in modo permanente ogni singola operazione su pi\u00f9 istanze.   <\/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;\">La replica non \u00e8 un backup<\/p><p style=\"margin:0 0 22px;\">Se un primario si riavvia automaticamente senza persistenza e con un set di dati vuoto, le sue repliche possono ereditare questo stato vuoto. Un backlog consistente non impedisce che si verifichi questo scenario. Assicurati quindi che il riavvio, la persistenza e il ripristino siano coordinati; una singola replica non sostituisce un backup dei dati utilizzabile in modo indipendente.  <\/p><\/aside><p style=\"margin:0 0 22px;\">Per <strong style=\"font-weight:700;color:#153e50;\">Alta disponibilit\u00e0<\/strong> \u00c8 quindi necessario definire una strategia coerente che comprenda: perdita di dati tollerabile, tempo di inattivit\u00e0 ammissibile, persistenza, rilevamento dei guasti, selezione del nuovo primario e ripristino. Sentinel o Redis Cluster possono assumere compiti diversi rispetto al backlog. Chi si limita ad aumentare la dimensione di un buffer lasciando invariate tutte le altre ipotesi non dispone ancora di un piano di ripristino affidabile.   <\/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;\">Testare le modifiche e individuare i problemi ricorrenti<\/h2><p style=\"margin:0 0 22px;\">Avvia un test controllato in un ambiente isolato con una versione di Redis comparabile e un carico di scrittura tracciabile. Prima dell\u2019interruzione, registra gli ID di replica, gli offset, lo stato del backlog e l\u2019utilizzo della memoria. Simula quindi un'interruzione limitata della connessione, senza modificare firewall o processi di produzione non verificati. Dopo il ripristino della connessione, osserva se avviene una sincronizzazione parziale o completa e quanto tempo richiede il recupero.  <\/p><p style=\"margin:0 0 22px;\">Per ogni prova, modifica, per quanto possibile, solo una variabile rilevante. Se il backlog, il carico di scrittura e le condizioni di rete cambiano contemporaneamente, \u00e8 difficile attribuire l\u2019effetto a una causa specifica. Ripeti la prova con durate di interruzione diverse e diverse fasi di carico. In questo modo, da una singola riconnessione riuscita si ottiene una valutazione comprensibile del comportamento. I limiti osservati dovrebbero essere documentati, senza per\u00f2 dedurne una garanzia per ogni futuro malfunzionamento.  <\/p><p style=\"margin:0 0 22px;\">In caso di risincronizzazioni complete ripetute, verifica innanzitutto se la cronologia \u00e8 effettivamente compatibile. Successivamente, controlla i byte ancora presenti, il tempo trascorso senza replica, le indicazioni relative ai riavvii e la velocit\u00e0 effettiva di recupero. Un buffer troppo piccolo \u00e8 una possibile causa, ma non l\u2019unica. \u00c8 particolarmente importante distinguere tra un\u2019interruzione una tantum troppo lunga e una replica che rimane costantemente in ritardo anche in presenza di una connessione attiva.  <\/p><p style=\"margin:0 0 22px;\">L'impostazione corretta \u00e8, in definitiva, quella che copre la finestra di inattivit\u00e0 da te definita con un carico realistico e lascia memoria sufficiente per il resto del funzionamento. Registra insieme la base di riferimento delle misurazioni, la fonte di configurazione e la data della verifica. Dopo modifiche significative al comportamento di scrittura, alla topologia o alla versione di Redis, \u00e8 necessario riesaminare il dimensionamento. In questo modo, il backlog rimane una decisione operativa fondata anzich\u00e9 un valore adottato una volta per tutte.  <\/p><section class=\"wh-sources\" style=\"margin-top:50px;padding-top:25px;border-top:1px solid #dce6eb;font-size:14px;color:#607381;\"><h2>Fonti e stato dell'arte<\/h2><p style=\"margin:0 0 22px;\">Stato della ricerca: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p style=\"margin:0 0 22px;\">Gli esempi di configurazione sono basati sulla versione stabile di Redis 7.2.0, non sul ramo di sviluppo \"unstable\". L'allocazione condivisa della memoria descritta \u00e8 valida, secondo la documentazione INFO, a partire da Redis 7.0. I meccanismi generali si riferiscono a Redis Open Source; non vengono riportati i valori predefiniti del software Redis o del cloud. Aggiornamento della documentazione: 21\/09\/2026. Nessun test di laboratorio su Redis effettuato autonomamente.<\/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>Il backlog di replica di Redis conserva una porzione limitata del flusso di replica. Spesso, in seguito a brevi interruzioni della connessione, consente di eseguire un PSYNC anzich\u00e9 un full resync, ma non sostituisce n\u00e9 l'archiviazione persistente dei dati n\u00e9 un sistema di alta disponibilit\u00e0 ben progettato.<\/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":"Comprendere e analizzare l'offset di replica di Redis per garantire un'elevata coerenza dei dati","excerpt":"Mostrer\u00f2 come leggo e analizzo in modo mirato l\u2019offset di Redis e come lo utilizzo per garantire un\u2019elevata coerenza dei dati. In questo modo riesco a individuare tempestivamente le lacune nella replica, a valutare i rischi di failover e a mantenere i cluster produttivi sincronizzati in modo affidabile. Punti chiave I seguenti concetti fondamentali offrono un\u2019introduzione mirata all\u2019argomento, alla terminologia e all\u2019applicazione pratica. L\u2019offset misura l\u2019avanzamento del flusso di replica byte per byte. Il lag \u00e8 la differenza tra master_repl_offset e slave_repl_offset. L\u2019ID+offset identifica una versione esatta dei dati per le sincronizzazioni parziali. Il backlog protegge dalle sincronizzazioni complete in caso di brevi interruzioni di connessione. Il monitoraggio tramite INFO\/metriche del cluster gestisce gli allarmi e il failover. Cosa significa l\u2019offset di replica di Redis? L\u2019offset di replica \u00e8 un contatore progressivo a 64 bit che riflette ogni flusso di byte trasmesso tra il primario e la replica. Da esso deduco a che punto sia la replica e se una replica abbia ancora del lavoro da svolgere. Il `master_repl_offset` sul primario aumenta con ogni byte appena generato, mentre la replica incrementa il proprio contatore non appena ha applicato i comandi. Le differenze indicano un ritardo in byte e segnalano se la replica \u00e8 in ritardo. Questa semantica semplice ma efficace rende l\u2019offset il valore centrale per la sincronizzazione, l\u2019analisi dei guasti e decisioni di failover accurate. Lettura degli offset: utilizzare correttamente INFO replication. Inizio quasi sempre la diagnosi con INFO replication, poich\u00e9 il comando fornisce in modo sintetico i campi rilevanti. Sul primario controllo master_repl_offset e lo stato delle repliche collegate, inclusi i loro offset. Su una replica controllo inoltre master_link_status e gli stati di sincronizzazione, per individuare eventuali sincronizzazioni complete o parziali in corso. Per un\u2019analisi pi\u00f9 approfondita ricorro a output strutturati e metto in correlazione gli offset con i valori relativi a CPU, I\/O e rete. Questa guida mi fornisce un'introduzione approfondita al comando: Redis INFO per il monitoraggio. ID di replica + offset: versione univoca dei dati Per ottenere una versione univoca, utilizzo la combinazione di ID di replica e offset. L'ID identifica una cronologia, mentre l'offset indica una posizione all\u2019interno della"},"I2":{"id":"I2","post_id":21597,"url":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":"Analisi e ottimizzazione delle prestazioni relative alla scadenza delle chiavi Redis","excerpt":"Analizzo in modo mirato le prestazioni della scadenza delle chiavi Redis e le ottimizzo con passaggi chiari e misurabili. In questo modo riduco la latenza, smusso i picchi di carico e tengo sotto controllo il consumo di memoria, senza compromettere la velocit\u00e0 di elaborazione. Punti chiave Riassumo gli aspetti pi\u00f9 importanti relativi alle prestazioni della scadenza delle chiavi in modo che i principianti possano iniziare subito e gli utenti avanzati possano ottimizzare il sistema in modo mirato. I seguenti punti chiave si concentrano sulle leve pi\u00f9 efficaci e indicano dove si verificano i tipici colli di bottiglia. Mi concentro in particolare sulle strategie TTL, sulla pulizia attiva e passiva e sul comportamento di eviction. Inoltre, definisco indicatori di monitoraggio che rendono visibili i problemi in fase precoce. In questo modo \u00e8 possibile valutare sistematicamente le prestazioni e controllarle nel lungo periodo. Scadenza pigra (lazy) vs. attiva (active): comprendere e misurare l\u2019interazione Dispersione del TTL: offset contro la scadenza simultanea Ottimizzazione hz: Bilanciare la frequenza dei cicli in background. Politica di eviction: allkeys-lru vs. varianti volatile. Monitoraggio: osservare i valori di scadenza, eviction e latenza. Punto su TTL coerenti, pulizia adattiva e soglie chiare. In questo modo distribuisco i tempi di scadenza, evito evizioni inutili e mantengo i tempi di risposta affidabilmente bassi. Inoltre, utilizzo metriche che segnalano immediatamente le fasi anomale e consentono di adottare contromisure precise. Scadenza delle chiavi Redis: funzionamento e impatto sulla latenza Redis combina la scadenza \u00ablazy\u00bb e quella \u00abactive\u00bb per coniugare elevate prestazioni con un carico della CPU limitato. Nella scadenza \u00ablazy\u00bb, il server cancella le chiavi solo al momento dell\u2019accesso, quando il TTL \u00e8 scaduto. In questo modo non si generano operazioni in background aggiuntive per i dati che vengono comunque letti regolarmente. La scadenza attiva integra il modello con scansioni brevi e frequenti delle chiavi in scadenza, al fine di rimuovere le voci dimenticate. Questa architettura mantiene basse le latenze e libera memoria senza ricorrere a costose scansioni permanenti. Si verifica una latenza percepibile soprattutto quando un numero molto elevato di voci scade in un breve lasso di tempo. In tal caso, Redis dedica pi\u00f9 risorse della CPU alla pulizia attiva, riducendo temporaneamente la capacit\u00e0 disponibile per le operazioni dei client. Ulteriore pressione sulla memoria v"},"I3":{"id":"I3","post_id":21547,"url":"https:\/\/webhosting.de\/redis-expire-strategien-grosse-cache-systeme-cache-architektur\/","title":"Strategie di scadenza di Redis per sistemi di cache di grandi dimensioni: guida pratica all'ottimizzazione delle prestazioni","excerpt":"Senza strategie pianificate di scadenza (expire) in Redis, i grandi cluster di cache provocano rapidamente colli di bottiglia nella memoria e latenze variabili; ti mostrer\u00f2 come combinare TTL, eviction e invalidazione in modo da evitare picchi di carico. Fornir\u00f2 best practice concrete per la progettazione delle chiavi, i tempi di scadenza e il monitoraggio, che funzionano in modo affidabile nelle installazioni di produzione. Punti chiave: comprendere e configurare in modo coerente la separazione tra scadenza ed eviction; impostare il TTL ovunque, combinando il jitter con l\u2019invalidazione contro il fenomeno del \u201eThundering Herd\u201c: Delete-on-write, tag, versioning; scegliere consapevolmente la politica di eviction e testarla con maxmemory; orientare il monitoraggio verso le chiavi scadute\/evictate, l\u2019hit rate e le latenze; scadenza vs. eviction: Come Redis esegue la cancellazione Nella mia pianificazione distinguo sempre chiaramente tra scadenza ed espulsione, poich\u00e9 entrambi i processi perseguono obiettivi diversi. La scadenza rimuove le chiavi allo scadere del TTL, mentre l\u2019espulsione interviene solo quando lo spazio di memoria configurato \u00e8 esaurito. Ad ogni accesso, Redis verifica tramite Lazy Expiration se una chiave \u00e8 scaduta e, inoltre, pulisce attivamente a intervalli regolari le voci selezionate in modo casuale. Questo approccio misto evita l\u2019overhead del timer per ogni chiave e mantiene basso l\u2019onere amministrativo. Chi comprende questo meccanismo pu\u00f2 controllare in modo mirato quanta memoria \u201cmorta\u201d \u00e8 tollerabile nel breve termine, senza provocare cache miss impreviste. Progettazione del TTL: tempi, jitter e tiering Assegno un TTL a ogni chiave della cache, anche quando utilizzo l\u2019invalidazione esplicita, poich\u00e9 un tempo di scadenza costituisce un\u2019importante rete di sicurezza. Per i dati vicini all\u2019utente, spesso parto da 5\u201315 minuti, ma adatto l\u2019intervallo in base alla frequenza delle modifiche e alla tolleranza per le letture obsolete. Alle sessioni assegno durate brevi, ai dettagli dei prodotti durate piuttosto pi\u00f9 lunghe, alle configurazioni ancora pi\u00f9 margine; in questo modo distribuisco il rischio e livello il carico. Inoltre, aggiungo un leggero jitter, ad esempio \u00b110 %, in modo che non scadano migliaia di chiavi contemporaneamente. Nelle cache multilivello, faccio in modo che la memoria dell\u2019app agisca in secondi, Redis operi in minuti o ore e i livelli a monte rimangano attivi pi\u00f9 a lungo, per evitare costose ricostruzioni. Invalidazione esplicita senza effetti collaterali 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":"Replica di Redis | Documentazione"},"S2":{"id":"S2","url":"https:\/\/redis.io\/docs\/latest\/commands\/info\/","title":"INFO | Documenti"},"S3":{"id":"S3","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai","title":"Replica di Redis | Documentazione"},"S4":{"id":"S4","url":"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf","title":"redis\/redis.conf su 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":"Replica del database | Documentazione"},"S6":{"id":"S6","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/","title":"Amministrazione di Redis | Documentazione"}},"_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":"Comprendere il backlog di replica di Redis: PSYNC, dimensioni e limiti di alta disponibilit\u00e0","slug":"comprendere-il-backlog-di-replica-di-redis","excerpt":"Il backlog di replica di Redis conserva una porzione limitata del flusso di replica. Spesso, in seguito a brevi interruzioni della connessione, consente di eseguire un PSYNC anzich\u00e9 un full resync, ma non sostituisce n\u00e9 l'archiviazione persistente dei dati n\u00e9 un sistema di alta disponibilit\u00e0 ben progettato.","seo":{"title":"Comprendere il backlog di replica di Redis e pianificarlo correttamente","description":"Scopri cosa memorizza il backlog di replica di Redis, come funziona PSYNC, come pianificarne le dimensioni e quali sono i limiti relativi all'alta disponibilit\u00e0.","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\/it\/wp-json\/wp\/v2\/posts\/21633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21633"}],"version-history":[{"count":5,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21633\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21633\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21637"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}