Minimización del tiempo de inactividad en MemoryDB con Multi-AZ - Amazon MemoryDB
Escenarios de error con respuestas de Multi-AZPrueba de la conmutación por error automática

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.

Minimización del tiempo de inactividad en MemoryDB con Multi-AZ

Hay varias situaciones en las que MemoryDB puede necesitar reemplazar un nodo principal. Entre ellas se incluyen determinados tipos de mantenimiento planificado y el caso poco probable de que se produzca un error en el nodo principal o en la zona de disponibilidad.

La respuesta al fallo del nodo depende del nodo que haya fallado. Sin embargo, en todos los casos, MemoryDB garantiza que no se pierdan datos durante la sustitución de nodos o la conmutación por error. Por ejemplo, si una réplica falla, el nodo fallido se reemplaza y los datos se sincronizan desde el registro de transacciones. Si el nodo principal falla, se desencadena una conmutación por error a una réplica coherente, lo que garantiza que no se pierdan datos durante la conmutación por error. Las escrituras ahora se realizan desde el nuevo nodo principal. A continuación, el nodo principal anterior se reemplaza y se sincroniza desde el registro de transacciones.

Si un nodo principal falla en una partición de un solo nodo (sin réplicas), MemoryDB deja de aceptar escrituras hasta que se sustituya el nodo principal y se sincronice desde el registro de transacciones.

El reemplazo de un nodo produce un tiempo de inactividad para el clúster, pero si Multi-AZ se encuentra activo, el tiempo de inactividad es mínimo. El rol del nodo principal tendrá una conmutación por error automática en una de las réplicas. No es necesario crear ni aprovisionar un nodo principal nuevo, ya que MemoryDB se encargará de esto de forma clara. 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.

En caso de que se inicien sustituciones de nodos planeadas debido a actualizaciones de mantenimiento o actualizaciones de servicio, tenga en cuenta que las sustituciones de nodos planeadas se completan mientras el clúster atiende las solicitudes de escritura entrantes.

Las zonas de disponibilidad múltiples en los clústeres de MemoryDB mejoran la tolerancia a los errores. Esto es cierto especialmente en los casos en que el nodo principal del clúster deja de estar accesible o de funcionar por cualquier motivo. La función Multi-AZ en los clústeres de MemoryDB requiere que cada partición tenga más de un nodo y se habilita automáticamente.

Escenarios de error con respuestas de Multi-AZ

Si Multi-AZ está activo, un nodo principal que produce error conmuta por error a una réplica disponible. La réplica se sincroniza automáticamente con el registro de transacciones y pasa a ser principal, lo que es mucho más rápido que crear y volver a aprovisionar un nodo principal nuevo. Este proceso suele tardar tan solo unos segundos hasta que se puede escribir de nuevo en el clúster.

Cuando Multi-AZ está activo, MemoryDB monitorea 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.

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 se convertirá automáticamente en principal. A continuación, se crea una réplica de reemplazo y se aprovisiona en la misma zona de disponibilidad que el principal ha producido un error.

Cuando solo se produce un error en el nodo principal, Multi-AZ de MemoryDB hace lo siguiente:

  1. El nodo principal con error se desconecta (sin conexión).

  2. Una up-to-date réplica se convierte automáticamente en principal.

    Las operaciones de escritura se pueden reanudar tan pronto como se haya completado el proceso de conmutación por error, por lo general, en tan solo unos segundos.

  3. Una réplica de reemplazo se lanza y aprovisiona.

    La réplica 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.

  4. La réplica se sincroniza con el registro de transacciones.

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 principal y algunas réplicas producen un error

Si la réplica principal y al menos una de ellas fallan, la up-to-date réplica pasa a ser un clúster principal. Las nuevas réplicas también se crean y se aprovisionan en las mismas zonas de disponibilidad que las de los nodos con error.

Cuando el nodo principal y algunas réplicas producen un error, Multi-AZ de MemoryDB hace lo siguiente:

  1. El nodo principal y las réplicas con error se desconectan.

  2. Una réplica disponible se convertirá en el nodo principal.

    Las operaciones de escritura se pueden reanudar en cuanto se haya completado el proceso de conmutación por error, por lo general, en tan solo unos segundos.

  3. 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.

  4. Todos los nodos se sincronizan con el registro de transacciones.

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 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.

No hay pérdida de datos en este escenario, ya que los datos se conservaban en el registro de transacciones.

Cuando se produce un error en todo el clúster, Multi-AZ de MemoryDB hace lo siguiente:

  1. El nodo principal y las réplicas se desconectan.

  2. Se crea y aprovisiona un nodo principal de reemplazo, que se sincroniza con el registro de transacciones.

  3. Se crean y aprovisionan réplicas de reemplazo, sincronizándolas con el registro de transacciones.

    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.

Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes:

Prueba de la conmutación por error automática

Puede probar la conmutación por error automática mediante la consola de MemoryDB, la AWS CLI y la API de MemoryDB.

Cuando realice las pruebas, tenga en cuenta lo siguiente:

  • Puede utilizar esta operación hasta cinco veces en un periodo de 24 horas.

  • Si realiza una llamada a esta operación en particiones de distintos clústeres, puede realizar las llamadas de forma simultánea.

  • En algunos casos, es posible llamar a esta operación varias veces en particiones diferentes del mismo clúster de MemoryDB. En tales casos, la sustitución del primer nodo debe completarse antes de que se pueda realizar una llamada posterior.

  • Para determinar si la sustitución del nodo se ha completado, compruebe los eventos mediante la consola de MemoryDB, la API de MemoryDB o la AWS CLI API de MemoryDB. Busque los siguientes eventos relacionados con FailoverShard, que se indican a continuación por orden de incidencia:

    1. mensaje de clúster: FailoverShard API called for shard <shard-id>

    2. mensaje de clúster: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. mensaje de clúster: Recovering nodes <node-id>

    4. mensaje de clúster: Finished recovery for nodes <node-id>

    Para más información, consulte los siguientes temas:

  • Esta API se ha diseñado para probar el comportamiento de la aplicación en caso de conmutación por error de MemoryDB. 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.

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.

  1. Inicie sesión en la consola de MemoryDB AWS Management Console y ábrala en https://console.aws.amazon.com/memorydb/.

  2. Seleccione el botón de opción situado a la izquierda al clúster que desea probar. Este clúster debe tener al menos un nodo de réplica.

  3. 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 Modificación de un clúster de MemoryDB.

  4. Elija el nombre del clúster.

  5. En la página Particiones y nodos, elija el nombre de la partición en la que desea probar la conmutación por error.

  6. Para el nodo, elija Realizar conmutación por error del nodo principal.

  7. 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 (FailoverShard 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 la partición de conmutación por error de AWS CLI operación.

Parámetros

  • --cluster-name: obligatorio. El clúster que se va a probar.

  • --shard-name: obligatorio. Nombre de la partición en la que desea probar la conmutación por error automática. Puede probar un máximo de cinco particiones en un periodo de 24 horas.

En el siguiente ejemplo, se utiliza AWS CLI para llamar a la partición del clúster failover-shard de MemoryDB. 0001 my-cluster

Para Linux, macOS o Unix:

aws memorydb failover-shard \
   --cluster-name my-cluster \
   --shard-name 0001

Para Windows:

aws memorydb failover-shard ^
   --cluster-name my-cluster ^
   --shard-name 0001

Para realizar un seguimiento del progreso de la conmutación por error, utilice la operación. AWS CLI describe-events

Devuelve la siguiente respuesta JSON:

{
    "Events": [
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Failover to replica node my-cluster-0001-002 completed",
            "Date": "2021-08-22T12:39:37.568000-07:00"
        },
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Starting failover for shard 0001",
            "Date": "2021-08-22T12:39:10.173000-07:00"
        }
    ]
}

Para más información, consulte los siguientes temas:

 

Prueba de la conmutación por error automática mediante la API de MemoryDB

En el siguiente ejemplo, se realiza una llamada a FailoverShard en la partición 0003 del clúster memorydb00.

ejemplo Prueba de la conmutación por error automática
https://memory-db.us-east-1.amazonaws.com/
    ?Action=FailoverShard
    &ShardName=0003
    &ClusterName=memorydb00
    &Version=2021-01-01
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20210801T192317Z
    &X-Amz-Credential=<credential>

Para realizar un seguimiento del progreso de la conmutación por error, use la operación DescribeEvents de la API de MemoryDB.

Para más información, consulte los siguientes temas: