Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Minimizar el tiempo de inactividad en ElastiCache Redis con Multi-AZ
Hay varios casos ElastiCache en los que Redis puede necesitar reemplazar un nodo principal; estos incluyen ciertos tipos de mantenimiento planificado y el improbable caso de que se produzca un fallo en un nodo principal o en una zona de disponibilidad.
Este reemplazo produce un tiempo de inactividad para el clúster, pero si Multi-AZ se encuentra habilitado, el tiempo de inactividad es mínimo. El rol del nodo primario tendrá una conmutación por error automática en una de las réplicas de lectura. No es necesario crear ni aprovisionar un nuevo nodo principal, ya que ElastiCache lo gestionará de forma transparente. Esta conmutación por error y promoción de réplica garantizan la posibilidad de reanudar la escritura en la réplica principal tan pronto como se complete la promoción.
ElastiCache también propaga el nombre del Servicio de nombres de dominio (DNS) de la réplica promocionada. Lo hace así porque, en ese caso, si su aplicación escribe en el punto de enlace principal, no se requiere ningún cambio de punto de conexión en su aplicación. Si lee desde puntos de conexión individuales, asegúrese de cambiar el punto de enlace de lectura de la réplica promovida a principal en el punto de enlace de la nueva réplica.
En caso de que se inicien reemplazos de nodos planificados debido a actualizaciones de mantenimiento o actualizaciones de autoservicio, tenga en cuenta lo siguiente:
En el ElastiCache caso del clúster de Redis, las sustituciones de nodos planificadas se completan mientras el clúster atiende las solicitudes de escritura entrantes.
En los clústeres que tienen el modo clúster de Redis deshabilitado con Multi-AZ habilitado y que se ejecutan en un motor versión 5.0.6 o superior, las sustituciones de nodos planeadas se realizan mientras el clúster atiende las solicitudes de escritura entrantes.
En los clústeres que tienen el modo clúster de Redis desactivado con Multi-AZ habilitado y que se ejecutan en un motor versión 4.0.10 o anterior, es posible que se produzca una breve interrupción de escritura asociada con las actualizaciones de DNS. Esta interrupción es posible que tarde unos segundos. Este proceso es mucho más rápido que el de volver a crear y aprovisionar una réplica principal nueva, que es el proceso que se realiza en caso de no habilitar Multi-AZ.
Puede habilitar Multi-AZ mediante la consola ElastiCache de administración AWS CLI, la o la API. ElastiCache
La activación de ElastiCache Multi-AZ en su clúster de Redis (en la API y la CLI, grupo de replicación) mejora su tolerancia a los errores. Esto es cierto especialmente en los casos en que el nodo principal de lectura/escritura del clúster deja de estar accesible o de funcionar por cualquier motivo. Multi-AZ solo se admite en clústeres de Redis que tienen más de un nodo en cada partición.
Temas
Habilitación de Multi-AZ
Puede habilitar Multi-AZ al crear o modificar un clúster (API o CLI, grupo de replicación) mediante la ElastiCache consola o la ElastiCache API. AWS CLI
Solo puede habilitar Multi-AZ en clústeres de Redis (modo de clúster deshabilitado) que tengan al menos una réplica de lectura disponible. Los clústeres sin réplicas de lectura no ofrecen alta disponibilidad ni tolerancia a errores. Para obtener información acerca de la creación de clústeres con reproducción, consulte Creación de un grupo de reproducción de Redis. Para obtener información acerca de la adición de réplicas de lectura a un clúster con reproducción, consulte Adición de una réplica de lectura, para grupos de reproducción de Redis (modo de clúster deshabilitado).
Temas
Habilitación de Multi-AZ (consola)
Puede habilitar las zonas de disponibilidad múltiples mediante la ElastiCache consola al crear un nuevo clúster de Redis o modificando un clúster de Redis existente mediante replicación.
Multi-AZ se encuentra habilitado de forma predeterminada en los clústeres de Redis (modo de clúster habilitado).
importante
ElastiCache activará automáticamente la zona de disponibilidad múltiple solo si el clúster contiene al menos una réplica en una zona de disponibilidad diferente de la principal en todos los fragmentos.
Habilitar Multi-AZ al crear un clúster mediante la consola ElastiCache
Para obtener más información acerca de este proceso, consulte Creación de un clúster de Redis (modo de clúster deshabilitado) (consola). Asegúrese de tener una o más réplicas y habilitar Multi-AZ.
Habilitación de Multi-AZ en un clúster existente (consola)
Para obtener más información sobre este proceso, consulte Modificación de un clúster Uso del AWS Management Console.
Habilitación de Multi-AZ (AWS CLI)
En el siguiente ejemplo de código, se utiliza AWS CLI para habilitar la zona de disponibilidad múltiple para el grupo de replicación. redis12
importante
El grupo de reproducción redis12 debe existir y tener al menos una réplica de lectura disponible.
Para Linux, macOS o Unix:
aws elasticache modify-replication-group \ --replication-group-idredis12\ --automatic-failover-enabled \ --multi-az-enabled \ --apply-immediately
Para Windows:
aws elasticache modify-replication-group ^ --replication-group-idredis12^ --automatic-failover-enabled ^ --multi-az-enabled ^ --apply-immediately
La salida JSON de este comando debería tener un aspecto similar al siguiente.
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "One shard, two nodes",
"NodeGroups": [
{
"Status": "modifying",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "redis12",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabling",
"MultiAZ": "enabled",
"SnapshotWindow": "07:00-08:00",
"SnapshottingClusterId": "redis12-002",
"MemberClusters": [
"redis12-001",
"redis12-002"
],
"PendingModifiedValues": {}
}
}Para obtener más información, consulte los temas siguientes en la Referencia de los comandos de la AWS CLI :
-
modify-replication-group en la Referencia de los comandos de la AWS CLI .
Habilitación de Multi-AZ (API) ElastiCache
El siguiente ejemplo de código usa la ElastiCache API para habilitar las zonas de disponibilidad múltiples para el grupo de replicación. redis12
nota
Para usar este ejemplo, el grupo de reproducción redis12 debe existir y tener al menos una réplica de lectura disponible.
https://elasticache.us-west-2.amazonaws.com/ ?Action=ModifyReplicationGroup &ApplyImmediately=true &AutoFailover=true &MultiAZEnabled=true &ReplicationGroupId=redis12 &Version=2015-02-02 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20140401T192317Z &X-Amz-Credential=<credential>
Para obtener más información, consulte estos temas en la referencia de la ElastiCache API:
Escenarios de error con respuestas de Multi-AZ
Antes de la introducción de las zonas de disponibilidad múltiples (Multi-AZ), ElastiCache detectaba y sustituía los nodos defectuosos de un clúster mediante la recreación y el reaprovisionamiento del nodo defectuoso. Si habilita Multi-AZ, un nodo principal que produce error conmuta por error a la réplica con el menor retraso de reproducción. La réplica seleccionada se promocionará automáticamente a la principal, lo cual es mucho más rápido que crear y reaprovisionar un nuevo nodo principal. Este proceso suele tardar tan solo unos segundos hasta que se puede escribir de nuevo en el clúster.
Cuando la Multi-AZ está habilitada, supervisa ElastiCache continuamente el estado del nodo principal. Si se produce un error en el nodo principal, se realiza una de las siguientes acciones en función del tipo de error.
Temas
Escenarios de error cuando solo se produce un error en el nodo principal
Si solo se produce un error en el nodo principal, la réplica de lectura con el menor retardo de reproducción se promociona al clúster principal. A continuación, se crea una réplica de lectura de reemplazo y se aprovisiona en la misma zona de disponibilidad que el principal ha producido un error.
Cuando solo falla el nodo principal, ElastiCache Multi-AZ hace lo siguiente:
El nodo principal con error se desconecta (sin conexión).
La réplica de lectura con el mínimo retardo de reproducción se promociona a nodo principal.
Las operaciones de escritura se pueden reanudar tan pronto como se haya completado el proceso de promoción, por lo general, en tan solo unos segundos. Si su aplicación está escribiendo en el punto final principal, no necesita cambiar el punto final de escritura o lectura. ElastiCachepropaga el nombre DNS de la réplica promocionada.
Una réplica de lectura de reemplazo se lanza y aprovisiona.
La réplica de lectura de reemplazo se lanza en la zona de disponibilidad en la que estaba el nodo principal con error, por lo que se mantiene la distribución de los nodos.
Las réplicas se sincronizan con el nuevo nodo principal.
Una vez que la nueva réplica esté disponible, tenga en cuenta estos efectos:
-
Punto de enlace principal: no debe realizar cambios en su aplicación, ya que el nombre de DNS del nodo primario nuevo se propagará al punto de conexión principal.
-
Punto de enlace de lectura: el punto de conexión del lector se actualiza de forma automática para apuntar a los nodos de réplica nuevos.
Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes:
Escenarios de error cuando el nodo primario y algunas réplicas de lectura producen un error
Si se produce un error en el nodo principal y en al menos una réplica, la réplica disponible con el menor retardo de reproducción se promocionará al clúster principal. Las nuevas réplicas de lectura también se crean y se aprovisionan en las mismas zonas de disponibilidad que las de los nodos con error y que la réplica que se promocionó a nodo principal.
Cuando el nodo principal y algunas réplicas de lectura fallan, ElastiCache Multi-AZ hace lo siguiente:
El nodo principal y las réplicas de lectura con error se desconectan.
La réplica disponible con el mínimo retardo de reproducción se promociona a nodo principal.
Las operaciones de escritura se pueden reanudar tan pronto como se haya completado el proceso de promoción, por lo general, en tan solo unos segundos. Si su aplicación está escribiendo en el punto final principal, no es necesario cambiar el punto final para las escrituras. ElastiCache propaga el nombre DNS de la réplica promocionada.
Las réplicas de reemplazo se crean y se aprovisionan.
Las réplicas de reemplazo se crean en las zonas de disponibilidad de los nodos con error para, de este modo, conservar la distribución de los nodos.
Todos los clústeres se sincronizan con el nodo principal.
Debe realizar los siguientes cambios en su aplicación una vez que los nuevos nodos estén disponibles:
-
Punto de conexión principal: no realice cambios en su aplicación. El nombre de DNS del nuevo nodo principal se propaga al punto de conexión principal.
-
Punto de conexión de lectura: el punto de enlace de lectura se actualiza de forma automática para apuntar a los nodos de réplica nuevos.
Para obtener información acerca de la búsqueda de los puntos de enlace de un grupo de replicación, consulte los temas siguientes:
Escenarios de error cuando se produce un error en todo el clúster
Si el error es general, todos los nodos se volverán a crear y a aprovisionar en las mismas zonas de disponibilidad que las de los nodos originales.
En esta situación, se perderán todos los datos del clúster debido al error de todos los nodos del clúster. Este tipo de error no suele producirse con frecuencia.
Cuando se produce un error en todo el clúster, ElastiCache Multi-AZ hace lo siguiente:
El nodo principal y las réplicas de lectura se desconectan.
Se crea y se aprovisiona un nodo principal de reemplazo.
Las réplicas de reemplazo se crean y se aprovisionan.
Los reemplazos se crean en las zonas de disponibilidad de los nodos con error para, de este modo, conservar la distribución de los nodos.
Puesto que el error ha afectado a la totalidad del clúster, los datos se perderán y los nuevos nodos se crean vacíos.
Puesto que cada uno de los nodos de reemplazo tendrán el mismo punto de conexión que el nodo al que reemplacen, no es necesario realizar ningún cambio de punto de conexión en su aplicación.
Para obtener información acerca de la búsqueda de los puntos de enlace de un grupo de replicación, consulte los temas siguientes:
Recomendamos que cree el nodo principal y las réplicas de lectura en distintas zonas de disponibilidad para incrementar el nivel de tolerancia a errores.
Prueba de la conmutación por error automática
Después de habilitar la conmutación por error automática, puede probarla mediante la ElastiCache consola AWS CLI, la y la ElastiCache API.
Cuando realice las pruebas, tenga en cuenta lo siguiente:
-
Puedes usar esta operación para probar la conmutación por error automática en hasta 15 fragmentos (denominados grupos de nodos en la ElastiCache API AWS CLI) en cualquier período continuo de 24 horas.
-
Si realiza una llamada a esta operación en fragmentos de distintos clústeres (denominados grupos de reproducción en la API y la CLI), podrá realizar las llamadas de forma simultánea.
-
En algunos casos, es posible que llame a esta operación varias veces en particiones diferentes del mismo grupo de reproducción de Redis (modo de clúster habilitado). En tales casos, la sustitución del primer nodo debe completarse antes de que se pueda realizar una llamada posterior.
-
Para determinar si se ha completado la sustitución del nodo, compruebe los eventos mediante la ElastiCache consola de Amazon AWS CLI, la o la ElastiCache API. Busque los eventos relacionados con la conmutación por error automática que se indican a continuación por orden de incidencia:
-
Mensaje del grupo de replicación:
Test Failover API called for node group <node-group-id> -
Mensaje del clúster de caché:
Failover from primary node <primary-node-id> to replica node <node-id> completed -
Mensaje del grupo de replicación:
Failover from primary node <primary-node-id> to replica node <node-id> completed -
Mensaje del clúster de caché:
Recovering cache nodes <node-id> -
Mensaje del clúster de caché:
Finished recovery for cache nodes <node-id>
Para más información, consulte los siguientes temas:
-
Visualización de eventos de ElastiCache en la Guía del usuario de ElastiCache .
-
DescribeEvents en la Referencia de la API de ElastiCache
-
describe-events en la Referencia de los comandos de la AWS CLI .
-
Esta API está diseñada para probar el comportamiento de la aplicación en caso de ElastiCache conmutación por error. No está diseñado para ser una herramienta operativa para iniciar una conmutación por error para solucionar un problema con el clúster. Además, en determinadas condiciones, como eventos operativos a gran escala, AWS puede bloquear esta API.
Temas
Probar la conmutación por error automática mediante el AWS Management Console
Utilice el procedimiento siguiente para probar la conmutación por error automática con la consola.
Para probar la conmutación por error automática
-
Inicie sesión en la ElastiCache consola AWS Management Console y ábrala en https://console.aws.amazon.com/elasticache/
. -
En el panel de navegación, seleccione Redis.
-
Desde la lista de clústeres de Redis, elija el cuadro situado a la izquierda del clúster que desea probar. El clúster debe tener al menos un nodo de réplica de lectura.
-
En el área Details, asegúrese de que este clúster tiene habilitadas Multi-AZ. Si el clúster no tiene habilitado Multi-AZ, elija un clúster distinto o modifique este clúster para habilitar Multi-AZ. Para obtener más información, consulte Uso del AWS Management Console.
Para Redis (modo de clúster deshabilitado), elija el nombre del clúster.
Para Redis (modo de clúster habilitado), realice lo siguiente:
-
Elija el nombre del clúster.
-
En la página Shards, elija el nombre del fragmento (denominado grupo de nodos en la API y la CLI) en el que desea probar la conmutación por error.
-
-
En la página Nodos, elija Failover Primary.
-
Elija Continue para realizar la conmutación por error al nodo principal, o bien Cancel para cancelar la operación y no realizar la conmutación por error al nodo principal.
Durante el proceso de conmutación por error, la consola seguirá mostrando el estado del nodo como disponible. Para realizar un seguimiento del progreso de la prueba de la conmutación por error, elija Events en el panel de navegación de la consola. En la pestaña Eventos, consulte los eventos que indican que la conmutación por error se ha iniciado (
Test Failover API called) y completado (Recovery completed).
Prueba de la conmutación por error automática mediante el AWS CLI
Puede probar la conmutación por error automática en cualquier clúster habilitado para zonas de disponibilidad múltiples mediante esta operación. AWS CLI test-failover
Parámetros
-
--replication-group-id: obligatorio. Grupo de reproducción (en la consola, clúster) que se va a comprobar. -
--node-group-id: obligatorio. Nombre del grupo de nodos en el que desea probar la conmutación por error automática. Puede probar un máximo de 15 grupos de nodos en un período continuo de 24 horas.
En el siguiente ejemplo, se utiliza AWS CLI para probar la conmutación por error automática en el grupo redis00-0003 de nodos del clúster de Redis (modo de clúster activado). redis00
ejemplo Pruebe la conmutación por error automática
Para Linux, macOS o Unix:
aws elasticache test-failover \ --replication-group-idredis00\ --node-group-idredis00-0003
Para Windows:
aws elasticache test-failover ^ --replication-group-idredis00^ --node-group-idredis00-0003
La salida del comando anterior es similar a la siguiente.
{
"ReplicationGroup": {
"Status": "available",
"Description": "1 shard, 3 nodes (1 + 2 replicas)",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ClusterEnabled": false,
"ReplicationGroupId": "redis1x3",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotWindow": "11:30-12:30",
"SnapshottingClusterId": "redis1x3-002",
"MemberClusters": [
"redis1x3-001",
"redis1x3-002",
"redis1x3-003"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}Para realizar un seguimiento del progreso de la conmutación por error, utilice la operación. AWS CLI describe-events
Para más información, consulte los siguientes temas:
-
test-failover en la Referencia de los comandos de la AWS CLI .
-
describe-events en la Referencia de los comandos de la AWS CLI .
Probar la conmutación por error automática mediante la API ElastiCache
Puede probar la conmutación por error automática en cualquier clúster habilitado con Multi-AZ mediante la operación de ElastiCache API. TestFailover
Parámetros
-
ReplicationGroupId: obligatorio. El grupo de reproducción (en la consola, clúster) que se va a comprobar. -
NodeGroupId: obligatorio. Nombre del grupo de nodos en el que desea probar la conmutación por error automática. Puede probar un máximo de 15 grupos de nodos en un período continuo de 24 horas.
El ejemplo siguiente comprueba la conmutación por error automática en el grupo de nodos redis00-0003 del grupo de reproducción (clúster, en la consola) redis00.
ejemplo Prueba de la conmutación por error automática
https://elasticache.us-west-2.amazonaws.com/ ?Action=TestFailover &NodeGroupId=redis00-0003 &ReplicationGroupId=redis00 &Version=2015-02-02 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20140401T192317Z &X-Amz-Credential=<credential>
Para realizar un seguimiento del progreso de la conmutación por error, utiliza la operación de la ElastiCache DescribeEvents API.
Para más información, consulte los siguientes temas:
-
TestFailoveren la referencia de la ElastiCache API
-
DescribeEventsen la referencia ElastiCache de la API
Limitaciones en Redis Multi-AZ
Tenga en cuenta las siguientes limitaciones para Redis Multi-AZ:
-
Multi-AZ es compatible con Redis versión 2.8.6 y versiones más recientes.
-
Redis Multi-AZ no es compatible con los tipos de nodos T1.
-
La reproducción de Redis es asíncrona. Por lo tanto, cuando un nodo principal realiza una conmutación por error a una réplica, se puede perder una pequeña cantidad de datos debido al retraso de reproducción.
Al elegir la réplica para pasar a ser principal, ElastiCache Redis elige la réplica con el menor retraso de replicación. En otras palabras, elija la réplica más actual. Esto ayuda a minimizar la cantidad de datos perdidos. La réplica que tiene el menor retardo de reproducción puede estar en la misma zona de disponibilidad que el nodo principal con error o en otra.
-
Solo se pueden promocionar de forma manual réplicas de lectura a nodos primarios en Redis (modo de clúster deshabilitado) si Multi-AZ y la conmutación por error automática se encuentran deshabilitados. Para promocionar una réplica de lectura a principal, siga estos pasos:
-
Deshabilite Multi-AZ en el clúster.
-
Deshabilite la conmutación por error automática en el clúster. Para ello, puede utilizar la consola de Redis al desactivar la casilla de verificación de Auto failover (Conmutación por error automática) para el grupo de reproducción. Para ello, puede establecer la AWS CLI
AutomaticFailoverEnabledpropiedad enfalseal llamar a laModifyReplicationGroupoperación. -
Promocione la réplica de lectura a principal.
-
Vuelva a habilitar Multi-AZ.
-
-
ElastiCache para Redis, Multi-AZ y el archivo solo anexado (AOF) se excluyen mutuamente. Si habilita una opción, no puede habilitar la otra.
-
El error de un nodo puede ser provocado por el improbable caso de que deje de funcionar una zona de disponibilidad completa. En este caso, la réplica que sustituye a la principal con error se creará únicamente si hay una copia de seguridad de la zona de disponibilidad. Por ejemplo, considere la posibilidad de un grupo de reproducción con el principal en AZ-a y las réplicas en AZ-b y AZ-c. Si el principal falla, la réplica con el menor retardo de reproducción se promociona al clúster principal. A continuación, ElastiCache crea una nueva réplica en AZ-a (donde se encontraba la principal averiada) solo cuando AZ-a esté disponible de nuevo.
-
Un reinicio iniciado por un cliente de un principal no desencadena la conmutación por error automática. Otros reinicios y errores sí activan la conmutación por error automática.
-
Cuando se reinicia el principal, sus datos se borran cuando vuelve a estar en línea. Cuando las réplicas de lectura ven el clúster principal borrado, borran sus copias de los datos, lo que provoca una pérdida de datos.
-
Después de la promoción de una réplica de lectura, las otras réplicas se sincronizan con el nuevo principal. Después de la sincronización inicial, el contenido de las réplicas se elimina y sincronizan los datos del nuevo principal. Este proceso de sincronización provoca una breve interrupción, durante la cual no se puede acceder a las réplicas. El proceso de sincronización también provoca un aumento de carga temporal en el principal mientras se sincroniza con las réplicas. Este comportamiento es nativo de Redis y no exclusivo de Multi-AZ. ElastiCache Para obtener más información sobre este comportamiento de Redis, consulte Replicación
en el sitio web de Redis.
importante
Para Redis versión 2.8.22 y versiones más recientes, no puede crear réplicas externas.
Para las versiones de Redis anteriores a la 2.8.22, le recomendamos que no conecte una réplica externa de Redis a un clúster de Redis que esté habilitado ElastiCache para zonas de disponibilidad múltiples. Esta configuración no compatible puede provocar problemas que impidan ElastiCache realizar correctamente la recuperación y la conmutación por error. Para conectar una réplica externa de Redis a un ElastiCache clúster, asegúrese de que Multi-AZ no esté activado antes de realizar la conexión.
