{"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":"entender-el-backlog-de-replicacion-de-redis","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-replication-backlog-verstehen\/","title":{"rendered":"Entender el backlog de replicaci\u00f3n de Redis: PSYNC, tama\u00f1o y l\u00edmites de alta disponibilidad"},"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;\">El <strong style=\"font-weight:700;color:#153e50;\">Pendiente de replicaci\u00f3n de Redis<\/strong> determina, entre otras cosas, si, tras una interrupci\u00f3n de la conexi\u00f3n, una r\u00e9plica solo recupera los cambios que faltan o si se le vuelve a transmitir todo el conjunto de datos. Si se dimensiona el b\u00fafer en funci\u00f3n del volumen real de replicaci\u00f3n, se pueden evitar sincronizaciones completas innecesarias. Para ello, sin embargo, el historial de replicaci\u00f3n, el presupuesto de almacenamiento y los procesos operativos deben estar en consonancia: un gran volumen de trabajo pendiente no sustituye ni a la persistencia ni a un concepto de conmutaci\u00f3n por error robusto. <\/p><nav aria-label=\"Contenido de este art\u00edculo\" 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;\">Ir directamente a la secci\u00f3n<\/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;\">Qu\u00e9 almacena realmente el 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;\">Cu\u00e1ndo basta con un PSYNC y cu\u00e1ndo es necesaria una resincronizaci\u00f3n 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;\">Medir la tasa de replicaci\u00f3n en lugar de estimar el tama\u00f1o de la base de datos<\/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;\">Calcular de forma transparente el volumen de la cartera de pedidos pendientes<\/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;\">Modificar la configuraci\u00f3n de Redis de forma clara y controlada<\/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;\">Seguimiento: qu\u00e9 valores van juntos<\/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;\">C\u00f3mo interpretar correctamente el presupuesto de almacenamiento y las r\u00e9plicas lentas<\/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;\">Por qu\u00e9 un gran volumen de trabajo pendiente no garantiza por s\u00ed solo una alta disponibilidad<\/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;\">Probar los cambios e identificar los problemas recurrentes<\/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;\">Qu\u00e9 almacena realmente el backlog<\/h2><p style=\"margin:0 0 22px;\">En <strong style=\"font-weight:700;color:#153e50;\">Replicaci\u00f3n de Redis<\/strong> El servidor principal procesa los cambios en el conjunto de datos y transmite un flujo continuo de comandos a sus r\u00e9plicas. Esto no solo incluye los valores escritos directamente por los clientes. Las claves caducadas o sustituidas tambi\u00e9n pueden provocar cambios que deben transmitirse. El backlog mantiene en la memoria una muestra limitada y reciente de este flujo de replicaci\u00f3n. Por lo tanto, no contiene una copia completa adicional de la base de datos ni es un archivo de operaciones de escritura de cualquier antig\u00fcedad. <\/p><p style=\"margin:0 0 22px;\">En condiciones normales de funcionamiento, las r\u00e9plicas siguen el flujo de datos en curso. Si se interrumpe una conexi\u00f3n, el historial sigue creciendo en el servidor primario. Tras restablecerse la conexi\u00f3n, la r\u00e9plica intenta reanudarse desde el punto en el que se encontraba. En ese momento, es fundamental que a\u00fan se disponga de los bytes necesarios. Si es as\u00ed y el historial de replicaci\u00f3n coincide, Redis puede completar la informaci\u00f3n que falta. Para ello, no es necesario sustituir por completo los datos ya existentes en la r\u00e9plica. <\/p><p style=\"margin:0 0 22px;\">Su utilidad es especialmente notable en caso de interrupciones breves de la red, cambios de conexi\u00f3n y trabajos de mantenimiento programados. Una sincronizaci\u00f3n completa de un gran volumen de datos requiere capacidad de transmisi\u00f3n y potencia de c\u00e1lculo; dependiendo de la configuraci\u00f3n, a ello se suman otras cargas sobre el almacenamiento y los soportes de datos. El backlog puede reducir este esfuerzo, pero no es capaz de compensar cualquier tipo de interrupci\u00f3n. Un reinicio del proceso o un historial modificado requieren un enfoque diferente al de una conexi\u00f3n TCP que se ha interrumpido brevemente. <\/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;\">Cu\u00e1ndo basta con un PSYNC y cu\u00e1ndo es necesaria una resincronizaci\u00f3n completa<\/h2><p style=\"margin:0 0 22px;\">A <strong style=\"font-weight:700;color:#153e50;\">Resincronizaci\u00f3n parcial con PSYNC<\/strong> Requiere dos datos relacionados entre s\u00ed: el ID de replicaci\u00f3n y el desplazamiento. El ID identifica un historial de datos concreto. El desplazamiento describe una posici\u00f3n en bytes dentro del flujo de replicaci\u00f3n. Por lo tanto, dos desplazamientos del mismo tama\u00f1o procedentes de historiales diferentes no son autom\u00e1ticamente comparables. Por el contrario, un peque\u00f1o retraso en el mismo historial puede quedar ya fuera del backlog disponible si la capacidad de este es limitada.  <\/p><p style=\"margin:0 0 22px;\">En t\u00e9rminos sencillos, la r\u00e9plica, al volver a conectarse, informa hasta qu\u00e9 punto ha llegado. La primaria comprueba si puede proporcionar los datos necesarios a partir de ah\u00ed. Si se desconoce el historial o falta la secci\u00f3n necesaria, se produce un <strong style=\"font-weight:700;color:#153e50;\">Resincronizaci\u00f3n completa<\/strong> es necesario. De este modo, la r\u00e9plica recibe un conjunto completo de datos y, a continuaci\u00f3n, los cambios producidos durante la sincronizaci\u00f3n. La transferencia puede realizarse, dependiendo de la configuraci\u00f3n, con un paso intermedio en una base de datos relacional (RDB) o sin dicho paso intermedio.  <\/p><p style=\"margin:0 0 22px;\">Tras una conmutaci\u00f3n por error, no siempre es inevitable una resincronizaci\u00f3n completa. Una r\u00e9plica trasladada puede, adem\u00e1s, recordar el ID de replicaci\u00f3n anterior y su rango de desplazamiento v\u00e1lido. De este modo, otras r\u00e9plicas pueden incorporarse al historial conocido si se dan las condiciones adecuadas. Sin embargo, esto no supone ninguna garant\u00eda a efectos de planificaci\u00f3n: el rango relevante debe seguir estando disponible y la reconexi\u00f3n concreta debe coincidir con los ID almacenados.  <\/p><div aria-label=\"Reconexi\u00f3n de una r\u00e9plica: posibles resultados\" 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;\">Reconexi\u00f3n de una r\u00e9plica: posibles resultados<\/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;\">Situaci\u00f3n<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Requisito previo<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Resultado<\/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 interrupci\u00f3n<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Historial adecuado; los bytes necesarios a\u00fan est\u00e1n disponibles<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">PSYNC solo puede recuperar los datos de replicaci\u00f3n que faltan.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Se han sobrescrito los bytes m\u00e1s antiguos necesarios<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">El intervalo solicitado se encuentra fuera del historial disponible<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Un reajuste completo en lugar de una reanudaci\u00f3n parcial.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Historial de replicaci\u00f3n desconocido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">El ID de replicaci\u00f3n no se reconoce como v\u00e1lido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Un mayor volumen de trabajo pendiente por s\u00ed solo no resuelve el problema.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Conmutaci\u00f3n por error con un ID de predecesor conocido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">ID secundario almacenado, rango de desplazamiento v\u00e1lido e historial suficiente<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">A\u00fan as\u00ed, podr\u00eda ser posible una resincronizaci\u00f3n parcial.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Se ha liberado el backlog tras la separaci\u00f3n de todas las r\u00e9plicas<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">El TTL ha caducado; no queda ning\u00fan historial v\u00e1lido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">La reconexi\u00f3n posterior requiere una sincronizaci\u00f3n 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 ventana limitada en el flujo de datos muestra qu\u00e9 datos de replicaci\u00f3n que faltan siguen estando disponibles tras una interrupci\u00f3n.\" 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;\">Ilustraci\u00f3n esquem\u00e1tica: PSYNC solo puede conectarse a un historial de replicaci\u00f3n compatible y que a\u00fan est\u00e9 disponible.<\/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;\">Medir la tasa de replicaci\u00f3n en lugar de estimar el tama\u00f1o de la base de datos<\/h2><p style=\"margin:0 0 22px;\">El mero volumen de la base de datos basta para <strong style=\"font-weight:700;color:#153e50;\">Dimensionamiento de la cartera de pedidos<\/strong> No es as\u00ed. Una base de datos grande, en la que predominan las operaciones de lectura, puede generar poco tr\u00e1fico de replicaci\u00f3n. Por el contrario, una cach\u00e9 peque\u00f1a con valores que cambian con frecuencia y muchos eventos de caducidad puede transmitir continuamente cantidades considerables de datos. Adem\u00e1s, un n\u00famero fijo de operaciones por segundo no describe de forma suficiente la memoria necesaria: los peque\u00f1os cambios en las claves y las grandes sobrescrituras de valores no ocupan el mismo n\u00famero de bytes.  <\/p><p style=\"margin:0 0 22px;\">Se obtiene una aproximaci\u00f3n \u00fatil a partir del incremento temporal de <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>. Registra el valor dos veces en el mismo servidor primario y divide la diferencia entre los segundos transcurridos. Comprueba tambi\u00e9n el ID de replicaci\u00f3n. Tras un cambio de rol o un reinicio, no debes simplemente restar entre s\u00ed dos puntos de medici\u00f3n que no pertenezcan al mismo conjunto. Adem\u00e1s, un \u00fanico intervalo de medici\u00f3n solo proporciona una tasa media dentro de ese intervalo, no un l\u00edmite m\u00e1ximo garantizado de forma permanente.  <\/p><p style=\"margin:0 0 22px;\">La siguiente consulta lee informaci\u00f3n de diagn\u00f3stico. No modifica ninguna configuraci\u00f3n de Redis. Ejec\u00fatala con las opciones de conexi\u00f3n y autenticaci\u00f3n necesarias en tu entorno. La llamada que se muestra a continuaci\u00f3n utiliza la conexi\u00f3n predeterminada de <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">redis-cli<\/code>; es necesario configurar expresamente otro servidor, puerto o acceso 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;\">Realiza mediciones a lo largo de diferentes fases de carga, por ejemplo, durante la actividad diaria habitual, en las importaciones y durante las renovaciones importantes de la cach\u00e9. Documenta tanto las tasas habituales como los picos breves. Si se producen muchos cambios debido a la caducidad de claves, el art\u00edculo interno te ayudar\u00e1 a profundizar en el tema. <a href=\"https:\/\/webhosting.de\/es\/redis-clave-caducidad-rendimiento-analizar-optimizar-cache\/\">Analizar la caducidad de las claves de Redis<\/a>. Esta relaci\u00f3n es importante para la planificaci\u00f3n, ya que no todos los impulsos de escritura relevantes surgen directamente de una nueva solicitud del usuario.  <\/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;\">Calcular de forma transparente el volumen de la cartera de pedidos pendientes<\/h2><p style=\"margin:0 0 22px;\">Como <strong style=\"font-weight:700;color:#153e50;\">Aproximaci\u00f3n de planificaci\u00f3n<\/strong> Puedes multiplicar la tasa de replicaci\u00f3n pertinente por la duraci\u00f3n de la interrupci\u00f3n que hay que cubrir y, a continuaci\u00f3n, a\u00f1adir una reserva justificada. La duraci\u00f3n no debe tener en cuenta \u00fanicamente la interrupci\u00f3n real de la red. La detecci\u00f3n, los intentos de reconexi\u00f3n y el restablecimiento de la ruta de conexi\u00f3n tambi\u00e9n pueden llevar tiempo. La reserva adecuada depende de las fluctuaciones observadas y del objetivo operativo deseado, no de un porcentaje universal. <\/p><p style=\"margin:0 0 22px;\">Un ejemplo de c\u00e1lculo deliberadamente simplificado: para una fase de carga determinada, se calculan 12 MiB por segundo. La conexi\u00f3n podr\u00eda estar interrumpida durante 90 segundos; adem\u00e1s, se prev\u00e9n otros 30 segundos como reserva de tiempo. De ello se deduce que <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>, es decir, unos 1,41 GiB. Estas cifras son valores estimados a modo de ejemplo y no constituyen una prueba de rendimiento de Redis. Antes de ponerlo en producci\u00f3n, deben sustituirse por los valores medidos en tu aplicaci\u00f3n. <\/p><figure class=\"wh-chart\"><figcaption>Necesidad de backlog suponiendo 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 segundos<\/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 segundos<\/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 segundos<\/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 segundos<\/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;\">Ejemplo ilustrativo de c\u00e1lculo, no es una medici\u00f3n: necesidad = 12 MiB\/s (valor estimado) \u00d7 duraci\u00f3n total seleccionada. Los 120 segundos del ejemplo del texto incluyen 90 segundos de interrupci\u00f3n y 30 segundos de reserva de tiempo. Aqu\u00ed no se incluyen otras reservas.<\/p><details><summary>Tabla de datos correspondiente al gr\u00e1fico<\/summary><table><thead><tr><th scope=\"col\">Entrada<\/th><th scope=\"col\">MiB<\/th><\/tr><\/thead><tbody><tr><td>30 segundos<\/td><td>360<\/td><\/tr><tr><td>60 segundos<\/td><td>720<\/td><\/tr><tr><td>120 segundos<\/td><td>1440<\/td><\/tr><tr><td>180 segundos<\/td><td>2160<\/td><\/tr><\/tbody><\/table><\/details><\/figure><p style=\"margin:0 0 22px;\">El c\u00e1lculo inverso ayuda a valorar la capacidad de un b\u00fafer existente. Un backlog completamente lleno de 256 MiB equivale, te\u00f3ricamente, a unos 21 segundos de historial si se mantiene una tasa constante de 12 MiB por segundo. A 2 MiB por segundo, ser\u00edan unos 128 segundos. Sin embargo, en una aplicaci\u00f3n real, las tasas var\u00edan. Por lo tanto, ese alcance es una instant\u00e1nea y no una garant\u00eda de que cualquier interrupci\u00f3n de esa duraci\u00f3n pueda sincronizarse parcialmente. <\/p><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Dos ventanas de historial del mismo tama\u00f1o, con flujos de datos de diferente densidad, ilustran la influencia de la tasa de replicaci\u00f3n.\" 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;\">Ilustraci\u00f3n conceptual: con el mismo tama\u00f1o de b\u00fafer, un flujo de replicaci\u00f3n mayor reduce el alcance temporal.<\/figcaption><\/figure><p style=\"margin:0 0 22px;\">Comprueba, adem\u00e1s, si la r\u00e9plica, tras volver a conectarse, es capaz de ponerse al d\u00eda m\u00e1s r\u00e1pido de lo que se producen nuevos cambios. Aumentar el historial no soluciona ni una red que sea demasiado lenta de forma permanente ni un receptor que est\u00e9 constantemente sobrecargado. Si el retraso persiste o sigue aumentando, hay que investigar la causa. De lo contrario, destinar cada vez m\u00e1s memoria solo pospone el problema y puede someter a todo el sistema a una presi\u00f3n de almacenamiento excesiva. <\/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;\">Modificar la configuraci\u00f3n de Redis de forma clara y controlada<\/h2><p style=\"margin:0 0 22px;\">Los par\u00e1metros <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> y <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> controlan aspectos diferentes. El primero describe el tama\u00f1o previsto del backlog. El segundo determina, en el servidor principal, tras cu\u00e1nto tiempo sin r\u00e9plicas conectadas se puede liberar el backlog. Es <strong style=\"font-weight:700;color:#153e50;\">No hay una duraci\u00f3n m\u00e1xima de interrupci\u00f3n para PSYNC<\/strong>. Mientras se siga sobrescribiendo el b\u00fafer o falte alg\u00fan otro requisito, un TTL largo por s\u00ed solo no sirve de nada.   <\/p><p style=\"margin:0 0 22px;\">Las siguientes l\u00edneas proceden de la plantilla de configuraci\u00f3n de Redis 7.2.0 y aparecen como valores predeterminados comentados. Los s\u00edmbolos de comentario se han conservado intencionadamente. El mero hecho de copiar estas l\u00edneas no activa ninguna configuraci\u00f3n; adem\u00e1s, los valores mencionados no constituyen una recomendaci\u00f3n general de capacidad para sistemas en producci\u00f3n.   <\/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 liberaci\u00f3n programada se desactiva tras desconectar todas las r\u00e9plicas. Esto no conserva un historial ilimitado: los nuevos datos de replicaci\u00f3n pueden seguir sobrescribiendo el b\u00fafer existente. Tampoco se garantiza la persistencia tras cualquier reinicio del proceso. Por lo tanto, eval\u00faa cuidadosamente si el consumo adicional de memoria se ajusta al comportamiento de reconexi\u00f3n previsto.   <\/p><p style=\"margin:0 0 22px;\">Antes de realizar cualquier cambio, debes consultar los valores realmente vigentes y aclarar el procedimiento de implementaci\u00f3n. Una variable de entorno del contenedor, un archivo de configuraci\u00f3n gestionado y un ajuste modificado en tiempo de ejecuci\u00f3n no son lo mismo. Si posteriormente se vuelve a crear una instancia, solo se pueden perder los ajustes realizados en tiempo de ejecuci\u00f3n. Las siguientes consultas son de solo lectura; no obstante, requieren los permisos de acceso adecuados.   <\/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;\">En el caso de Managed Redis, el proveedor puede restringir el acceso a <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">CONFIG<\/code> restringir o gestionar la configuraci\u00f3n a trav\u00e9s de una interfaz propia. Esto no es motivo para eludir los mecanismos de protecci\u00f3n. En ese caso, utiliza los canales de gesti\u00f3n autorizados y documenta el tama\u00f1o seleccionado junto con el volumen de replicaci\u00f3n subyacente. En el plan de cambios tambi\u00e9n deben consignarse los valores actuales y una estrategia de reversi\u00f3n realista.   <\/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;\">Seguimiento: qu\u00e9 valores van juntos<\/h2><p style=\"margin:0 0 22px;\">Para la <strong style=\"font-weight:700;color:#153e50;\">Supervisi\u00f3n de la replicaci\u00f3n de Redis<\/strong> Un \u00fanico indicador verde de estado de conexi\u00f3n no es suficiente. Una conexi\u00f3n puede volver a estar activa mientras la r\u00e9plica sigue poni\u00e9ndose al d\u00eda o est\u00e1 cargando un conjunto completo de datos. Por el contrario, una breve interrupci\u00f3n de la conexi\u00f3n no tiene por qu\u00e9 ser cr\u00edtica de inmediato si el historial y la capacidad de recuperaci\u00f3n son suficientes. Por lo tanto, eval\u00faa conjuntamente la conexi\u00f3n, el estado de sincronizaci\u00f3n, la evoluci\u00f3n del desfase y el historial disponible. <\/p><div aria-label=\"Supervisi\u00f3n de Redis: interpretar los valores en su contexto\" 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;\">Supervisi\u00f3n de Redis: interpretar los valores en su contexto<\/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;\">Significado<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">En qu\u00e9 te fijas<\/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;\">Identidad del historial y desplazamiento actual en bytes en el servidor principal<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Compara los puntos de medici\u00f3n \u00fanicamente dentro de un mismo historial.<\/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;\">Si el backlog de replicaci\u00f3n est\u00e1 activo actualmente<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">El mero hecho de haber configurado un valor no implica que haya un historial disponible.<\/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;\">Desplazamiento del primer byte que a\u00fan est\u00e1 almacenado<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Los datos necesarios para la r\u00e9plica deben ajustarse al espacio disponible.<\/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;\">Duraci\u00f3n actual del historial y tama\u00f1o configurado<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Un b\u00fafer reci\u00e9n creado no tiene por qu\u00e9 estar completamente lleno todav\u00eda.<\/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;\">Conexi\u00f3n y sincronizaci\u00f3n continua desde el punto de vista de la r\u00e9plica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">El mero hecho de que un enlace vuelva a estar disponible no significa, por s\u00ed solo, que la sincronizaci\u00f3n se haya completado.<\/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;\">Progreso de la replicaci\u00f3n en una r\u00e9plica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Ten en cuenta la cronolog\u00eda y los antecedentes correspondientes.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 22px;\">Los campos de una <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">INFO<\/code>Las respuestas pueden variar entre las distintas versiones de Redis y entre el servidor principal y la r\u00e9plica. Por lo tanto, un an\u00e1lisis deber\u00eda tratar expresamente los campos que falten, en lugar de interpretarlos t\u00e1citamente como nulos o como un estado sin errores. Tambi\u00e9n las denominaciones <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master<\/code> y <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">slave<\/code> Por motivos de compatibilidad, siguen apareciendo en los nombres de los campos; no deben traducirse libremente en el c\u00f3digo ejecutable. <\/p><p style=\"margin:0 0 22px;\">Para interpretar el retraso, se debe consultar la gu\u00eda interna <a href=\"https:\/\/webhosting.de\/es\/redis-replica-desplazamiento-analisis-consistencia-de-datos-cluster\/\">Analizar el desplazamiento de replicaci\u00f3n de Redis<\/a> Un complemento adecuado. En el seguimiento continuo, deber\u00edas tener en cuenta las tendencias hist\u00f3ricas, y no solo dos cifras le\u00eddas manualmente. Una distancia que va aumentando requiere una reacci\u00f3n diferente a la que se da cuando la brecha se va reduciendo de forma constante tras un breve par\u00f3n. <\/p><p style=\"margin:0 0 22px;\">Las alertas \u00fatiles se basan en tus objetivos operativos: \u00bfDurante cu\u00e1nto tiempo puede estar inaccesible una r\u00e9plica? \u00bfCon qu\u00e9 rapidez debe recuperarse? \u00bfQu\u00e9 frecuencia de sincronizaciones completas se considera inusual? Los l\u00edmites r\u00edgidos que no tienen en cuenta el perfil de carga ni el volumen de datos suelen dar lugar a avisos innecesarios o pasar por alto deterioros reales. Adem\u00e1s de las m\u00e9tricas de replicaci\u00f3n, vigila tambi\u00e9n la utilizaci\u00f3n de la RAM, la carga de la red y los indicios de reinicios de procesos. <\/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;\">C\u00f3mo interpretar correctamente el presupuesto de almacenamiento y las r\u00e9plicas lentas<\/h2><p style=\"margin:0 0 22px;\">La cartera de pedidos es solo una parte del total <strong style=\"font-weight:700;color:#153e50;\">Requisitos de memoria de Redis<\/strong>. A esto hay que a\u00f1adir el conjunto de datos, las estructuras administrativas, los b\u00faferes de los clientes y, dependiendo del estado operativo, memoria adicional durante las tareas de persistencia o sincronizaci\u00f3n. Por lo tanto, no destines toda la memoria de trabajo disponible a los datos de usuario m\u00e1s un backlog calculado con exactitud. La reserva necesaria debe determinarse a partir del entorno concreto y de los picos de carga que se produzcan en \u00e9l.  <\/p><p style=\"margin:0 0 22px;\">Desde Redis 7.0, el b\u00fafer de r\u00e9plicas y la cola de replicaci\u00f3n comparten memoria. Por ello, la documentaci\u00f3n de INFO se\u00f1ala, entre otras cosas, que <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> puede ser nulo si los b\u00faferes de r\u00e9plica no superan la asignaci\u00f3n de backlog. Esto no significa, sin embargo, que la replicaci\u00f3n no ocupe memoria. Ten en cuenta los valores previstos para ello, como <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> y <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> ten en cuenta el contexto y no sumes ciegamente magnitudes que se solapan.  <\/p><p style=\"margin:0 0 22px;\">Un error de diagn\u00f3stico frecuente consiste en atribuir cada sincronizaci\u00f3n interrumpida a un retraso acumulado importante. Las r\u00e9plicas lentas, el ancho de banda de red limitado o el rebasamiento de los l\u00edmites del b\u00fafer de salida pueden deberse a otras causas. El par\u00e1metro <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> se refiere a la clase de cliente en cuesti\u00f3n y no debe confundirse 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> se deben considerar equivalentes. Antes de modificar los l\u00edmites, comprueba los registros, la documentaci\u00f3n de la versi\u00f3n y las posibles repercusiones en otras conexiones.  <\/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;\">Por qu\u00e9 un gran volumen de trabajo pendiente no garantiza por s\u00ed solo una alta disponibilidad<\/h2><p style=\"margin:0 0 22px;\">El backlog mejora la reconexi\u00f3n, pero no garantiza que la replicaci\u00f3n, que por defecto es as\u00edncrona, se realice sin p\u00e9rdidas. Un servidor primario puede haber confirmado ya una operaci\u00f3n de escritura al cliente antes de que una r\u00e9plica la haya procesado. Si el servidor primario falla durante ese intervalo, es posible que la operaci\u00f3n en cuesti\u00f3n no est\u00e9 presente en el sistema de sustituci\u00f3n seleccionado posteriormente. El tama\u00f1o del b\u00fafer por s\u00ed solo no resuelve este <strong style=\"font-weight:700;color:#153e50;\">Riesgo de p\u00e9rdida de datos durante la conmutaci\u00f3n por error<\/strong> no.   <\/p><p style=\"margin:0 0 22px;\">Tambi\u00e9n <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">WAIT<\/code> no convierte una topolog\u00eda de Redis en un sistema con consistencia fuerte garantizada. El comando puede esperar a recibir confirmaciones de las r\u00e9plicas; la seguridad real de los datos sigue dependiendo de otras circunstancias, en particular del comportamiento de persistencia y conmutaci\u00f3n por error. Del mismo modo, limitan <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> y <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> aceptar nuevas operaciones de escritura seg\u00fan sus respectivas condiciones, sin guardar autom\u00e1ticamente y de forma permanente cada operaci\u00f3n individual en varias instancias.   <\/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 replicaci\u00f3n no es una copia de seguridad<\/p><p style=\"margin:0 0 22px;\">Si un servidor primario se reinicia autom\u00e1ticamente sin persistencia y con una base de datos vac\u00eda, sus r\u00e9plicas pueden adoptar ese estado vac\u00edo. Un gran volumen de trabajo pendiente no impide que se produzca este escenario. Por lo tanto, garantiza conjuntamente el reinicio, la persistencia y la recuperaci\u00f3n; una r\u00e9plica por s\u00ed sola no sustituye a una copia de seguridad que se pueda utilizar de forma independiente.  <\/p><\/aside><p style=\"margin:0 0 22px;\">Para <strong style=\"font-weight:700;color:#153e50;\">Alta disponibilidad<\/strong> Por lo tanto, necesitas una decisi\u00f3n coherente que abarque: la p\u00e9rdida de datos tolerable, el tiempo de inactividad admisible, la persistencia, la detecci\u00f3n de fallos, la selecci\u00f3n del nuevo primario y la recuperaci\u00f3n. Sentinel o Redis Cluster pueden asumir otras tareas distintas a las del backlog. Quien se limite a aumentar el tama\u00f1o de un b\u00fafer y deje sin modificar el resto de supuestos, no dispondr\u00e1 a\u00fan de un plan de reinicio fiable.   <\/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;\">Probar los cambios e identificar los problemas recurrentes<\/h2><p style=\"margin:0 0 22px;\">Inicia una prueba controlada en un entorno aislado con una versi\u00f3n de Redis similar y una carga de escritura predecible. Antes de la interrupci\u00f3n, registra los ID de replicaci\u00f3n, los desplazamientos, el volumen de trabajo pendiente y el consumo de memoria. A continuaci\u00f3n, simula una interrupci\u00f3n limitada de la conexi\u00f3n sin modificar firewalls o procesos de producci\u00f3n sin haberlos comprobado previamente. Tras restablecer la conexi\u00f3n, observa si se produce una sincronizaci\u00f3n parcial o completa y cu\u00e1nto tiempo tarda en completarse.  <\/p><p style=\"margin:0 0 22px;\">En cada prueba, cambia, en la medida de lo posible, solo una variable relevante. Si cambian al mismo tiempo el backlog, la carga de escritura y las condiciones de la red, resulta muy dif\u00edcil determinar el efecto concreto. Repite la prueba con diferentes duraciones de interrupci\u00f3n y distintas fases de carga. De este modo, una sola reconexi\u00f3n satisfactoria se convierte en una evaluaci\u00f3n comprensible del comportamiento. Los l\u00edmites observados deben documentarse, sin deducir de ellos una garant\u00eda para cualquier fallo futuro.  <\/p><p style=\"margin:0 0 22px;\">En caso de resincronizaciones completas repetidas, comprueba primero si el historial es compatible. A continuaci\u00f3n, f\u00edjate en los bytes que a\u00fan faltan, el tiempo sin r\u00e9plica, las indicaciones de reinicios y la velocidad real de recuperaci\u00f3n. Un b\u00fafer demasiado peque\u00f1o es una posible causa, pero no la \u00fanica. Es especialmente importante distinguir entre una interrupci\u00f3n puntual demasiado prolongada y una r\u00e9plica que se queda rezagada de forma permanente, incluso con conexi\u00f3n activa.  <\/p><p style=\"margin:0 0 22px;\">La configuraci\u00f3n adecuada es, en definitiva, aquella que cubre el margen de fallo que hayas definido con una carga realista y deja memoria suficiente para el resto del funcionamiento. Anota siempre la base de medici\u00f3n, la fuente de configuraci\u00f3n y la fecha de la comprobaci\u00f3n. Tras cambios importantes en el comportamiento de escritura, en la topolog\u00eda o en la versi\u00f3n de Redis, hay que volver a revisar el dimensionamiento. De este modo, el backlog seguir\u00e1 siendo una decisi\u00f3n operativa fundamentada, en lugar de una cifra fijada una vez por todas.  <\/p><section class=\"wh-sources\" style=\"margin-top:50px;padding-top:25px;border-top:1px solid #dce6eb;font-size:14px;color:#607381;\"><h2>Fuentes y estado actual de los conocimientos<\/h2><p style=\"margin:0 0 22px;\">Estado de la investigaci\u00f3n: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p style=\"margin:0 0 22px;\">Los ejemplos de configuraci\u00f3n se basan en la versi\u00f3n estable 7.2.0 de Redis, no en la rama de desarrollo \u00abunstable\u00bb. Seg\u00fan la documentaci\u00f3n de INFO, la asignaci\u00f3n de memoria compartida descrita es v\u00e1lida a partir de Redis 7.0. Los mecanismos generales se refieren a Redis de c\u00f3digo abierto; no se transfieren los valores predeterminados del software Redis ni de la nube. Fecha de actualizaci\u00f3n de la documentaci\u00f3n: 21 de septiembre de 2026. No se han realizado pruebas de laboratorio con Redis por cuenta propia.<\/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>La cola de replicaci\u00f3n de Redis almacena una parte limitada del flujo de replicaci\u00f3n. A menudo permite realizar un PSYNC en lugar de una resincronizaci\u00f3n completa tras breves interrupciones de la conexi\u00f3n, pero no sustituye ni al almacenamiento persistente de datos ni a un concepto bien dise\u00f1ado de alta disponibilidad.<\/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":"Comprender y analizar el desplazamiento de replicaci\u00f3n de Redis para lograr una alta consistencia de los datos","excerpt":"Mostrar\u00e9 c\u00f3mo leo y analizo el offset de Redis de forma espec\u00edfica y c\u00f3mo lo utilizo para lograr una alta consistencia de los datos. De este modo, detecto a tiempo las brechas de replicaci\u00f3n, eval\u00fao los riesgos de conmutaci\u00f3n por error y mantengo los cl\u00fasteres productivos sincronizados de forma fiable. Puntos clave: Las siguientes ideas fundamentales sirven de introducci\u00f3n espec\u00edfica al tema, la terminolog\u00eda y la aplicaci\u00f3n pr\u00e1ctica. El offset mide el progreso del flujo de replicaci\u00f3n byte a byte. El retraso (Lag) es la diferencia entre master_repl_offset y slave_repl_offset. El ID + offset identifica una versi\u00f3n exacta de los datos para las sincronizaciones parciales. El backlog evita las sincronizaciones completas en caso de breves interrupciones de conexi\u00f3n. La supervisi\u00f3n mediante m\u00e9tricas INFO\/de cl\u00faster controla las alertas y la conmutaci\u00f3n por error. \u00bfQu\u00e9 significa el \u00aboffset de replicaci\u00f3n\u00bb de Redis? El offset de replicaci\u00f3n es un contador continuo de 64 bits que refleja cada flujo de bytes transmitido entre el primario y la r\u00e9plica. A partir de \u00e9l, puedo determinar hasta qu\u00e9 punto ha avanzado la replicaci\u00f3n y si una r\u00e9plica a\u00fan tiene trabajo pendiente. El `master_repl_offset` del primario aumenta con cada byte reci\u00e9n generado, mientras que la r\u00e9plica incrementa su propio contador tan pronto como ha aplicado los comandos. Las diferencias dan lugar a un desfase en bytes e indican si la r\u00e9plica va con retraso. Esta sem\u00e1ntica sencilla pero eficaz convierte al offset en la cifra clave para la sincronizaci\u00f3n, el an\u00e1lisis de fallos y la toma de decisiones acertadas en caso de conmutaci\u00f3n por error. Lectura de los offsets: uso correcto de INFO replication Casi siempre comienzo el diagn\u00f3stico con INFO replication, ya que este comando proporciona los campos relevantes de forma concisa. En el primario, compruebo master_repl_offset, as\u00ed como el estado de las r\u00e9plicas conectadas, incluidos sus offsets. En una r\u00e9plica, compruebo adem\u00e1s master_link_status y los estados de sincronizaci\u00f3n para detectar sincronizaciones completas o parciales en curso. Para un an\u00e1lisis m\u00e1s detallado, recurro a salidas estructuradas y correlaciono los offsets con los valores de CPU, E\/S y red. Esta gu\u00eda me ofrece una introducci\u00f3n detallada al comando: Redis INFO para la monitorizaci\u00f3n. ID de replicaci\u00f3n + desplazamiento: versi\u00f3n \u00fanica de los datos. Para obtener una versi\u00f3n \u00fanica, utilizo la combinaci\u00f3n del ID de replicaci\u00f3n y el desplazamiento. El ID marca un historial, mientras que el desplazamiento indica una posici\u00f3n dentro del"},"I2":{"id":"I2","post_id":21597,"url":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":"Analizar y optimizar el rendimiento de la caducidad de claves en Redis","excerpt":"Analizo de forma espec\u00edfica el rendimiento de la caducidad de claves de Redis y lo optimizo mediante pasos claros y cuantificables. De este modo, reduzco la latencia, suavizo los picos de carga y mantengo bajo control el consumo de memoria, sin comprometer el rendimiento. Puntos clave: resumo los aspectos m\u00e1s importantes sobre el rendimiento de la caducidad de claves de manera que los principiantes puedan empezar directamente y los usuarios avanzados puedan realizar ajustes espec\u00edficos. Los siguientes puntos clave se centran en los ajustes m\u00e1s eficaces y muestran d\u00f3nde surgen los cuellos de botella t\u00edpicos. Para ello, me centro en las estrategias de TTL, la limpieza activa y pasiva, as\u00ed como en el comportamiento de expulsi\u00f3n. Adem\u00e1s, establezco indicadores de monitorizaci\u00f3n que permiten detectar los problemas de forma temprana. De este modo, se puede evaluar el rendimiento de forma sistem\u00e1tica y controlarlo a largo plazo. Caducidad \u00ablazy\u00bb frente a \u00abactiva\u00bb: comprender y medir la interacci\u00f3n. Dispersi\u00f3n del TTL: compensaciones frente a la caducidad simult\u00e1nea. Ajuste de hz: Equilibrar la frecuencia de los ciclos en segundo plano. Pol\u00edtica de expulsi\u00f3n: \u00aballkeys-lru\u00bb frente a variantes \u00abvolatile\u00bb. Supervisi\u00f3n: observar los valores de caducidad, expulsi\u00f3n y latencia. Apuesto por TTL coherentes, una limpieza adaptativa y l\u00edmites claros. De este modo, distribuyo los momentos de caducidad, evito expulsiones innecesarias y mantengo los tiempos de respuesta fiablemente bajos. Adem\u00e1s, utilizo m\u00e9tricas que se\u00f1alan inmediatamente las fases an\u00f3malas y permiten tomar contramedidas precisas. Caducidad de claves en Redis: funcionamiento e influencia en la latencia. Redis combina la caducidad \u00ablazy\u00bb y la \u00abactiva\u00bb para combinar un alto rendimiento con una carga de CPU limitada. En la caducidad \u00ablazy\u00bb, el servidor solo elimina las claves al acceder a ellas cuando ha caducado el TTL. De este modo, no se generan operaciones en segundo plano adicionales para datos que, de todos modos, se leen peri\u00f3dicamente. La caducidad activa complementa el modelo mediante escaneos breves y frecuentes de las claves que est\u00e1n a punto de caducar, con el fin de eliminar las entradas olvidadas. Esta arquitectura mantiene bajas las latencias y libera memoria sin necesidad de costosos escaneos permanentes. Se produce una latencia apreciable sobre todo cuando un gran n\u00famero de entradas caducan en un intervalo de tiempo reducido. En ese caso, Redis dedica m\u00e1s recursos de CPU a la limpieza activa, lo que reduce temporalmente la capacidad para las operaciones de los clientes. La presi\u00f3n adicional sobre la memoria v"},"I3":{"id":"I3","post_id":21547,"url":"https:\/\/webhosting.de\/redis-expire-strategien-grosse-cache-systeme-cache-architektur\/","title":"Estrategias de caducidad de Redis para grandes sistemas de cach\u00e9: gu\u00eda pr\u00e1ctica para la optimizaci\u00f3n del rendimiento","excerpt":"Los grandes cl\u00fasteres de cach\u00e9, si no se aplican estrategias planificadas de caducidad en Redis, provocan r\u00e1pidamente cuellos de botella en la memoria y latencias variables; te mostrar\u00e9 c\u00f3mo combinar el TTL, la expulsi\u00f3n y la invalidaci\u00f3n para evitar picos de carga. Te proporciono pr\u00e1cticas recomendadas concretas para el dise\u00f1o de claves, los tiempos de caducidad y la monitorizaci\u00f3n, que funcionan de forma fiable en entornos de producci\u00f3n. Puntos clave: comprender y configurar de forma coherente la separaci\u00f3n entre caducidad y expulsi\u00f3n; establecer el TTL en todas partes, adem\u00e1s de combinar el jitter con la invalidaci\u00f3n contra el \u201eThundering Herd\u201c: \u00abDelete-on-write\u00bb, etiquetas, control de versiones. Elegir conscientemente la pol\u00edtica de expulsi\u00f3n y probarla con \u00abmaxmemory\u00bb. Orientar la monitorizaci\u00f3n hacia las claves caducadas o expulsadas, la tasa de aciertos y las latencias. Caducidad frente a expulsi\u00f3n: C\u00f3mo borra Redis En mi planificaci\u00f3n, siempre distingo claramente entre caducidad y expulsi\u00f3n, ya que ambos procesos persiguen objetivos diferentes. La caducidad elimina las claves al vencimiento del TTL, mientras que la expulsi\u00f3n solo se aplica cuando se agota el l\u00edmite de memoria configurado. Con la caducidad diferida (Lazy Expiration), Redis comprueba en cada acceso si una clave ha caducado y, adem\u00e1s, limpia activamente, a intervalos, las entradas seleccionadas al azar. Este m\u00e9todo mixto evita la sobrecarga del temporizador por clave y mantiene baja la carga administrativa. Quien comprenda este mecanismo puede controlar de forma espec\u00edfica cu\u00e1nta memoria \u00abmuerta\u00bb se tolera a corto plazo sin provocar fallos inesperados en la cach\u00e9. Dise\u00f1o del TTL: tiempos, fluctuaciones y jerarquizaci\u00f3n Asigno un TTL a cada clave de cach\u00e9, incluso cuando utilizo la invalidaci\u00f3n expl\u00edcita, ya que un tiempo de caducidad constituye una importante red de seguridad. Para los datos cercanos al usuario, suelo empezar con 5-15 minutos, pero adapto el intervalo a la frecuencia de cambios y a la tolerancia a las lecturas obsoletas. Las sesiones tienen duraciones cortas, los detalles de los productos suelen tenerlas m\u00e1s largas y las configuraciones cuentan con un margen a\u00fan mayor; as\u00ed distribuyo el riesgo y suavizo la carga. Adem\u00e1s, a\u00f1ado un ligero jitter, de unos \u00b110 %, para que no caduquen miles de claves al mismo tiempo. En las cach\u00e9s de varios niveles, hago que la memoria de la aplicaci\u00f3n act\u00fae en segundos, que Redis funcione en minutos u horas y que los niveles previos se mantengan durante m\u00e1s tiempo, para evitar costosas reconstrucciones. Invalidaci\u00f3n expl\u00edcita sin efectos secundarios 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":"Replicaci\u00f3n de Redis | Documentaci\u00f3n"},"S2":{"id":"S2","url":"https:\/\/redis.io\/docs\/latest\/commands\/info\/","title":"INFORMACI\u00d3N | Documentos"},"S3":{"id":"S3","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai","title":"Replicaci\u00f3n de Redis | Documentaci\u00f3n"},"S4":{"id":"S4","url":"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf","title":"redis\/redis.conf en 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":"Replicaci\u00f3n de bases de datos | Documentaci\u00f3n"},"S6":{"id":"S6","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/","title":"Administraci\u00f3n de Redis | Documentaci\u00f3n"}},"_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":"Entender el backlog de replicaci\u00f3n de Redis: PSYNC, tama\u00f1o y l\u00edmites de alta disponibilidad","slug":"entender-el-backlog-de-replicacion-de-redis","excerpt":"La cola de replicaci\u00f3n de Redis almacena una parte limitada del flujo de replicaci\u00f3n. A menudo permite realizar un PSYNC en lugar de una resincronizaci\u00f3n completa tras breves interrupciones de la conexi\u00f3n, pero no sustituye ni al almacenamiento persistente de datos ni a un concepto bien dise\u00f1ado de alta disponibilidad.","seo":{"title":"Comprender el backlog de replicaci\u00f3n de Redis y planificarlo correctamente","description":"Descubre qu\u00e9 almacena el \u00abRedis Replication Backlog\u00bb, c\u00f3mo funciona PSYNC, c\u00f3mo planificar el tama\u00f1o y cu\u00e1les son los l\u00edmites que se aplican a la alta disponibilidad.","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\/es\/wp-json\/wp\/v2\/posts\/21633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21633"}],"version-history":[{"count":5,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21633\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21633\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21637"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}