Información acerca de las réplicas de lectura

El nivel Estándar de Memorystore para Redis te permite escalar las consultas de lectura de tu aplicación con réplicas de lectura. En esta página, se supone que conoces las diferentes funciones de los niveles de Redis de Memorystore.

Las réplicas de lectura te permiten escalar tu carga de trabajo de lectura mediante consultas a las réplicas. Se proporciona un extremo de lectura para que las aplicaciones distribuyan las consultas entre las réplicas de forma más sencilla. Para obtener más información, consulta Escalamiento de operaciones de lectura con el 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

La tienda 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 operaciones de lectura que de escritura, y estos casos de uso suelen tolerar algunas operaciones de lectura inactivas. En casos como estos, tiene sentido aprovechar las réplicas de lectura para aumentar la disponibilidad y la escalabilidad de la instancia.

Comportamiento de las réplicas de lectura

  • Las réplicas de lectura no están habilitadas en las instancias de nivel Estándar de forma predeterminada.
  • Una vez que se habilitan las réplicas de lectura en una instancia, 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 solo extremo para distribuir 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 instancias con nodos superiores o iguales a 5 GB.
  • Las réplicas de lectura solo se pueden habilitar en instancias que usen la versión 5.0 de Redis o una posterior.
  • Si designas una zona y una zona alterna para los nodos de aprovisionamiento, Memorystore usa esas zonas para el primer y segundo nodos 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 rango 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 las réplicas de lectura, especificas la cantidad de réplicas que deseas en la instancia. Memorystore distribuye automáticamente los nodos principales y de réplica de lectura en las zonas disponibles de una región.

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

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

Conmutaciones por error para instancias con réplicas de lectura

Cuando falla un elemento principal, el servicio de supervisión del estado de Memorystore inicia la conmutación por error, y el nuevo elemento principal se pone a disposición para las 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 al nuevo extremo principal. Sin embargo, todas las conexiones de cliente al extremo principal se desconectan durante una conmutación por error. Las aplicaciones con lógica de reintento de conexión se volverán a conectar 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 se promueve a principal durante la conmutación por error. Las conexiones a las réplicas restantes siguen publicándose durante una conmutación por error. Cuando se vuelve a intentar, 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 realizar la conmutación por error a la réplica con la menor demora. Esto ayuda a minimizar la cantidad de 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 promocionada puede estar en la misma zona o en una zona diferente a la anterior. Se selecciona una réplica para que sea la nueva principal si está en la misma zona que la principal anterior y tiene la menor demora. De lo contrario, una réplica de una zona diferente puede convertirse en la nueva principal.

Dado que la replicación es asíncrona, siempre existe la posibilidad de leer datos obsoletos durante una conmutación por error. Además, mientras se promueve la instancia principal nueva, es posible que se pierdan algunas operaciones de escritura en la instancia. Las aplicaciones deberían poder controlar este comportamiento.

Redis hace todo lo posible para evitar que las otras réplicas requieran una sincronización completa durante la conmutación por error, pero puede ocurrir en casos excepcionales. 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 están sincronizando por completo no están disponibles para las operaciones de lectura. Una vez que se complete 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 encontrar varias fallas y condiciones no óptimas que afectan a la aplicación. El comportamiento varía según si la instancia tiene una réplica, 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 algún motivo, se marca como no disponible y todas las conexiones a la réplica se cancelan 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 de recuperación de una réplica varía según el modo de falla.

  • En caso de falta de existencias o falla de zona de Compute Engine, la réplica no se recupera hasta que se resuelve la condición.

Falla de zona

  • Si falla la zona en la que se encuentra la instancia principal, esta se conmuta por error automáticamente a una réplica 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 las operaciones de lectura.

  • Si falla la zona en la que se encuentra una o más de las réplicas, estas no estarán disponibles durante el tiempo que dure la falla de la zona. Si hay una falla de dos zonas y hay dos o más réplicas, la réplica con el menor retraso en las zonas restantes se promueve a la principal. Las réplicas restantes en las zonas no afectadas están disponibles para las 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 conectarse a todos los clientes, zonas o nodos de pares. 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 elemento principal en una partición minoritaria se degrada automáticamente. La partición de mayoría (si existe una) elige un nuevo elemento principal si aún no tiene uno. Las réplicas aisladas siguen publicando operaciones de lectura. Sin embargo, es posible que se vuelvan inactivos si no se pueden sincronizar desde el elemento principal.

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

Agotamiento de existencias

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

Sincronización completa

Cuando una réplica se retrasa demasiado con respecto a la principal, se activa una sincronización completa que copia una instantánea completa de la principal a una réplica. Esta operación puede tardar desde minutos hasta una hora en el peor de los casos. 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 las operaciones de lectura, y la instancia principal experimenta un mayor uso de CPU y memoria.

El extremo principal muestra READONLY

Es posible que tus operaciones de escritura en el extremo principal de una instancia de Memorystore para Redis con réplicas de lectura reciban errores -READONLY You can't write against a read only replica. de forma inesperada. Te recomendamos que cierres y vuelvas a crear las conexiones con la instancia. En la mayoría de los casos, reiniciar la aplicación cliente puede mitigar el problema. Si estas opciones no son factibles o el comportamiento persiste, comunícate con el Google Cloud equipo de asistencia al cliente.

Cómo escalar las operaciones de lectura con el extremo de lectura

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

Extremo de lectura

El extremo de lectura es una dirección IP a la que se conecta tu aplicación. Equilibra las cargas de las conexiones de manera uniforme 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 habilitadas las réplicas de lectura tiene un extremo de lectura. Para obtener instrucciones sobre cómo ver el extremo de lectura de tu instancia, consulta Cómo ver la información de la réplica de lectura de tu instancia.

Comportamiento del extremo de lectura

  • El extremo de lectura distribuye automáticamente las conexiones entre todas las réplicas disponibles. Las conexiones no se dirigen a la principal.
  • Una réplica se considera disponible siempre que pueda entregar tráfico de cliente. Esto no incluye los momentos en que una réplica está realizando una sincronización completa con su instancia principal.
  • Una réplica con un retraso de replicación alto sigue entregando tráfico. Las aplicaciones con un gran volumen de operaciones de escritura pueden leer datos inactivos de una réplica que entrega operaciones de escritura altas.
  • En caso de que un nodo de réplica se convierta en el principal, las conexiones a ese nodo se terminan y las nuevas conexiones se redireccionan a un nuevo nodo de réplica.
  • Las conexiones individuales al extremo de lectura se orientan a la misma réplica durante el tiempo de vida de la conexión. No se garantiza que 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 OSS Redis. Debido a la naturaleza de la replicación asíncrona, es posible que la réplica se retrase con respecto a la principal. Las aplicaciones con operaciones de escritura constantes que también leen de la réplica deberían poder tolerar lecturas incoherentes.

Si la aplicación requiere coherencia de "lee tu escritura", te recomendamos que uses el extremo principal para las operaciones de lectura y escritura. El uso del extremo principal garantiza que las operaciones de lectura siempre se dirijan al extremo principal. Incluso en este caso, es posible tener operaciones de lectura inactivas después de una conmutación por error.

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

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

  • Habilitar réplicas de lectura en una instancia de Redis existente 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 las réplicas de lectura en una instancia de Redis existente, debes asignar un rango de direcciones IP válido adicional de tamaño /28, independientemente del tamaño del rango de direcciones IP existente que se asignó a Memorystore para Redis.

    • Debes proporcionar el rango de IP adicional cuando habilites las 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 se habilitan 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 las réplicas de lectura.

  • Para encontrar el nuevo extremo de lectura, 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 tu instancia durante un período de tráfico de lectura y escritura bajo para minimizar el impacto en la aplicación.

Si agregas una réplica nueva, se 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 a entregar operaciones de lectura. Si quitas una réplica, se cerrarán todas las conexiones activas enrutadas a esa réplica. La aplicación cliente debe configurarse para que se vuelva a conectar automáticamente al extremo de lectura y restablezca 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 de 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 la memoria más allá de este límite. En estos casos, Memorystore falla en las operaciones de escritura hasta que se reduce la presión de memoria. Consulta Prácticas recomendadas para la administración de memoria para obtener más detalles.

Si Memorystore está realizando una operación BGSAVE debido a una exportación o una replicación de sincronización completa, y se produce una condición de OOM, se finalizará el proceso secundario. En este caso, la operación BGSAVE falla y el servidor del nodo Redis sigue disponible.

Para garantizar la replicación y la creación de instantáneas en todas las circunstancias, te recomendamos que mantengas el uso de la memoria por debajo del 50% durante operaciones importantes, como la exportación, el escalamiento, etcétera. Puedes activar manualmente la exportación o la failover para ver el impacto en el rendimiento de estas operaciones.

Administración de la CPU

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

Los nodos individuales pueden experimentar un uso alto 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 tus conexiones de forma periódica para permitir que Memorystore reequilibre las conexiones automáticamente. Memorystore no vuelve a balancear las conexiones abiertas.

Administración del balance de conexiones

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

Administración del retraso de replicación

Es posible que las réplicas se retrasen, en especial cuando la tasa de escritura es muy alta. En esos casos, la réplica sigue disponible para las operaciones de lectura. En esta circunstancia, las operaciones de lectura de la réplica pueden estar inactivas, y la aplicación debería poder controlar esto, o bien se debe abordar la alta tasa de escritura.

¿Qué sigue?