Entender el backlog de replicación de Redis: PSYNC, tamaño y límites de alta disponibilidad

El Pendiente de replicación de Redis determina, entre otras cosas, si, tras una interrupción de la conexión, una réplica solo recupera los cambios que faltan o si se le vuelve a transmitir todo el conjunto de datos. Si se dimensiona el búfer en función del volumen real de replicación, se pueden evitar sincronizaciones completas innecesarias. Para ello, sin embargo, el historial de replicación, 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ón por error robusto.

Qué almacena realmente el backlog

En Replicación de Redis El servidor principal procesa los cambios en el conjunto de datos y transmite un flujo continuo de comandos a sus réplicas. Esto no solo incluye los valores escritos directamente por los clientes. Las claves caducadas o sustituidas también pueden provocar cambios que deben transmitirse. El backlog mantiene en la memoria una muestra limitada y reciente de este flujo de replicación. 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üedad.

En condiciones normales de funcionamiento, las réplicas siguen el flujo de datos en curso. Si se interrumpe una conexión, el historial sigue creciendo en el servidor primario. Tras restablecerse la conexión, la réplica intenta reanudarse desde el punto en el que se encontraba. En ese momento, es fundamental que aún se disponga de los bytes necesarios. Si es así y el historial de replicación coincide, Redis puede completar la información que falta. Para ello, no es necesario sustituir por completo los datos ya existentes en la réplica.

Su utilidad es especialmente notable en caso de interrupciones breves de la red, cambios de conexión y trabajos de mantenimiento programados. Una sincronización completa de un gran volumen de datos requiere capacidad de transmisión y potencia de cálculo; dependiendo de la configuración, 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ón. Un reinicio del proceso o un historial modificado requieren un enfoque diferente al de una conexión TCP que se ha interrumpido brevemente.

Cuándo basta con un PSYNC y cuándo es necesaria una resincronización completa

A Resincronización parcial con PSYNC Requiere dos datos relacionados entre sí: el ID de replicación y el desplazamiento. El ID identifica un historial de datos concreto. El desplazamiento describe una posición en bytes dentro del flujo de replicación. Por lo tanto, dos desplazamientos del mismo tamaño procedentes de historiales diferentes no son automáticamente comparables. Por el contrario, un pequeño retraso en el mismo historial puede quedar ya fuera del backlog disponible si la capacidad de este es limitada.

En términos sencillos, la réplica, al volver a conectarse, informa hasta qué punto ha llegado. La primaria comprueba si puede proporcionar los datos necesarios a partir de ahí. Si se desconoce el historial o falta la sección necesaria, se produce un Resincronización completa es necesario. De este modo, la réplica recibe un conjunto completo de datos y, a continuación, los cambios producidos durante la sincronización. La transferencia puede realizarse, dependiendo de la configuración, con un paso intermedio en una base de datos relacional (RDB) o sin dicho paso intermedio.

Tras una conmutación por error, no siempre es inevitable una resincronización completa. Una réplica trasladada puede, además, recordar el ID de replicación anterior y su rango de desplazamiento válido. De este modo, otras réplicas pueden incorporarse al historial conocido si se dan las condiciones adecuadas. Sin embargo, esto no supone ninguna garantía a efectos de planificación: el rango relevante debe seguir estando disponible y la reconexión concreta debe coincidir con los ID almacenados.

Medir la tasa de replicación en lugar de estimar el tamaño de la base de datos

El mero volumen de la base de datos basta para Dimensionamiento de la cartera de pedidos No es así. Una base de datos grande, en la que predominan las operaciones de lectura, puede generar poco tráfico de replicación. Por el contrario, una caché pequeña con valores que cambian con frecuencia y muchos eventos de caducidad puede transmitir continuamente cantidades considerables de datos. Además, un número fijo de operaciones por segundo no describe de forma suficiente la memoria necesaria: los pequeños cambios en las claves y las grandes sobrescrituras de valores no ocupan el mismo número de bytes.

Se obtiene una aproximación útil a partir del incremento temporal de master_repl_offset. Registra el valor dos veces en el mismo servidor primario y divide la diferencia entre los segundos transcurridos. Comprueba también el ID de replicación. Tras un cambio de rol o un reinicio, no debes simplemente restar entre sí dos puntos de medición que no pertenezcan al mismo conjunto. Además, un único intervalo de medición solo proporciona una tasa media dentro de ese intervalo, no un límite máximo garantizado de forma permanente.

La siguiente consulta lee información de diagnóstico. No modifica ninguna configuración de Redis. Ejecútala con las opciones de conexión y autenticación necesarias en tu entorno. La llamada que se muestra a continuación utiliza la conexión predeterminada de redis-cli; es necesario configurar expresamente otro servidor, puerto o acceso TLS.

redis-cli INFO replication

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é. Documenta tanto las tasas habituales como los picos breves. Si se producen muchos cambios debido a la caducidad de claves, el artículo interno te ayudará a profundizar en el tema. Analizar la caducidad de las claves de Redis. Esta relación es importante para la planificación, ya que no todos los impulsos de escritura relevantes surgen directamente de una nueva solicitud del usuario.

Calcular de forma transparente el volumen de la cartera de pedidos pendientes

Como Aproximación de planificación Puedes multiplicar la tasa de replicación pertinente por la duración de la interrupción que hay que cubrir y, a continuación, añadir una reserva justificada. La duración no debe tener en cuenta únicamente la interrupción real de la red. La detección, los intentos de reconexión y el restablecimiento de la ruta de conexión también pueden llevar tiempo. La reserva adecuada depende de las fluctuaciones observadas y del objetivo operativo deseado, no de un porcentaje universal.

Un ejemplo de cálculo deliberadamente simplificado: para una fase de carga determinada, se calculan 12 MiB por segundo. La conexión podría estar interrumpida durante 90 segundos; además, se prevén otros 30 segundos como reserva de tiempo. De ello se deduce que 12 MiB/s × 120 s = 1.440 MiB, 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ón, deben sustituirse por los valores medidos en tu aplicación.

El cálculo inverso ayuda a valorar la capacidad de un búfer existente. Un backlog completamente lleno de 256 MiB equivale, teóricamente, a unos 21 segundos de historial si se mantiene una tasa constante de 12 MiB por segundo. A 2 MiB por segundo, serían unos 128 segundos. Sin embargo, en una aplicación real, las tasas varían. Por lo tanto, ese alcance es una instantánea y no una garantía de que cualquier interrupción de esa duración pueda sincronizarse parcialmente.

Comprueba, además, si la réplica, tras volver a conectarse, es capaz de ponerse al día más rápido 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é constantemente sobrecargado. Si el retraso persiste o sigue aumentando, hay que investigar la causa. De lo contrario, destinar cada vez más memoria solo pospone el problema y puede someter a todo el sistema a una presión de almacenamiento excesiva.

Modificar la configuración de Redis de forma clara y controlada

Los parámetros repl-backlog-size y repl-backlog-ttl controlan aspectos diferentes. El primero describe el tamaño previsto del backlog. El segundo determina, en el servidor principal, tras cuánto tiempo sin réplicas conectadas se puede liberar el backlog. Es No hay una duración máxima de interrupción para PSYNC. Mientras se siga sobrescribiendo el búfer o falte algún otro requisito, un TTL largo por sí solo no sirve de nada.

Las siguientes líneas proceden de la plantilla de configuración de Redis 7.2.0 y aparecen como valores predeterminados comentados. Los símbolos de comentario se han conservado intencionadamente. El mero hecho de copiar estas líneas no activa ninguna configuración; además, los valores mencionados no constituyen una recomendación general de capacidad para sistemas en producción.

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

Con repl-backlog-ttl 0 La liberación programada se desactiva tras desconectar todas las réplicas. Esto no conserva un historial ilimitado: los nuevos datos de replicación pueden seguir sobrescribiendo el búfer existente. Tampoco se garantiza la persistencia tras cualquier reinicio del proceso. Por lo tanto, evalúa cuidadosamente si el consumo adicional de memoria se ajusta al comportamiento de reconexión previsto.

Antes de realizar cualquier cambio, debes consultar los valores realmente vigentes y aclarar el procedimiento de implementación. Una variable de entorno del contenedor, un archivo de configuración gestionado y un ajuste modificado en tiempo de ejecución no son lo mismo. Si posteriormente se vuelve a crear una instancia, solo se pueden perder los ajustes realizados en tiempo de ejecución. Las siguientes consultas son de solo lectura; no obstante, requieren los permisos de acceso adecuados.

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

En el caso de Managed Redis, el proveedor puede restringir el acceso a CONFIG restringir o gestionar la configuración a través de una interfaz propia. Esto no es motivo para eludir los mecanismos de protección. En ese caso, utiliza los canales de gestión autorizados y documenta el tamaño seleccionado junto con el volumen de replicación subyacente. En el plan de cambios también deben consignarse los valores actuales y una estrategia de reversión realista.

Seguimiento: qué valores van juntos

Para la Supervisión de la replicación de Redis Un único indicador verde de estado de conexión no es suficiente. Una conexión puede volver a estar activa mientras la réplica sigue poniéndose al día o está cargando un conjunto completo de datos. Por el contrario, una breve interrupción de la conexión no tiene por qué ser crítica de inmediato si el historial y la capacidad de recuperación son suficientes. Por lo tanto, evalúa conjuntamente la conexión, el estado de sincronización, la evolución del desfase y el historial disponible.

Los campos de una INFOLas respuestas pueden variar entre las distintas versiones de Redis y entre el servidor principal y la réplica. Por lo tanto, un análisis debería tratar expresamente los campos que falten, en lugar de interpretarlos tácitamente como nulos o como un estado sin errores. También las denominaciones master y slave Por motivos de compatibilidad, siguen apareciendo en los nombres de los campos; no deben traducirse libremente en el código ejecutable.

Para interpretar el retraso, se debe consultar la guía interna Analizar el desplazamiento de replicación de Redis Un complemento adecuado. En el seguimiento continuo, deberías tener en cuenta las tendencias históricas, y no solo dos cifras leídas manualmente. Una distancia que va aumentando requiere una reacción diferente a la que se da cuando la brecha se va reduciendo de forma constante tras un breve parón.

Las alertas útiles se basan en tus objetivos operativos: ¿Durante cuánto tiempo puede estar inaccesible una réplica? ¿Con qué rapidez debe recuperarse? ¿Qué frecuencia de sincronizaciones completas se considera inusual? Los límites rígidos 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ás de las métricas de replicación, vigila también la utilización de la RAM, la carga de la red y los indicios de reinicios de procesos.

Cómo interpretar correctamente el presupuesto de almacenamiento y las réplicas lentas

La cartera de pedidos es solo una parte del total Requisitos de memoria de Redis. A esto hay que añadir el conjunto de datos, las estructuras administrativas, los búferes de los clientes y, dependiendo del estado operativo, memoria adicional durante las tareas de persistencia o sincronización. Por lo tanto, no destines toda la memoria de trabajo disponible a los datos de usuario más 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 él.

Desde Redis 7.0, el búfer de réplicas y la cola de replicación comparten memoria. Por ello, la documentación de INFO señala, entre otras cosas, que mem_clients_slaves puede ser nulo si los búferes de réplica no superan la asignación de backlog. Esto no significa, sin embargo, que la replicación no ocupe memoria. Ten en cuenta los valores previstos para ello, como mem_replication_backlog y mem_total_replication_buffers ten en cuenta el contexto y no sumes ciegamente magnitudes que se solapan.

Un error de diagnóstico frecuente consiste en atribuir cada sincronización interrumpida a un retraso acumulado importante. Las réplicas lentas, el ancho de banda de red limitado o el rebasamiento de los límites del búfer de salida pueden deberse a otras causas. El parámetro client-output-buffer-limit replica se refiere a la clase de cliente en cuestión y no debe confundirse con repl-backlog-size se deben considerar equivalentes. Antes de modificar los límites, comprueba los registros, la documentación de la versión y las posibles repercusiones en otras conexiones.

Por qué un gran volumen de trabajo pendiente no garantiza por sí solo una alta disponibilidad

El backlog mejora la reconexión, pero no garantiza que la replicación, que por defecto es asíncrona, se realice sin pérdidas. Un servidor primario puede haber confirmado ya una operación de escritura al cliente antes de que una réplica la haya procesado. Si el servidor primario falla durante ese intervalo, es posible que la operación en cuestión no esté presente en el sistema de sustitución seleccionado posteriormente. El tamaño del búfer por sí solo no resuelve este Riesgo de pérdida de datos durante la conmutación por error no.

También WAIT no convierte una topología de Redis en un sistema con consistencia fuerte garantizada. El comando puede esperar a recibir confirmaciones de las réplicas; la seguridad real de los datos sigue dependiendo de otras circunstancias, en particular del comportamiento de persistencia y conmutación por error. Del mismo modo, limitan min-replicas-to-write y min-replicas-max-lag aceptar nuevas operaciones de escritura según sus respectivas condiciones, sin guardar automáticamente y de forma permanente cada operación individual en varias instancias.

Para Alta disponibilidad Por lo tanto, necesitas una decisión coherente que abarque: la pérdida de datos tolerable, el tiempo de inactividad admisible, la persistencia, la detección de fallos, la selección del nuevo primario y la recuperación. Sentinel o Redis Cluster pueden asumir otras tareas distintas a las del backlog. Quien se limite a aumentar el tamaño de un búfer y deje sin modificar el resto de supuestos, no dispondrá aún de un plan de reinicio fiable.

Probar los cambios e identificar los problemas recurrentes

Inicia una prueba controlada en un entorno aislado con una versión de Redis similar y una carga de escritura predecible. Antes de la interrupción, registra los ID de replicación, los desplazamientos, el volumen de trabajo pendiente y el consumo de memoria. A continuación, simula una interrupción limitada de la conexión sin modificar firewalls o procesos de producción sin haberlos comprobado previamente. Tras restablecer la conexión, observa si se produce una sincronización parcial o completa y cuánto tiempo tarda en completarse.

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ícil determinar el efecto concreto. Repite la prueba con diferentes duraciones de interrupción y distintas fases de carga. De este modo, una sola reconexión satisfactoria se convierte en una evaluación comprensible del comportamiento. Los límites observados deben documentarse, sin deducir de ellos una garantía para cualquier fallo futuro.

En caso de resincronizaciones completas repetidas, comprueba primero si el historial es compatible. A continuación, fíjate en los bytes que aún faltan, el tiempo sin réplica, las indicaciones de reinicios y la velocidad real de recuperación. Un búfer demasiado pequeño es una posible causa, pero no la única. Es especialmente importante distinguir entre una interrupción puntual demasiado prolongada y una réplica que se queda rezagada de forma permanente, incluso con conexión activa.

La configuración 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ón, la fuente de configuración y la fecha de la comprobación. Tras cambios importantes en el comportamiento de escritura, en la topología o en la versión de Redis, hay que volver a revisar el dimensionamiento. De este modo, el backlog seguirá siendo una decisión operativa fundamentada, en lugar de una cifra fijada una vez por todas.