Réplicas de lectura

El nivel Estándar de Memorystore para Redis proporciona la capacidad de escalar las consultas de lectura de tu aplicación mediante réplicas de lectura. En esta página, se supone que estás familiarizado con las diferentes funciones de nivel 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 puedan distribuir consultas entre las réplicas con más facilidad. Para obtener más información, consulta Escala lecturas con 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 para réplicas de lectura

El almacén de sesiones, la tabla de clasificación, el motor de recomendaciones y otros casos prácticos requieren que la instancia tenga alta disponibilidad. Para estos casos prácticos, hay muchas más lecturas que escrituras, y por lo general pueden tolerar algunas lecturas 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 la réplica 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, estas ya no se pueden inhabilitar.
  • 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 consultas en los nodos de réplica.
  • Las réplicas de lectura se mantienen mediante 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 el aprovisionamiento de nodos, Memorystore usa esas zonas para el primer y segundo nodo de la instancia. Luego, 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. No se admiten rangos más pequeños, como /29, para esta función.

Arquitectura

Cuando habilitas las réplicas de lectura, debes especificar la cantidad de réplicas que deseas en la instancia. Memorystore distribuye de forma automática los nodos de réplica principales y de lectura en 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 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 y elige una réplica como la principal nueva. 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 principal, el servicio de supervisión de estado de Memorystore inicia la conmutación por error y la nueva instancia principal está disponible para lecturas y escrituras. Por lo general, la conmutación por error se completa en menos de 30 segundos.

Sin embargo, cuando ocurre una conmutación por error, el extremo principal redirecciona de forma automática el tráfico al nuevo principal, pero todas las conexiones del 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 de forma automática cuando la nueva instancia principal esté en línea. Algunas de las conexiones de cliente al extremo de lectura también se desconectan de la réplica de lectura que se asciende a principal durante la conmutación por error. Las conexiones a las réplicas restantes se entregan 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 su mejor esfuerzo para conmutar por error a la réplica con el menor retraso. 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 ascendida puede estar en la misma zona o en una zona diferente a la principal anterior. Se selecciona una réplica para que sea la principal nueva si se encuentra en la misma zona que la 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 el nuevo principal, es posible que se pierdan algunas escrituras en la instancia. Las aplicaciones deben poder manejar este comportamiento.

Redis hace su mejor esfuerzo para evitar que las otras réplicas requieran una sincronización completa durante la conmutación por error, pero puede suceder 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 las lecturas. Una vez que se completa la sincronización, se puede acceder a las réplicas para las lecturas.

Modos de falla para las réplicas de lectura

Las instancias con réplicas de lectura pueden ejecutarse en varias fallas y en mal estado que afectan a la aplicación. El comportamiento varía según si la instancia tiene una réplica o dos o más réplicas. En la sección, se describen algunos modos de falla comunes y se describe 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 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 acabe el stock de Compute Engine o falla 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 realiza la conmutación 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 lecturas

  • Si la zona en la que se encuentran una o más réplicas falla, esas réplicas no estarán disponibles mientras 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 asciende a la principal. Las réplicas restantes en las zonas no afectadas están disponibles para 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 escrituras. En el caso de una partición de red, cualquier instancia principal de una partición minoritaria se desciende de forma automática. La partición mayoritaria (si existe) elige una instancia principal nueva si aún no tiene una. Las réplicas aisladas continúan entregando lecturas. Sin embargo, pueden quedar obsoletos si no pueden sincronizarse desde la instancia principal.

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

Agotamiento

En ocasiones, los recursos de Compute Engine necesarios para Memorystore no están disponibles en una zona, lo que genera un agotamiento de stock. Si hay una reserva 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 en relación con 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 en 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 principal experimenta un uso de CPU y memoria más alto.

El extremo principal muestra READONLY

Es posible que las escrituras 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. 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 factibles o el comportamiento persiste, comunícate con el equipo de Asistencia de Google Cloud.

Escala lecturas con el extremo de lectura

Las réplicas de lectura permiten a las aplicaciones escalar sus lecturas leyendo desde 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. Además, 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 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 Visualiza la información de réplica de lectura de tu instancia.

Comportamiento del extremo de lectura

  • El extremo de lectura distribuye las conexiones de forma automática entre todas las réplicas disponibles. Las conexiones no se dirigen a la instancia principal.
  • Una réplica se considera disponible siempre que pueda entregar tráfico de clientes. Esto no incluye los momentos en los que una réplica está en sincronización completa con su instancia principal.
  • Una réplica con un gran retraso de replicación sigue entregando tráfico. Las aplicaciones con un alto volumen de escritura pueden leer datos inactivos de una réplica que entrega escrituras 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 el ciclo de vida de la conexión. No se garantiza que las conexiones diferentes del mismo host del cliente se orienten al mismo nodo de réplica.

Coherencia en la lectura

Las réplicas de lectura se mantienen mediante la replicación asíncrona nativa de OSS de Redis. 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 de la réplica deben poder tolerar lecturas incoherentes.

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

Configurar TTL en las claves de la primaria garantiza que las claves vencidas no se lean desde la instancia 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 la habilitación de réplicas de lectura en una instancia existente

  • Habilitar las 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 la instancia 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 de /28, independientemente del tamaño del rango de direcciones IP existente que se asigna 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 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.

Escalar una instancia

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

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.

Agregar una réplica nueva genera una carga adicional en la instancia principal mientras la réplica realiza una sincronización completa. Cuando agregas nodos, las conexiones existentes no se ven afectadas ni se transfieren. Una vez que la réplica nueva está disponible, comienza a recibir conexiones desde el extremo y entrega lecturas. Cuando quitas una réplica, se cierran todas las conexiones activas enrutadas a esa réplica. La aplicación cliente se debe configurar para volver a conectarse de forma automática al extremo de lectura a fin de restablecer las conexiones a las réplicas restantes.

Prácticas recomendadas

Administración de la memoria

Redis no permite que las operaciones de escritura de cliente excedan 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 después de este límite. En estos casos, Memorystore falla la escritura hasta que se reduce la presión de la memoria. Consulta las prácticas recomendadas de administración de memoria para obtener más detalles.

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

Para garantizar la replicación y la creación de instantáneas en todas las circunstancias, recomendamos mantener un uso de memoria inferior al 50% durante operaciones importantes como la exportación, el escalamiento, etc. Puedes activar la exportación o 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 para cada nodo. Te recomendamos asignar una sobrecarga suficiente para que se pueda tolerar la pérdida de una sola zona de disponibilidad. Esto significa que debes mantener el uso de CPU de las réplicas en un 50% o menos. De esta manera, si una de las tres zonas no está disponible, las réplicas restantes se ejecutarán en el 75%.

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 dan como resultado 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 balancearlas de forma automática. Memorystore no vuelve a balancear las conexiones abiertas.

Administración del saldo de conexión

Cada vez que las conexiones de un nodo se cierran, 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 enrutan, pero las conexiones nuevas se enrutan al nodo nuevo. Los clientes pueden finalizar las conexiones de forma periódica para asegurarse de que estén balanceadas en los nodos disponibles.

Administración de retraso de replicación

Es posible que las réplicas se retrasen, en especial cuando la tasa de escritura es muy alta. En estos casos, la réplica sigue disponible para lecturas. En esta circunstancia, las lecturas de la réplica pueden estar inactivas, y la aplicación debería poder manejar esto, o la tasa de escritura alta debería abordarse.

¿Qué sigue?