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 mediante réplicas de lectura. En esta página se da por supuesto 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 consultando las réplicas. Se proporciona un endpoint de lectura para que las aplicaciones puedan distribuir las consultas entre las réplicas más fácilmente. Para obtener más información, consulta Escalar lecturas con el endpoint de lectura.

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

Casos prácticos de las 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 una alta disponibilidad. En estos casos prácticos, hay muchas más lecturas que escrituras, y generalmente se pueden tolerar algunas lecturas obsoletas. En estos casos, es recomendable usar 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 de forma predeterminada en las instancias de nivel estándar.
  • Una vez que se habilitan las réplicas de lectura en una instancia, ya no se pueden inhabilitar en esa instancia.
  • Las instancias de nivel estándar pueden tener de 1 a 5 réplicas de lectura.
  • El endpoint de lectura proporciona un único endpoint para distribuir las consultas entre 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 se admiten en instancias con nodos de 5 GB o más.
  • 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 alternativa para aprovisionar nodos, Memorystore usará esas zonas para el primer y el segundo nodo de la instancia. Después, Memorystore selecciona las zonas de todos los nodos restantes aprovisionados para la instancia.
  • Debes aprovisionar la instancia con un intervalo de direcciones IP CIDR de /28 o superior. Los tamaños de intervalo más grandes, como /27 y /26, son válidos. Esta función no admite intervalos más pequeños, como /29.

Arquitectura

Cuando habilitas las réplicas de lectura, especificas el número de réplicas que quieres que tenga la instancia. Memorystore distribuye automáticamente los nodos de réplica principal y de lectura entre las zonas disponibles de una región.

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

El servicio de monitorización del estado de Memorystore para Redis monitoriza la instancia y se encarga de detectar cualquier fallo del nodo principal, así como de elegir una réplica como nuevo principal e iniciar una conmutación por error automática al nuevo principal.

Conmutaciones por error de instancias con réplicas de lectura

Cuando falla un elemento principal, el servicio de monitorización del estado de Memorystore inicia la conmutación por error y el nuevo elemento principal está disponible para lecturas y escrituras. La conmutación por error suele completarse en menos de 30 segundos.

Cuando se produce una conmutación por error, el endpoint principal redirige automáticamente el tráfico al nuevo principal. Sin embargo, todas las conexiones de cliente al endpoint principal se desconectan durante la conmutación por error. Las aplicaciones con lógica de reintento de conexión se volverán a conectar automáticamente cuando el nuevo nodo principal esté online. Algunas de las conexiones de cliente al endpoint de lectura también se desconectan de la réplica de lectura que se convierte en principal durante la conmutación por error. Las conexiones a las réplicas restantes se siguen atendiendo durante una conmutación por error. Al reintentar, las conexiones se redirigen a las nuevas réplicas.

Cuando se produce una conmutación por error, debido a la naturaleza asíncrona de la replicación, las réplicas pueden tener una latencia 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. De esta forma, se minimiza la pérdida de datos y la reducción del rendimiento de lectura durante una conmutación por error. El nuevo primario puede estar en la misma zona o en una zona diferente que el anterior. Se selecciona una réplica para que sea la nueva principal si está en la misma zona que la anterior y tiene el menor retraso. Si no es así, una réplica de otra zona puede convertirse en la nueva principal.

Como la replicación es asíncrona, siempre existe la posibilidad de leer datos obsoletos durante una conmutación por error. Además, mientras se asciende a la nueva réplica principal, es posible que se pierdan algunas escrituras en la instancia. Las aplicaciones deben poder gestionar este comportamiento.

Redis hace todo lo posible para evitar que las demás 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, en función de la velocidad de escritura y del tamaño del conjunto de datos que se esté replicando. Durante este tiempo, las réplicas que se sometan a una sincronización completa no estarán disponibles para lecturas. Una vez que se haya completado la sincronización, se podrá acceder a las réplicas para leerlas.

Modos de fallo de las réplicas de lectura

Las instancias con réplicas de lectura pueden sufrir varios errores y estados incorrectos que afecten a la aplicación. El comportamiento varía en función de si la instancia tiene una réplica o dos o más. En esta sección se describen algunos modos de fallo habituales y el comportamiento de la instancia en estas condiciones.

Réplica no disponible

  • Si una réplica falla por cualquier motivo, se marca como no disponible y se terminan todas las conexiones a la réplica después de un tiempo de espera determinado. Una vez que se recupera la réplica, las nuevas conexiones se dirigen a la réplica restaurada. El tiempo necesario para recuperar una réplica varía en función del modo de fallo.

  • En caso de que se agoten las existencias de Compute Engine o se produzca un fallo en la zona, la réplica no se recuperará hasta que se resuelva el problema.

Fallo de zona

  • Si falla la zona en la que se encuentra el elemento principal, este se conmutará automáticamente a una réplica de otra zona. Si la instancia solo tiene una réplica, el endpoint 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 que no estén en la zona afectada estarán disponibles para las lecturas.

  • Si falla la zona en la que se encuentra una o varias de las réplicas, estas no estarán disponibles mientras dure el fallo. Si se produce un error en dos zonas y hay dos o más réplicas, la réplica con el menor retraso en las zonas restantes se convierte en la principal. Las réplicas que queden en las zonas no afectadas estarán disponibles para las lecturas.

Partición de red

Una partición de red es una situación en la que los nodos siguen funcionando, pero no pueden acceder a todos los clientes, zonas o nodos del mismo nivel. Memorystore usa un sistema basado en quórum para evitar que los nodos aislados sirvan escrituras. En caso de partición de red, cualquier réplica principal de una partición minoritaria se degrada automáticamente. La partición mayoritaria (si existe) elige un nuevo elemento principal si aún no tiene uno. Las réplicas aisladas siguen sirviendo lecturas. Sin embargo, pueden quedar obsoletos si no se pueden sincronizar con el principal.

Para determinar si el enlace está roto, monitoriza 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 provoca una falta de stock. Si no hay stock en una región en la que intentas aprovisionar una instancia, la operación para crear la instancia 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 la réplica. Esta operación puede tardar entre unos minutos y una hora en el peor de los casos. Una sincronización completa no provoca un fallo de la instancia, pero durante este tiempo la réplica que se está sincronizando no está disponible para lecturas y la instancia principal experimenta un mayor uso de CPU y memoria.

El endpoint principal devuelve READONLY

Es posible que tus escrituras en el endpoint 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 a la instancia. En la mayoría de los casos, reiniciar la aplicación cliente puede mitigar el problema. Si estas opciones no son viables o el problema persiste, ponte en contacto con el Google Cloud equipo de Asistencia.

Escalar lecturas con el endpoint de lectura

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

Leer endpoint

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

Comportamiento del endpoint de lectura

  • El endpoint de lectura distribuye automáticamente las conexiones entre todas las réplicas disponibles. Las conexiones no se dirigen a la principal.
  • Se considera que una réplica está disponible mientras pueda atender el tráfico de clientes. Esto no incluye los momentos en los que una réplica está sincronizando por completo con su principal.
  • Una réplica con una latencia de replicación alta sigue sirviendo tráfico. Las aplicaciones con un volumen de escritura alto pueden leer datos obsoletos de una réplica que sirva escrituras altas.
  • Si un nodo de réplica se convierte en el principal, las conexiones a ese nodo se terminan y las nuevas conexiones se redirigen a un nuevo nodo de réplica.
  • Las conexiones individuales al endpoint de lectura se dirigen a la misma réplica durante toda la conexión. No se garantiza que las distintas conexiones del mismo host de cliente se dirijan al mismo nodo de réplica.

Coherencia de lectura

Las réplicas de lectura se mantienen mediante la replicación asíncrona nativa de Redis OSS. Debido a la naturaleza de la réplica asíncrona, es posible que la réplica se retrase con respecto a la 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 de lectura y escritura, te recomendamos que uses el endpoint principal tanto para las escrituras como para las lecturas. Si usas el endpoint principal, te aseguras de que las lecturas siempre se dirijan al principal. Incluso en este caso, es posible que se produzcan lecturas obsoletas después de una conmutación por error.

Si se definen TTLs en las claves de la principal, se asegura de que las claves caducadas no se lean ni de la principal ni de la réplica. Esto se debe a que Redis se asegura de que no se pueda leer una clave caducada de la réplica.

Comportamiento al habilitar réplicas de lectura en una instancia

  • Habilitar réplicas de lectura en una instancia de Redis ya creada es una operación exclusiva, lo que significa que no puedes realizar otras modificaciones de la instancia con la 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, debes asignar un intervalo de direcciones IP secundarias válido para la colocación de nodos. Debe ser un intervalo de enrutamiento entre dominios sin clases (CIDR) de tamaño /28, independientemente del tamaño del intervalo de direcciones IP asignado a Memorystore para Redis.

    • Debes proporcionar el intervalo de IP adicional al habilitar las réplicas de lectura de la instancia de Redis. Puedes elegir un intervalo específico o dejar que Memorystore seleccione uno automáticamente.

  • La dirección IP de lectura/escritura de tu instancia no cambia al habilitar las réplicas de lectura. La dirección IP del endpoint de lectura se encuentra en el intervalo original asignado a tu instancia de Memorystore, no en el intervalo adicional que proporcionas al habilitar las réplicas de lectura.

  • Para encontrar el nuevo endpoint 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 el número de réplicas de lectura de tu instancia y también modificar el tamaño del nodo:

Te recomendamos que escales tu instancia durante un periodo de poco tráfico de lectura y escritura para minimizar el impacto en la aplicación.

Si se añade una réplica, se genera una carga adicional en el elemento principal mientras la réplica realiza una sincronización completa. Cuando se añaden nodos, las conexiones no se ven afectadas ni se transfieren. Una vez que la nueva réplica esté disponible, empezará a recibir conexiones del endpoint y a servir lecturas. Si quitas una réplica, se cerrarán las conexiones activas dirigidas a esa réplica. La aplicación cliente debe configurarse para que se vuelva a conectar automáticamente al endpoint de lectura y restablecer las conexiones a las réplicas restantes.

Prácticas recomendadas

Gestión de la memoria

Redis no permite que las escrituras de los clientes 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 memoria por encima de este límite. En estos casos, Memorystore no puede escribir hasta que se reduzca la presión de la memoria. Consulta más información en el artículo Prácticas recomendadas para gestionar la memoria.

Si Memorystore está llevando a cabo una operación BGSAVE debido a una exportación o a una replicación de sincronización completa y se produce una condición de falta de memoria, se cierra el proceso secundario. En este caso, la operación BGSAVE falla y el servidor de nodos de Redis sigue disponible.

Para garantizar la replicación y la creación de copias de seguridad en todas las circunstancias, le recomendamos que mantenga la utilización de la memoria por debajo del 50% durante las operaciones importantes, como la exportación o el escalado. Puede activar manualmente la exportación o la conmutación por error para ver el impacto de estas operaciones en el rendimiento.

Gestión de la CPU

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

Es posible que algunos nodos experimenten un uso elevado si los patrones de uso de los clientes están desequilibrados o si las operaciones de conmutación por error provocan una distribución desequilibrada de las conexiones. En este caso, te recomendamos que cierres periódicamente tus conexiones para permitir que Memorystore vuelva a equilibrar las conexiones automáticamente. Memorystore no vuelve a equilibrar las conexiones abiertas.

Gestión del saldo de conexión

Cada vez que se cierran las conexiones de un nodo, los clientes tienen que volver a conectarse. Normalmente, esto se hace habilitando la reconexión automática en la biblioteca de cliente que elijas. Cuando se vuelve a introducir el nodo, las conexiones existentes no se redirigen, pero las nuevas sí. Los clientes pueden cerrar las conexiones periódicamente para asegurarse de que están equilibradas entre los nodos disponibles.

Gestión del retraso de replicación

Es posible que las réplicas se retrasen, sobre todo cuando la tasa de escritura es muy alta. En estos casos, la réplica sigue estando disponible para lecturas. En esta situación, las lecturas de la réplica pueden estar obsoletas y la aplicación debe poder gestionarlo o se debe abordar la alta tasa de escritura.

Siguientes pasos