Uso de réplicas de Redis

Aunque otras topologías admiten el uso de réplicas, este documento se escribe teniendo en cuenta los clústeres.

Escenarios de migración tras error

Cuando el clúster de Redis detecta que un nodo maestro está inactivo, inicia la migración tras error a una de las réplicas del maestro. Las réplicas utilizan el proceso de replicación para duplicar actualizaciones del nodo maestro a medida que suceden.

En Kubernetes, cuando el pod anteriormente bloqueado se recupera y vuelve a unirse al clúster, cambiará a un rol de réplica del maestro que atiende actualmente las ranuras (que solía ser su réplica).

Si no se utilizan réplicas, Kubernetes seguirá detectando (utilizando sondas) y reiniciando los pods que no respondan. Las ranuras servidas por el maestro afectado no estarán disponibles temporalmente. Dependiendo de la duración de la interrupción, HCL Cachelos interruptores de circuito se activarán. El nodo Redis puede tardar un par de minutos en estar disponible de nuevo. Este tiempo se amplía cuando se utiliza la persistencia, ya que Redis necesita volver a cargar la memoria caché al iniciarse y el servicio no está disponible hasta que la memoria caché se haya terminado de cargar.

Escenarios de escalabilidad

Además de su rol para la migración tras error, las réplicas pueden aumentar la escalabilidad mediante el manejo GET/la lectura de operaciones. Esto libera recursos en el nodo maestro y permite un uso más eficiente de los recursos. El cliente de Redis HCL Cache se puede configurar para dirigir operaciones de lectura a réplicas utilizando la configuración readMode .

Cuando se utilizan réplicas para operaciones de lectura, debe tenerse en cuenta lo siguiente:

• El proceso de réplica introduce un retardo. Si se produce una operación de lectura inmediatamente después de una escritura, es posible que la lectura devuelva datos obsoletos o que no haya datos. Esto podría introducir problemas funcionales para determinados escenarios de memoria caché y personalizaciones. HCL Cache incluye varias configuraciones que controlan si las lecturas se dirigen a maestros o réplicas, y tiempos de espera para que se completen las réplicas.
• Si se utilizan réplicas para lecturas, los servidores maestro y de réplica deben estar disponibles para obtener un rendimiento óptimo: Una réplica no disponible puede generar tiempos de espera WAIT excedidos de mandatos durante las operaciones PUT (syncReplicas, consulte más abajo) y operaciones de lectura fallidas (GET) ejecutadas en las réplicas. Cuando se reinicia el maestro recuperado, se vuelve a configurar una réplica e inicia un nuevo proceso de sincronización. Si se requiere una sincronización completa, es posible que el servidor de réplicas no esté disponible durante algún tiempo mientras se replica la base de datos. El sistema puede tardar más tiempo en recuperarse cuando las operaciones de lectura se descargan en réplicas.

Configuraciones

Las réplicas y HCL Cache pueden requerir cambios de configuración en Redis, el cliente de Redis o HCL Cache:

Configuraciones de Redis

• cluster-replica-validity-factor: xxxxxxx
• repl-diskless-sync
• client-output-buffer-limit

Configuración de cliente Redis

HCL Cache se puede configurar para emitir operaciones de lectura (GET) a servidores de réplica con el valor readMode .

HCL Cache configuraciones

HCL Cache incluye varias configuraciones avanzadas de nivel de memoria caché para controlar el comportamiento de las operaciones PUT cuando se utilizan réplicas. Estos valores son más relevantes cuando readMode: Se utiliza SLAVE.

cacheConfigs:
  cacheName:
    remoteConfig:
       forceReadFromMaster: [TRUE|false]
       syncReplicas: [NULL| <number_of_replicas> OR all : timeout_ms]
       limitSyncReplicasToNumberAvailable: [TRUE|false]

forceReadFromMaster

Cuando readMode se establece en SLAVE o MASTER_SLAVE, la configuración forceReadFromMaster garantiza que las escrituras (PUT) para esta memoria caché se envíen al servidor maestro.

syncReplicas

Esta configuración está inhabilitada de forma predeterminada. Si está habilitado, HCL Cache invoca el mandato WAIT después de una operación PUT. El mandato WAIT introduce un retardo hasta que el número configurado de réplicas ha procesado el cambio o se ha alcanzado el tiempo de espera excedido. En lugar de especificar un número fijo de réplicas, es posible utilizar all, lo que se traduce en el número de réplicas conocidas actualmente por el cliente de Redis. Ejemplo: Con la siguiente configuración, HCL Cache esperará hasta que el cambio se replique en todas las réplicas disponibles y esperará hasta 250 milisegundos:

  syncReplicas: all:250

limitSyncReplicasToNumberAvailable

Cuando syncReplicas está habilitada con varias réplicas, la configuración limitSyncReplicasToNumberAvailable se puede utilizar para restringir el número configurado al número de réplicas conocidas actualmente por el cliente de Redis.