Acerca de las réplicas de lectura

El nivel Estándar de Memorystore para Redis permite escalar las consultas de lectura de tu aplicación con réplicas de lectura. En esta página, se supone que estás familiarizado con las capacidades de nivel de Redis de Memorystore.

Las réplicas de lectura te permiten escalar la carga de trabajo de lectura mediante consultas a las réplicas. Se proporciona un extremo de lectura para facilitar a las aplicaciones la distribución de consultas entre réplicas. Para obtener más información, consulta Cómo escalar lecturas con un extremo de lectura.

Para obtener instrucciones sobre cómo administrar una instancia de Redis con réplicas de lectura, consulta Administra réplicas de lectura.

Casos de uso de las réplicas de lectura

El almacén de sesiones, la tabla de clasificación, el motor de recomendaciones y otros casos de uso requieren que la instancia tenga alta disponibilidad. En estos casos de uso, hay muchas más lecturas que escrituras y, por lo general, son capaces de tolerar algunas lecturas inactivas. En casos como estos, tiene sentido aprovechar las réplicas de lectura para aumentar la disponibilidad y escalabilidad de la instancia.

Comportamiento de la réplica de lectura

  • Las réplicas de lectura no están habilitadas de forma predeterminada en las instancias de nivel Estándar.
  • Una vez que las réplicas de lectura se habilitan en una instancia, las réplicas de lectura ya no se pueden inhabilitar para esa instancia.
  • Las instancias de nivel Estándar pueden tener de 1 a 5 réplicas de lectura.
  • El extremo de lectura proporciona un único extremo para distribuir las consultas entre los nodos de réplica.
  • Las réplicas de lectura se mantienen con la replicación asíncrona de Redis.

Advertencias y limitaciones

  • Las réplicas de lectura solo son compatibles con tamaños de instancia con nodos >= 5 GB.
  • Las réplicas de lectura solo se pueden habilitar en instancias que usan Redis 5.0 o una versión posterior.
  • Si designas una zona y una zona alternativa para aprovisionar nodos, Memorystore usa esas zonas para el primer y el segundo nodo de la instancia. Después de eso, Memorystore selecciona las zonas de todos los nodos restantes aprovisionados para la instancia.
  • Debes aprovisionar la instancia con un rango de direcciones IP CIDR de /28 o superior. Los tamaños de rangos más grandes, como /27 y /26, son válidos. Los rangos más pequeños, como /29, no son compatibles con esta función.

Arquitectura

Cuando habilitas réplicas de lectura, debes especificar la cantidad de réplicas que deseas en la instancia. Memorystore distribuye de forma automática los nodos principal y de réplica de lectura entre las zonas disponibles de una región.

Cada instancia tiene un extremo principal y uno de lectura. El extremo principal siempre dirige el tráfico al nodo principal, mientras que el extremo de lectura balancea de forma automática las cargas de las consultas de lectura en las réplicas disponibles.

El servicio de supervisión de estado de Memorystore para Redis supervisa la instancia y es responsable de detectar cualquier falla del nodo principal. Además, elige una réplica como la instancia principal nueva y, luego, inicia una conmutación por error automática a la instancia principal nueva.

Conmutaciones por error para instancias con réplicas de lectura

Cuando falla una instancia principal, el servicio de supervisión de estado de Memorystore inicia la conmutación por error y la instancia principal nueva está disponible para operaciones de lectura y escritura. Por lo general, la conmutación por error se completa en menos de 30 segundos.

Cuando se produce una conmutación por error, el extremo principal redirecciona automáticamente el tráfico a la instancia principal nueva. Sin embargo, todas las conexiones de clientes al extremo principal se desconectan durante una conmutación por error. Las aplicaciones con lógica de reintento de conexión se reconectarán automáticamente una vez que la nueva instancia principal esté en línea. Algunas de las conexiones del cliente al extremo de lectura también se desconectan de la réplica de lectura que asciende a principal durante la conmutación por error. Las conexiones a las réplicas restantes se seguirán entregando durante una conmutación por error. En el reintento, las conexiones se redireccionan a las réplicas nuevas.

Cuando se produce una conmutación por error, debido a la naturaleza asíncrona de la replicación, las réplicas pueden tener un retraso de replicación diferente. Sin embargo, el proceso de conmutación por error hace todo lo posible para conmutar por error a la réplica con el menor retraso posible. Esto ayuda a minimizar la pérdida de datos y la reducción de la capacidad de procesamiento de lectura durante una conmutación por error. La instancia principal recién ascendida puede estar en la misma zona o en una diferente que la principal anterior. Se selecciona una réplica para que sea la instancia principal nueva si se encuentra en la misma zona que la instancia principal anterior y tiene el menor retraso. De lo contrario, una réplica de una zona diferente puede convertirse en la nueva instancia principal.

Dado que la replicación es asíncrona, siempre existe la posibilidad de leer datos inactivos durante una conmutación por error. Además, mientras se promueve la instancia principal nueva, se pueden perder algunas escrituras en la instancia. Las aplicaciones deberían poder lidiar con este comportamiento.

Redis hace todo lo posible para evitar las otras réplicas que requieren una sincronización completa durante la conmutación por error, pero puede ocurrir en situaciones poco frecuentes. Una sincronización completa puede tardar entre unos minutos y una hora según la tasa de escritura y el tamaño del conjunto de datos que se replica. Durante este tiempo, las réplicas que se someten a una sincronización completa no están disponibles para lecturas. Una vez que se completa la sincronización, se puede acceder a las réplicas para las operaciones de lectura.

Modos de falla para las réplicas de lectura

Las instancias con réplicas de lectura pueden generar varias fallas y condiciones de mal estado que afecten a la aplicación. El comportamiento varía según si la instancia tiene una réplica, o dos o más. En la sección, se describen algunos modos de falla comunes y el comportamiento de la instancia durante estas condiciones.

La réplica no está disponible

  • Cuando una réplica falla por cualquier motivo, se marca como no disponible y todas sus conexiones se finalizan después de un tiempo de espera determinado. Una vez que se recupera la réplica, las conexiones nuevas se enrutan a la réplica restablecida. El tiempo para recuperar una réplica varía según el modo de falla.

  • En caso de que se agote el stock de Compute Engine o falle la zona, la réplica no se recupera hasta que se resuelve la condición.

Falla de zona

  • Si la zona en la que se encuentra la instancia principal falla, la principal conmuta por error automáticamente a una réplica que se encuentre en otra zona. Si la instancia solo tiene una réplica, el extremo de lectura no estará disponible mientras dure la interrupción de la zona. Si la instancia tiene más de una réplica, las réplicas fuera de la zona afectada están disponibles para operaciones de lectura.

  • Si la zona en la que se encuentran una o más de las réplicas falla, esas réplicas no estarán disponibles mientras dure la falla de la zona. Si hay una falla en dos zonas y hay dos o más réplicas, la réplica con el menor retraso en las zonas restantes se asciende a la principal. Cualquier réplica restante en las zonas no afectadas está disponible para operaciones de lectura.

Partición de red

Una partición de red es una situación en la que los nodos permanecen en ejecución, pero no pueden llegar a todos los clientes, zonas o nodos de intercambio de tráfico. Memorystore usa un sistema basado en quórum para evitar que los nodos aislados entreguen operaciones de escritura. En el caso de una partición de red, cualquier principal en una partición minoritaria desciende de nivel por cuenta propia. La partición mayor (si existe) elige una instancia principal nueva si todavía no tiene una. Las réplicas aisladas continúan entregando operaciones de lectura. Sin embargo, pueden quedar inactivas si no pueden sincronizarse desde la instancia principal.

Para determinar si el vínculo está roto, supervisa las métricas master_link_down_since_seconds y offset_diff para identificar nodos aislados.

Agotado

En ocasiones, los recursos de Compute Engine que necesita Memorystore no están disponibles en una zona, lo que genera un agotamiento. Si hay agotado en una región en la que intentas aprovisionar una instancia, la operación para crearla falla.

Sincronización completa

Cuando una réplica se retrasa demasiado con respecto a la instancia principal, se activa una sincronización completa que copia una instantánea completa de la instancia principal a una réplica. En el peor de los casos, esta operación puede tardar desde minutos hasta una hora. Una sincronización completa no causa una falla de la instancia. Sin embargo, durante este tiempo, la réplica que se somete a la sincronización completa no está disponible para lecturas y la instancia principal experimenta un mayor uso de CPU y memoria.

El extremo principal devuelve READONLY

Las operaciones de escritura en el extremo principal de una instancia de Memorystore para Redis con réplicas de lectura pueden recibir errores -READONLY You can't write against a read only replica. de forma inesperada. Recomendamos cerrar y volver a crear las conexiones a la instancia. En la mayoría de los casos, reiniciar la aplicación cliente puede mitigar el problema. Si estas opciones no son posibles o el comportamiento persiste, comunícate con el equipo de Asistencia de Google Cloud.

Escala las lecturas con el extremo de lectura

Las réplicas de lectura permiten que las aplicaciones escalen sus lecturas mediante la lectura de las réplicas. Las aplicaciones pueden conectarse a réplicas de lectura a través del extremo de lectura.

Leer extremo

El extremo de lectura es una dirección IP a la que se conecta tu aplicación. De forma uniforme, balancea las cargas de las conexiones entre las réplicas de la instancia. Las conexiones a la réplica de lectura pueden enviar consultas de lectura, pero no de escritura. Cada instancia de nivel Estándar que tiene réplicas de lectura habilitadas tiene un extremo de lectura. Si quieres obtener instrucciones para ver el extremo de lectura de tu instancia, consulta Visualiza la información de la réplica de lectura de tu instancia.

Comportamiento del extremo de lectura

  • El extremo de lectura distribuye las conexiones entre todas las réplicas disponibles de forma automática. Las conexiones no se dirigen a la instancia principal.
  • Se considera que una réplica está disponible siempre y cuando pueda entregar el tráfico de clientes. Esto no incluye los momentos en los que una réplica se encuentra en una sincronización completa con la instancia principal.
  • Una réplica con un retraso de replicación alto continúa entregando tráfico. Las aplicaciones con un volumen alto de escritura pueden leer datos inactivos de una réplica que entrega operaciones de escritura altas.
  • En el caso de que un nodo de réplica se convierta en el principal, las conexiones a ese nodo se finalizan y las conexiones nuevas se redireccionan a un nodo de réplica nuevo.
  • Las conexiones individuales al extremo de lectura se orientan a la misma réplica durante todo el ciclo de vida de la conexión. No se garantiza que las diferentes conexiones del mismo host cliente se orienten al mismo nodo de réplica.

Coherencia de lectura

Las réplicas de lectura se mantienen con la replicación asíncrona nativa de Redis de OSS. Debido a la naturaleza de la replicación asíncrona, es posible que la réplica se retrase con respecto a la instancia principal. Las aplicaciones con escrituras constantes que también leen desde la réplica deberían poder tolerar lecturas incoherentes.

Si la aplicación requiere coherencia de “lectura de escritura”, recomendamos usar el extremo principal para escrituras y lecturas. Usar el extremo principal garantiza que las lecturas siempre se dirijan a esta. Incluso en este caso, es posible tener lecturas inactivas después de una conmutación por error.

Configurar los TTL en las claves de la instancia principal garantiza que las claves vencidas no se lean desde la principal ni desde la réplica. Esto se debe a que Redis garantiza que una clave vencida no se pueda leer desde la réplica.

Comportamiento de habilitar réplicas de lectura en una instancia existente

  • Habilitar réplicas de lectura en una instancia existente de Redis es una operación exclusiva, lo que significa que no puedes realizar otras modificaciones de instancias de operación de actualización como parte de la misma operación que habilita las réplicas de lectura.

  • Para habilitar réplicas de lectura en una instancia de Redis existente, debes asignar un rango de direcciones IP válido adicional con un tamaño de /28, sin importar el tamaño del rango de direcciones IP existente asignado a Memorystore para Redis.

    • Debes proporcionar el rango de IP adicional cuando habilites réplicas de lectura para la instancia de Redis. Puedes elegir un rango específico o permitir que Memorystore seleccione uno automáticamente.

  • La dirección IP de lectura y escritura de tu instancia no cambia cuando habilitas las réplicas de lectura. La dirección IP del extremo de lectura se encuentra en el rango original asignado para tu instancia de Memorystore, no en el rango adicional que proporcionas cuando habilitas réplicas de lectura.

  • Para encontrar el extremo de lectura nuevo, consulta la información de las réplicas de lectura de tu instancia después de que se complete la operación para habilitar las réplicas de lectura.

Escalar una instancia

Puedes escalar la cantidad de réplicas de lectura de tu instancia y también puedes modificar el tamaño del nodo:

Te recomendamos que escales la instancia durante un período de bajo tráfico de lectura y escritura para minimizar el impacto en la aplicación.

Agregar una réplica nueva genera una carga adicional en la instancia principal mientras la réplica realiza una sincronización completa. Cuando se agregan nodos, las conexiones existentes no se ven afectadas ni se transfieren. Una vez que la réplica nueva está disponible, comienza a recibir conexiones del extremo y entrega operaciones de lectura. Cuando quitas una réplica, se cierran todas las conexiones activas enrutadas a ella. La aplicación cliente debe configurarse para volver a conectarse automáticamente al extremo de lectura y restablecer las conexiones con las réplicas restantes.

prácticas recomendadas

Administración de la memoria

Redis no permite que las operaciones de escritura del cliente superen el límite maxmemory de la instancia. Sin embargo, la sobrecarga, como la fragmentación, los búferes de replicación y los comandos costosos, como EVAL, pueden aumentar el uso de memoria más allá de este límite. En estos casos, Memorystore falla las operaciones de escritura hasta que se reduce la presión de la memoria. Si quieres obtener más detalles, consulta Prácticas recomendadas para la administración de memoria.

Si Memorystore se encuentra en una operación BGSAVE debido a una exportación o una replicación de sincronización completa, y se produce una condición OOM, el proceso secundario finaliza. En este caso, la operación BGSAVE falla y el servidor de nodos de Redis permanece disponible.

Para garantizar la replicación y la creación de instantáneas en todas las circunstancias, te recomendamos que mantengas el uso de memoria inferior al 50% durante operaciones importantes, como la exportación, el escalamiento, etc. Puedes activar la exportación o la conmutación por error de forma manual para ver el impacto en el rendimiento de estas operaciones.

Administración de CPU

Memorystore proporciona métricas sobre el uso de CPU y el recuento de conexiones de cada nodo. Te recomendamos que asignes suficiente sobrecarga para que se pueda tolerar la pérdida de una sola zona de disponibilidad. El objetivo ideal puede variar en función de la cantidad de réplicas y patrones de uso, pero un buen punto de partida es mantener el uso de CPU de la réplica por debajo del 50%.

Los nodos individuales pueden experimentar un uso elevado si los patrones de uso del cliente no están equilibrados o si las operaciones de conmutación por error generan una distribución de conexión desequilibrada. En este caso, te recomendamos que cierres las conexiones de forma periódica para permitir que Memorystore vuelva a balancear las conexiones de forma automática. Memorystore no vuelve a balancear las conexiones abiertas.

Administración del saldo de conexiones

Cada vez que las conexiones de un nodo se cierran, los clientes deben volver a conectarse. Por lo general, se habilita la reconexión automática en la biblioteca cliente que elijas. Cuando se vuelve a introducir el nodo, las conexiones existentes no se redirigen, pero las nuevas se enrutan al nodo nuevo. Los clientes pueden finalizar las conexiones de forma periódica para garantizar que se equilibran en los nodos disponibles.

Administración del retraso de la replicación

Es posible que las réplicas se retrasen, en especial cuando la tasa de escritura es muy alta. En estas situaciones, la réplica sigue estando disponible para lecturas. En esta circunstancia, las lecturas de la réplica pueden quedar inactivas y la aplicación debería poder controlar esto, o se debe abordar la tasa de escritura alta.

¿Qué sigue?