Recuperación ante desastres y clústeres globales de Amazon DocumentDB - Amazon DocumentDB

View a markdown version of this page

Recuperación ante desastres y clústeres globales de Amazon DocumentDB - Amazon DocumentDB

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.

Recuperación ante desastres y clústeres globales de Amazon DocumentDB

Al usar un clúster global, puedes recuperarte rápidamente de desastres, como los errores regionales. La recuperación de desastres suele medirse mediante valores para RTO y RPO.

  • Objetivo de tiempo de recuperación (RTO) – El tiempo que tarda un sistema en volver a un estado operativo después de un desastre. En otras palabras, el RTO mide el tiempo de inactividad. Para un clúster global, RTO en minutos.

  • Objetivo de punto de recuperación (RPO) – La cantidad de datos que se pueden perder (medidos en el tiempo). Para un clúster global, el RPO suele medirse en segundos.

  • Para recuperarte de una interrupción no planificada, puedes realizar una conmutación por error entre regiones a una de las unidades secundarias de tu clúster global. Si tu clúster global tiene varias regiones secundarias, asegúrate de separar todas las regiones secundarias que quieras promover como principales. Luego, promocionas una de esas regiones secundarias para convertirla en la nueva región principal. Región de AWS Por último, crea nuevos clústeres en cada una de las demás regiones secundarias y vincula esos clústeres a tu clúster global.

Ejecución de una conmutación por error administrada para un clúster global de Amazon DocumentDB

Este enfoque tiene por objeto garantizar la continuidad empresarial en caso de que se produzca un verdadero desastre regional o una interrupción total del nivel de servicio.

Durante una conmutación por error administrada, el clúster principal se conmuta por error a la región secundaria que elija mientras se mantiene la topología de reproducción existente del clúster global de Amazon DocumentDB. El clúster secundario elegido promueve uno de sus nodos de solo de lectura al estado de escritor completo. Este paso permite que el clúster asuma el rol de clúster principal. La base de datos no estará disponible durante un breve periodo, mientras el clúster asume su nuevo rol. Los datos que no se replicaron del clúster principal anterior al clúster secundario elegido se pueden perder cuando este clúster secundario se convierta en el nuevo clúster principal. El volumen principal anterior hace todo lo posible por tomar una instantánea antes de sincronizarla con el nuevo volumen principal, de modo que los datos no replicados se conserven en la instantánea.

nota

Solo puede hacer una conmutación por error administrada del clúster entre regiones en un clúster global de Amazon DocumentDB si el clúster principal y todos los clústeres secundarios tienen las mismas versiones del motor. Si las versiones del motor no son compatibles, puede realizar la conmutación por error manualmente por medio de los pasos que se indican en Ejecución de una conmutación por error manual para un clúster global de Amazon DocumentDB.

Si las versiones del motor de la región no coinciden, se bloqueará la conmutación por error. Comprueba si hay actualizaciones pendientes y aplícalas para asegurarte de que todas las versiones del motor de la región coinciden y de que la conmutación por error del clúster global está desbloqueada. Para obtener más información, consulte Desbloqueo de una conmutación por error o una transición de clúster global.

Para minimizar la pérdida de datos, haga lo siguiente antes de usar esta función:

  • Desconecte las aplicaciones para evitar que se envíen escrituras al clúster principal del clúster global de Amazon DocumentDB.

  • Compruebe los tiempos de retraso para todos los clústeres secundarios de Amazon DocumentDB. La elección de la región secundaria con el menor retraso de replicación puede minimizar la pérdida de datos con respecto a la región principal que actualmente presenta errores. Compruebe los tiempos de retraso de todos los clústeres secundarios de Amazon DocumentDB del clúster global consultando la GlobalClusterReplicationLag métrica en Amazon CloudWatch. Estas métricas muestran el retraso (en milisegundos) de la replicación a un clúster secundario con respecto al clúster principal.

    Para obtener más información sobre CloudWatch las métricas de Amazon DocumentDB, consulte. Métricas de Amazon DocumentDB

Durante una conmutación por error administrada, el clúster secundario elegido se promueve a su nuevo rol de clúster principal. Sin embargo, no hereda las diversas opciones de configuración del clúster principal. Una falta de coincidencia en la configuración puede provocar problemas de rendimiento, incompatibilidades de carga de trabajo y otros comportamientos anómalos. Para evitar estos problemas, resuelva las diferencias entre los clústeres globales de Amazon DocumentDB en relación con lo siguiente:

  • Si es necesario, configure un grupo de parámetros de clúster de Amazon DocumentDB para el nuevo clúster principal. Puede configurar los grupos de parámetros del clúster de Amazon DocumentDB de forma independiente para cada clúster de su clúster global de Amazon DocumentDB. Por lo tanto, cuando se promueve un clúster secundario para que asuma el rol principal, su grupo de parámetros puede configurarse de manera diferente que para el principal. Si es así, modifique el grupo de parámetros del clúster secundario promocionado para que se ajuste a la configuración del clúster principal. Para aprender a hacerlo, consulte Modificación de grupos de parámetros de clúster de Amazon DocumentDB.

  • Configure las herramientas y opciones de monitoreo, como CloudWatch los eventos y las alarmas de Amazon: configure el clúster promocionado con la misma capacidad de registro, alarmas, etc., según sea necesario para el clúster global. Al igual que con los grupos de parámetros, la configuración de estas características no se hereda del clúster principal durante el proceso de conmutación por error. Algunas CloudWatch métricas, como el retraso de replicación, solo están disponibles para las regiones secundarias. Por lo tanto, una conmutación por error cambia la forma de ver esas métricas y configurar las alarmas en ellas, y podría requerir cambios en los paneles predefinidos. Para obtener más información sobre los clústeres de Amazon DocumentDB y la supervisión, consulte Supervisión y registro en Amazon DocumentDB.

Por lo general, el clúster secundario elegido asume el rol principal en menos de un minuto. En cuanto el nodo de escritor de la nueva región principal esté disponible, podrá conectar sus aplicaciones a él y reanudar sus cargas de trabajo. Una vez que Amazon DocumentDB promueve el nuevo clúster principal, reconstruye automáticamente todos los clústeres regionales secundarios adicionales.

Como los clústeres globales de Amazon DocumentDB utilizan la replicación asíncrona, el retraso de la replicación en cada región secundaria puede variar. Amazon DocumentDB reconstruye estas regiones secundarias para que tengan exactamente los mismos datos de un momento dado que el nuevo clúster de región principal. La duración de la tarea de reconstrucción completa puede tardar entre unos minutos y varias horas, según el tamaño del volumen de almacenamiento y la distancia entre las regiones. Cuando los clústeres de la región secundaria terminen de reconstruirse a partir de la nueva región principal, estarán disponibles para el acceso de lectura. Tan pronto como se promocione y esté disponible el nuevo escritor principal, el clúster de la nueva región principal podrá gestionar las operaciones de lectura y escritura del clúster global de Amazon DocumentDB.

Para restaurar la topología original del clúster global, Amazon DocumentDB supervisa la disponibilidad de la antigua región principal. Tan pronto como la región esté en buen estado y vuelva a estar disponible, Amazon DocumentDB volverá a agregarla automáticamente al clúster global como región secundaria. Antes de crear el nuevo volumen de almacenamiento en la antigua región principal, Amazon DocumentDB intenta tomar una instantánea del volumen de almacenamiento anterior en el punto en que se produjo el error. Lo hace para que pueda usarla para recuperar cualquiera de los datos perdidos. Si esta operación se realiza correctamente, Amazon DocumentDB coloca esta instantánea denominada «rds:docdb-unplanned-global-failovername-of-old-primary-» en la sección de instantáneas de. DB-cluster-timestamp Consola de administración de AWS También puede ver esta instantánea en la información devuelta por la operación de la API DescribeDBClusterSnapshots.

nota

La instantánea del volumen de almacenamiento anterior es una instantánea del sistema que está sujeta al período de retención de la copia de seguridad configurado en el clúster principal anterior. Para conservar esta instantánea más allá del período de retención, puede copiarla para guardarla como una instantánea manual. Para obtener más información sobre la copia de instantáneas, incluido el precio, consulte Copia de una instantánea de clúster.

Una vez restaurada la topología original, puede conmutar por recuperación el clúster global a la región principal original mediante una operación de transición cuando sea más conveniente para su empresa y su carga de trabajo. Para ello, siga los pasos que se indican en Ejecución de una transición para un clúster global de Amazon DocumentDB.

Puede conmutar por error su clúster global de Amazon DocumentDB mediante la API, la o la API de Amazon DocumentDB. Consola de administración de AWS AWS CLI

Using the Consola de administración de AWS

Ejecución de una conmutación por error administrada en el clúster global de Amazon DocumentDB

  1. Inicie sesión en y abra la Consola de administración de AWS consola de Amazon DocumentDB en. https://console.aws.amazon.com/docdb

  2. En el panel de navegación, seleccione Clusters (Clústeres).

  3. Busque y elija el clúster global de Amazon DocumentDB que desea someter al proceso de conmutación por error.

    Imagen: tabla de clústeres con el clúster global seleccionado.
  4. Elija Transición o conmutación por error en el menú Acciones.

  5. En el cuadro de diálogo que aparece, seleccione Conmutación por error y, a continuación, elija el clúster secundario en la lista desplegable del campo Nuevo clúster principal.

    Imagen: cuadro de diálogo de transición o conmutación por error de clúster global.
  6. Escriba “confirmar” en el último campo. A continuación, seleccione Confirm (Confirmar).

    El estado del clúster principal cambia a "Failing-over». Esta condición puede necesitar aproximadamente un minuto. Durante este tiempo, el estado del nuevo clúster principal muestra “Modificando…”. Una vez que se promocione el nuevo clúster principal, aparecerá como “Disponible” y podrá procesar transacciones de lectura y escritura. Las regiones secundarias, incluida la antigua principal, mostrarán «Resincronizando... «mientras se resincroniza con la nueva primaria. Al igual que el nuevo clúster principal, solo podrá procesar transacciones una vez que su estado cambie a “Disponible”.

  7. Cuando se complete, el clúster principal original se convierte en el clúster secundario. El clúster secundario seleccionado se convierte en el clúster principal.

    Imagen: tabla de clústeres que muestra el nuevo clúster principal.
Using the AWS CLI

Ejecución de una conmutación por error administrada en el clúster global de Amazon DocumentDB

Ejecute el comando failover-global-cluster de la CLI para conmutar por error el clúster global de Amazon DocumentDB. Con el comando, pase valores para las siguientes opciones:

  • --region

  • --global-cluster-identifier

  • --target-db-cluster-identifier

  • --allow-data-loss

En los siguientes ejemplos, sustituya cada uno por la información user input placeholder de su clúster.

Para Linux, macOS o Unix:

aws docdb failover-global-cluster \ --region region_of_selected_secondary \ --global-cluster-identifier global_cluster_id \ --target-db-cluster-identifier arn_of_secondary_to_promote \ --allow-data-loss

Para Windows:

aws docdb failover-global-cluster ^ --region region_of_selected_secondary ^ --global-cluster-identifier global_cluster_id ^ --target-db-cluster-identifier arn_of_secondary_to_promote ^ --allow-data-loss

Ejecución de una conmutación por error manual para un clúster global de Amazon DocumentDB

Si un clúster completo de uno Región de AWS deja de estar disponible, puedes promocionar otro clúster del clúster global para que tenga read/write capacidad.

Puede activar manualmente el mecanismo de conmutación por error del clúster global si un clúster de una Región de AWS diferente es una mejor opción para ser el clúster primario. Por ejemplo, puede aumentar la capacidad de uno de esos clústeres secundarios y promoverlo para que sea el clúster principal. O bien, el equilibrio de actividad entre ellos Regiones de AWS podría cambiar, por lo que cambiar el clúster principal a otro Región de AWS podría reducir la latencia de las operaciones de escritura.

El siguiente procedimiento describe qué hacer para promocionar uno de los clústeres secundarios de un clúster global de Amazon DocumentDB.

Para promover un clúster secundario:

  1. Deje de emitir sentencias DML y otras operaciones de escritura en el clúster principal durante Región de AWS la interrupción.

  2. Identifique un clúster de un secundario Región de AWS para usarlo como un clúster principal nuevo. Si tienes dos (o más) secundarios Regiones de AWS en tu clúster global, elige el clúster secundario que tenga el menor retraso.

  3. Desconecte el clúster secundario del clúster global elegido.

    Al eliminar un clúster secundario de un clúster global, se detiene inmediatamente la replicación del clúster principal a este secundario y lo convierte en un clúster aprovisionado independiente con todas read/write las capacidades. Cualquier otro clúster secundario asociado al clúster principal de la región donde se produjo la interrupción seguirá estando disponible y puede aceptar llamadas desde su aplicación. También consumen recursos. Dado que está recreando el clúster global, para evitar problemas de split-brain y otros problemas, elimine los otros clústeres secundarios antes de crear el nuevo clúster en los pasos que se indican a continuación.

    Para obtener más información sobre los pasos para desasociar clústeres, consulte Eliminación de un clúster global de Amazon DocumentDB.

  4. Este clúster se convierte en el clúster primario de un nuevo clúster global cuando comienza a agregarle regiones, en el siguiente paso.

  5. Agregue un Región de AWS al clúster. Al hacerlo, comienza el proceso de reproducción de clúster principal a secundario.

  6. Agregue más Regiones de AWS según sea necesario para volver a crear la topología necesaria para respaldar su aplicación. Asegúrese de que las escrituras de la aplicación se envían al clúster correcto antes, durante y después de realizar cambios como estos, para evitar incoherencias de datos entre los clústeres en el clúster global (problemas de split-brain).

  7. Cuando se haya resuelto la interrupción y esté listo para asignar su Región de AWS original como clúster primario de nuevo, realice los mismos pasos en orden inverso.

  8. Elimine uno de los clústeres secundarios del clúster global. Esto le permitirá atender read/write el tráfico.

  9. Redirija todo el tráfico de escritura del clúster primario en la Región de AWS original.

  10. Agregue un Región de AWS para configurar uno o más clústeres secundarios de la Región de AWS misma manera que antes.

Los clústeres globales de Amazon DocumentDB se pueden administrar mediante AWS SDK, lo que le permite crear soluciones para automatizar el proceso de conmutación por error global de los clústeres en casos de uso de la recuperación ante desastres y la planificación de la continuidad empresarial. Una de estas soluciones está disponible para nuestros clientes con las licencias de Apache 2.0 y se puede acceder a ella desde nuestro repositorio de herramientas aquí. Esta solución aprovecha Amazon Route 53 para la administración de puntos finales y proporciona AWS Lambda funciones que se pueden activar en función de los eventos apropiados.

Ejecución de una transición para un clúster global de Amazon DocumentDB

Al utilizar las transiciones, puede cambiar la región del clúster principal de forma rutinaria. Este enfoque está destinado a situaciones controladas, como el mantenimiento operativo y otros procedimientos operativos planificados.

Existen tres casos de uso frecuentes en los que se utilizan las transiciones:

  • Para los requisitos de “rotación regional” impuestos a sectores específicos. Por ejemplo, es posible que los reglamentos de los servicios financieros exijan que los sistemas de nivel 0 se cambien a una región diferente durante varios meses para garantizar que los procedimientos de recuperación ante desastres se ensayen con cierta asiduidad.

  • Para aplicaciones multirregionales del tipo “seguir el sol”. Por ejemplo, es posible que una empresa desee ofrecer escrituras con menor latencia en diferentes regiones en función del horario laboral en distintas zonas horarias.

  • Como método sin pérdida de datos para conmutar por recuperación a la región principal original tras una conmutación por error.

nota

Las transiciones están diseñadas para utilizarse en un clúster global de Amazon DocumentDB en buen estado. Para la recuperación de una interrupción no programada, siga el procedimiento correspondiente en Ejecución de una conmutación por error manual para un clúster global de Amazon DocumentDB.

Para realizar un cambio, todas las regiones secundarias deben ejecutar exactamente la misma versión del motor que la principal. Si las versiones del motor de la región no coinciden, se bloqueará el cambio. Comprueba si hay actualizaciones pendientes y aplícalas para asegurarte de que todas las versiones del motor de la región coinciden y de que el cambio de clúster global está desbloqueado. Para obtener más información, consulte Desbloqueo de una conmutación por error o una transición de clúster global.

Durante una transición, Amazon DocumentDB cambia el clúster principal a la región secundaria que elija a la vez que mantiene la topología de replicación existente del clúster global. Antes de iniciar el proceso de transición, Amazon DocumentDB espera a que todos los clústeres de regiones secundarias estén completamente sincronizados con el clúster de la región principal. A continuación, el clúster de bases de datos de la región principal se convierte en un clúster de solo lectura y el clúster secundario que elija promueve uno de sus nodos de solo lectura a estado de escritor completo. Al convertir este nodo en escritor, el clúster secundario puede asumir el rol de clúster principal. Dado que todos los clústeres secundarios se sincronizaron con el principal al principio del proceso, el nuevo principal continúa las operaciones para el clúster global de Amazon DocumentDB sin perder ningún dato. La base de datos no estará disponible durante un breve periodo, mientras los clústeres principales y secundarios seleccionados asumen nuevas funciones.

Para optimizar la disponibilidad de las aplicaciones, haga lo siguiente antes de usar esta función:

  • Lleve a cabo esta operación durante los horarios menos concurridos o en otro momento cuando las escrituras en el clúster principal sean mínimas.

  • Desconecte las aplicaciones para evitar que se envíen escrituras al clúster principal del clúster global de Amazon DocumentDB.

  • Compruebe los tiempos de retraso de todos los clústeres secundarios de Amazon DocumentDB del clúster global consultando la GlobalClusterReplicationLag métrica en Amazon CloudWatch. Esta métrica muestra el retraso (en milisegundos) de la replicación a un clúster secundario con respecto al clúster principal. Este valor es directamente proporcional al tiempo que tarda Amazon DocumentDB en completar la transición. Por lo tanto, cuanto mayor sea el valor de retraso, más tiempo llevará la transición.

    Para obtener más información sobre CloudWatch las métricas de Amazon DocumentDB, consulte. Métricas de Amazon DocumentDB

Durante una transición, el clúster secundario de base de datos elegido se promueve a su nuevo rol de clúster principal. Sin embargo, no hereda las diversas opciones de configuración del clúster principal de base de datos. Una falta de coincidencia en la configuración puede provocar problemas de rendimiento, incompatibilidades de carga de trabajo y otros comportamientos anómalos. Para evitar estos problemas, resuelva las diferencias entre los clústeres globales de Amazon DocumentDB en relación con lo siguiente:

  • Configure un grupo de parámetros de clúster de base de datos de Amazon DocumentDB para el nuevo clúster principal, si es necesario: puede configurar los grupos de parámetros de clúster de Amazon DocumentDB de forma independiente para cada clúster del clúster global de Amazon DocumentDB. Esto significa que cuando se promueve un clúster secundario de base de datos para asumir el rol principal, su grupo de parámetros puede configurarse de manera diferente que para el principal. Si es así, modifique el grupo de parámetros del clúster secundario de base de datos promocionado para que se ajuste a la configuración del clúster principal. Para saber cómo hacerlo, consulte Administración de los grupos de parámetros de clúster de Amazon DocumentDB.

  • Configure las herramientas y opciones de monitoreo, como CloudWatch los eventos y las alarmas de Amazon: configure el clúster promocionado con la misma capacidad de registro, alarmas, etc., según sea necesario para el clúster global. Al igual que con los grupos de parámetros, la configuración de estas características no se hereda del clúster principal durante el proceso de transición. Algunas CloudWatch métricas, como el retraso de replicación, solo están disponibles para las regiones principales. Por lo tanto, una transición cambia la forma de ver esas métricas y configurar las alarmas en ellas, y podría requerir cambios en los paneles predefinidos. Para obtener más información, consulte Supervisión y registro en Amazon DocumentDB.

nota

Por lo general, la transición de rol puede tardar varios minutos.

Cuando finaliza el proceso de transición, el clúster de Amazon DocumentDB promocionado puede manejar operaciones de escritura para el clúster global.

Puede cambiar su clúster global de Amazon DocumentDB mediante las siguientes Consola de administración de AWS opciones: AWS CLI

Using the Consola de administración de AWS

Ejecución de una transición en un clúster global de Amazon DocumentDB

  1. Inicie sesión en y abra Consola de administración de AWS la consola de Amazon DocumentDB en. https://console.aws.amazon.com/docdb

  2. En el panel de navegación, seleccione Clusters (Clústeres).

  3. Busque y elija el clúster global de Amazon DocumentDB que desea someter al proceso de transición.

    Imagen: tabla de clústeres con el clúster global seleccionado.
  4. Elija Transición o conmutación por error en el menú Acciones.

  5. En el cuadro de diálogo que aparece, seleccione Transición y, a continuación, elija el clúster secundario en la lista desplegable del campo Nuevo clúster principal.

    Imagen: diálogo de cambio de clúster con el clúster secundario seleccionado.
  6. Elija Confirmar.

    El estado del clúster principal cambia a "Switching-over». Esta condición puede necesitar aproximadamente tres minutos. Durante este tiempo, el estado de todos los clústeres regionales muestra “Modificando...”. Una vez que las regiones estén sincronizadas y se promueva el nuevo servidor principal, aparecerá la palabra «Disponible» en todos los campos de estado y podrá atender las transacciones.

  7. Cuando se complete, el clúster principal original se convierte en el clúster secundario. El clúster secundario seleccionado se convierte en el clúster principal.

    Imagen: tabla de clústeres que muestra el nuevo clúster principal.
Using the AWS CLI

Ejecución de una transición en un clúster global de Amazon DocumentDB

Utilice el comando switchover-global-cluster de la CLI para hacer la transición del clúster global de Amazon DocumentDB. Con el comando, pase valores para las siguientes opciones:

  • --region

  • --global-cluster-identifier

  • --target-db-cluster-identifier

En los siguientes ejemplos, sustituya cada uno por user input placeholder la información de su clúster.

Para Linux, macOS o Unix:

aws docdb switchover-global-cluster \ --region region_of_primary \ --global-cluster-identifier global_cluster_id \ --target-db-cluster-identifier arn_of_secondary_to_promote

Para Windows:

aws docdb switchover-global-cluster ^ --region region_of_primary ^ --global-cluster-identifier global_cluster_id ^ --target-db-cluster-identifier arn_of_secondary_to_promote

Desbloqueo de una conmutación por error o una transición de clúster global

Regiones en diferentes versiones del motor

Las transiciones y las conmutaciones por error de clústeres globales se bloquean cuando no todos los clústeres regionales del clúster global están en la misma versión del motor. Si las versiones no coinciden, es posible que aparezca este error al realizar una conmutación o una conmutación por error: el clúster de base de datos de destino especificado ejecuta una versión de motor con un nivel de parche diferente al del clúster de base de datos de origen. Aplica de forma rutinaria las versiones más recientes del motor para mantener los clústeres globales en buen estado.

Para resolver este error, actualice primero todas las regiones secundarias y, después, la región principal a la misma versión del motor. Para ello, aplique las acciones de mantenimiento pendientes. Para ver las acciones de mantenimiento pendientes y aplicar los cambios necesarios para corregir el problema, siga las instrucciones de una de las siguientes pestañas:

Using the Consola de administración de AWS

Para desbloquear una transición o conmutación por error de clúster global, debe determinar si hay acciones de mantenimiento pendientes para sus clústeres y aplicarlas. Siga estos pasos para ver y aplicar las acciones de mantenimiento:

  1. Inicie sesión en y abra la Consola de administración de AWS consola de Amazon DocumentDB en https://console.aws.amazon.com/docdb.

  2. En el panel de navegación, seleccione Clusters (Clústeres).

  3. En la tabla Clústeres, localice el clúster global en la columna de Identificador de clúster. En su clúster global, anote cada clúster secundario y el clúster principal del clúster global en cuestión, y realice los siguientes pasos para cada uno.

  4. Para cada clúster secundario:

    1. Si hay una actualización disponible para el clúster, se indicará con la palabra Disponible, Obligatorio o Siguiente período en la columna Mantenimiento.

    2. Para realizar una acción, elija el clúster para mostrar sus detalles y, a continuación, seleccione Mantenimiento y copias de seguridad. Aparecerán los elementos de mantenimiento pendientes.

    3. En Descripción, si indica que hay una «Nueva actualización de mantenimiento disponible», selecciónela y, a continuación, elija Aplicar ahora.

  5. Para su clúster principal:

    1. Si hay una actualización disponible para el clúster, se indicará con la palabra Disponible, Obligatorio o Siguiente período en la columna Mantenimiento.

    2. Para realizar una acción, elija el clúster para mostrar sus detalles y, a continuación, seleccione Mantenimiento y copias de seguridad. Aparecerán los elementos de mantenimiento pendientes.

    3. En Descripción, si indica que hay una «Nueva actualización de mantenimiento disponible», selecciónela y, a continuación, elija Aplicar ahora.

Using the AWS CLI

Para desbloquear una transición o conmutación por error de clúster global, debe determinar si hay acciones de mantenimiento pendientes para el clúster y aplicarlas. Siga estos pasos para ver y aplicar las acciones de mantenimiento primero en los clústeres secundarios y, después, en el clúster principal del clúster global:

  1. Ejecute primero lo siguiente en el clúster regional de cada región secundaria y, a continuación, en el clúster regional principal de las regiones.

  2. Ejecute el comando describe-pending-maintenance-actions de la CLI con la opción --resource-identifier para determinar si hay acciones de mantenimiento disponibles para su clúster regional de Amazon DocumentDB.

    En los siguientes ejemplos, reemplaza cada uno user input placeholder por la información de tu clúster.

    Para Linux, macOS o Unix:

    aws docdb describe-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15

    Para Windows:

    aws docdb describe-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15

    El resultado tendrá un aspecto parecido al siguiente:

    { "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "CurrentApplyDate": "2025-04-11T03:01:00Z", "Description": "db-version-upgrade", "ForcedApplyDate": "2025-06-18T03:01:00Z", "AutoAppliedAfterDate": "2025-05-11T03:01:00Z" "OptInStatus": "pending" } ] } ] }
  3. Si es necesaria una acción de mantenimiento, ejecute el comando apply-pending-maintenance-action de la CLI con las siguientes opciones:

    • --resource-identifier

    • --apply-action

    • --opt-in-type

    • --region

    En los siguientes ejemplos, sustituya cada uno user input placeholder por la información de su clúster.

    Para Linux, macOS o Unix:

    aws docdb apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 \ --apply-action system-update \ --opt-in-type immediate \ --region us-east-1

    Para Windows:

    aws docdb apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 ^ --apply-action system-update ^ --opt-in-type immediate ^ --region us-east-1
  4. Una vez finalizada la acción de mantenimiento, vuelva a ejecutar el comando describe-pending-maintenance-actions para asegurarse de que no haya otras acciones pendientes para el clúster.

    El resultado que desea es:

    { "PendingMaintenanceActions": [] }
Using the Amazon DocumentDB API

Para desbloquear una transición o conmutación por error de clúster global, debe determinar si hay acciones de mantenimiento pendientes para el clúster y aplicarlas. Use las siguientes API para ver y aplicar las acciones de mantenimiento:

  1. Ejecuta primero lo siguiente en el clúster regional de cada región secundaria y, después, en el clúster regional principal de las regiones.

  2. Llame a la API de PendingMaintenanceAction para determinar si hay acciones de mantenimiento disponibles para su clúster global de Amazon DocumentDB.

  3. Para aplicar cualquier cambio, llame a la API de ApplyPendingMaintenanceAction.

Cambios pendientes en el clúster de destino

Las conmutaciones y las conmutaciones por error también se bloquean cuando el clúster secundario de destino tiene un cambio programado que aún no se ha aplicado, como una acción de modificación o mantenimiento que hayas solicitado para el siguiente período de mantenimiento. En este caso, es posible que aparezca este error al realizar una conmutación o una conmutación por error: no puedes realizar una conmutación por error al clúster con ARN arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 porque se está modificando o porque hay modificaciones pendientes. Vuelva a intentarlo cuando el clúster esté disponible. Para desbloquear la operación, elimine el cambio programado en el clúster de destino. Los pasos dependen del tipo de cambio. Cuando se elimine el cambio programado y el estado del clúster vuelva a seravailable, vuelva a intentar la conmutación o la conmutación por error.

Cancela una acción de mantenimiento programada

No puedes cancelar una acción de mantenimiento programada (deshacer una suscripción) desde Consola de administración de AWS, así que usa el AWS CLI.

Using the AWS CLI
  1. Ejecute el comando describe-pending-maintenance-actions de la CLI con la --resource-identifier opción y busque una acción de mantenimiento que sea. OptInStatus next-maintenance

    En los siguientes ejemplos, sustituya cada uno por la información de su clúster. user input placeholder

    Para Linux, macOS o Unix:

    aws docdb describe-pending-maintenance-actions \ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 \ --region us-east-1

    Para Windows:

    aws docdb describe-pending-maintenance-actions ^ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 ^ --region us-east-1

    El resultado es similar al siguiente. Anote el Action valor (os-upgradeen este ejemplo) que utilizará en el paso siguiente.

    { "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15", "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade", "OptInStatus": "next-maintenance", "CurrentApplyDate": "2026-09-02T03:02:00Z", "Description": "New Operating System update is available" } ] } ] }
  2. Para cancelar la acción programada, ejecute el comando apply-pending-maintenance-action de la CLI y transfiera el valor del paso --opt-in-type undo-opt-in anterior a. Action --apply-action

    Para Linux, macOS o Unix:

    aws docdb apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 \ --apply-action os-upgrade \ --opt-in-type undo-opt-in \ --region us-east-1

    Para Windows:

    aws docdb apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15 ^ --apply-action os-upgrade ^ --opt-in-type undo-opt-in ^ --region us-east-1

    En la respuesta, la acción de mantenimiento ya no tiene un, lo que confirma que se canceló la suscripción OptInStatus programada.

    { "ResourcePendingMaintenanceActions": { "ResourceIdentifier": "arn:aws:rds:us-east-1:001234567890:cluster:docdb-2025-03-27-19-21-15", "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade", "Description": "New Operating System update is available" } ] } }
Revertir una modificación de clúster programada
Using the AWS CLI
  1. Compruebe si hay modificaciones programadas ejecutando el comando describe-db-clusters de la CLI e inspeccionando el campo de salida. PendingModifiedValues

    nota

    Utilice la CLI de Amazon RDS (aws rds) para este comando, no la CLI de Amazon DocumentDB (aws docdb), porque la API de Amazon DocumentDB no devuelve ningún campo a nivel de clúster. describe-db-clusters PendingModifiedValues

    En los siguientes ejemplos, sustituya cada uno user input placeholder por la información de su clúster.

    Para Linux, macOS o Unix:

    aws rds describe-db-clusters \ --db-cluster-identifier docdb-2025-03-27-19-21-15 \ --query 'DBClusters[0].PendingModifiedValues' \ --region us-east-1

    Para Windows:

    aws rds describe-db-clusters ^ --db-cluster-identifier docdb-2025-03-27-19-21-15 ^ --query "DBClusters[0].PendingModifiedValues" ^ --region us-east-1

    El resultado muestra los cambios programados. En este ejemplo, está pendiente un cambio en el nombre del clúster (DBClusterIdentifier), de docdb-2025-03-27-19-21-15 adocdb-new-name.

    { "DBClusterIdentifier": "docdb-new-name" }
  2. Para revertir el cambio, ejecute el comando de la CLI modify-db-cluster con --apply-immediately y restablezca el valor modificado en su valor original. En este ejemplo, se revierte el cambio de nombre pendiente --new-db-cluster-identifier restableciendo el nombre actual del clúster.

    Para Linux, macOS o Unix:

    aws docdb modify-db-cluster \ --db-cluster-identifier docdb-2025-03-27-19-21-15 \ --new-db-cluster-identifier docdb-2025-03-27-19-21-15 \ --apply-immediately \ --region us-east-1

    Para Windows:

    aws docdb modify-db-cluster ^ --db-cluster-identifier docdb-2025-03-27-19-21-15 ^ --new-db-cluster-identifier docdb-2025-03-27-19-21-15 ^ --apply-immediately ^ --region us-east-1

Administración de los RPO para los clústeres globales de Amazon DocumentDB

Con un clúster global de Amazon DocumentDB, puede administrar el objetivo del punto de recuperación (RPO) mediante el parámetro. global_db_rpo El RPO representa la cantidad máxima de datos que se pueden perder en caso de interrupción.

Cuando establece un RPO para su clúster global de Amazon DocumentDB, Amazon DocumentDB monitoriza el tiempo de retraso del RPO de todos los clústeres secundarios. Esta supervisión garantiza que al menos un clúster secundario permanezca dentro del período de RPO objetivo.

La configuración del RPO controla la forma en que Amazon DocumentDB administra las transacciones de escritura en el clúster principal para limitar la posible pérdida de datos en caso de que se produzca una conmutación por error. Amazon DocumentDB evalúa los tiempos de retraso del RPO y del RPO para confirmar (o bloquear) las transacciones en el servidor principal de la siguiente manera:

  • Confirma la transacción si al menos un clúster secundario de base de datos tiene un tiempo de retraso de RPO menor que el RPO.

  • Bloquea la transacción si todos los clústeres secundarios de base de datos tienen tiempos de retraso de RPO mayores que el RPO.

En otras palabras, si todos los clústeres secundarios están por debajo del RPO objetivo, Amazon DocumentDB detiene las transacciones en el clúster principal. Amazon DocumentDB reanuda y confirma las transacciones pausadas tan pronto como el retraso de al menos un clúster de base de datos secundario cae por debajo del RPO. El resultado es que ninguna transacción se puede confirmar hasta que se cumpla el RPO.

El parámetro global_db_rpo es dinámico. Si decide que no quiere que todas las transacciones de escritura se detengan hasta que el retraso disminuya lo suficiente, puede restablecerlo rápidamente. En este caso, Amazon DocumentDB aplica el cambio tras un breve retraso.

importante

En una base de datos global con solo dos AWS regiones, recomendamos mantener el valor predeterminado del global_db_rpo parámetro en el grupo de parámetros de la región secundaria. De lo contrario, realizar una conmutación por error debido a la pérdida de la AWS región principal podría provocar que Amazon DocumentDB pausara las transacciones. En su lugar, espere a que Amazon DocumentDB termine de reconstruir el clúster en la antigua AWS región donde se produjo el error antes de cambiar este parámetro para imponer un RPO máximo.

Establecimiento del objetivo de punto de recuperación

El global_db_rpo parámetro controla la configuración del RPO de una base de datos de Amazon DocumentDB. Los valores válidos oscilan entre 20 segundos y 2.147.483.647 segundos (68 años). Elija un valor realista para satisfacer las necesidades de su empresa. Por ejemplo, es posible que desee permitir hasta 10 minutos para su RPO, en cuyo caso establece el valor en 600.

Puede establecer este valor para su clúster global de Amazon DocumentDB mediante la API Consola de administración de AWS, la API o la AWS CLI API de Amazon DocumentDB.

Using the Consola de administración de AWS
Para establecer el RPO
  1. Inicie sesión en y abra la Consola de administración de AWS consola de Amazon DocumentDB en. https://console.aws.amazon.com/docdb

  2. Elija el clúster principal de su clúster global de Amazon DocumentDB y abra la pestaña Configuración para buscar el grupo de parámetros del clúster de base de datos correspondiente.

    Los grupos de parámetros no se pueden editar directamente. En su lugar, puede hacer lo siguiente:

    • Cree un grupo de parámetros de clúster de base de datos personalizado con el grupo de parámetros predeterminado apropiado como punto de partida.

    • En su grupo de parámetros de clúster de base de datos personalizado, defina el valor del parámetro global_db_rpo para adaptarlo a su caso de uso. Los valores válidos van desde 20 segundos hasta el valor entero máximo de 2 147 483 647 (68 años).

    • Aplique el grupo de parámetros del clúster de base de datos modificado a su clúster de base de datos de Amazon DocumentDB.

Para obtener más información sobre la modificación de los grupos de parámetros del clúster de base de datos, consulteModificación de grupos de parámetros de clúster de Amazon DocumentDB.

Using the AWS CLI

Para establecer el parámetro global_db_rpo, utilice el comando de CLI modify-db-cluster-parameter-group. En el comando, especifique el nombre del grupo de parámetros del clúster principal y los valores del parámetro RPO.

En el ejemplo siguiente se establece el RPO en 600 segundos (10 minutos) para el grupo de parámetros de clúster principal de base de datos denominado my_custom_global_parameter_group.

Para Linux, macOS o Unix:

aws docdb modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --parameters "ParameterName=global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Para Windows:

aws docdb modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --parameters "ParameterName=global_db_rpo,ParameterValue=600,ApplyMethod=immediate"
Using the Amazon DocumentDB API

Para modificar el global_db_rpo parámetro, usa la operación de la ModifyDBClusterParameterGroup API.

Visualización del objetivo de punto de recuperación

El objetivo de punto de recuperación (RPO) de un clúster global se almacena en el global_db_rpo parámetro de cada clúster de base de datos.

Puede usar la CLI para ver el global_db_rpo parámetro de un clúster de base de datos de Amazon DocumentDB. Utilice la --query opción para devolver solo el global_db_rpo parámetro del grupo de parámetros.

Para Linux, macOS o Unix:

aws docdb describe-db-cluster-parameters \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --query "Parameters[?ParameterName=='global_db_rpo']"

Para Windows:

aws docdb describe-db-cluster-parameters ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --query "Parameters[?ParameterName=='global_db_rpo']"

El comando devuelve un resultado similar al siguiente.

[ { "ParameterName": "global_db_rpo", "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.", "Source": "engine-default", "ApplyType": "dynamic", "DataType": "integer", "AllowedValues": "20-2147483647", "IsModifiable": true, "ApplyMethod": "immediate" } ]

Para obtener más información sobre la visualización de los parámetros del grupo de parámetros del clúster, consulteAdministración de los grupos de parámetros de clúster de Amazon DocumentDB.

Desactivación del objetivo de punto de recuperación

Para desactivar el RPO, restablezca el parámetro global_db_rpo. Puede restablecer los parámetros mediante la API Consola de administración de AWS AWS CLI, la API o la API de Amazon DocumentDB.

Using the Consola de administración de AWS
Para deshabilitar el RPO
  1. Inicie sesión en y abra Consola de administración de AWS la consola de Amazon DocumentDB en. https://console.aws.amazon.com/docdb

  2. En el panel de navegación, seleccione Parameter groups (Grupos de parámetros).

  3. En la lista, elija el grupo de parámetros de clúster de base de datos principal.

  4. Elija el botón de opción situado junto al parámetro global_db_rpo.

  5. Seleccione Restablecer los valores predeterminados y confírmelo.

Para obtener más información sobre cómo restablecer un parámetro con la consola, consulteModificación de grupos de parámetros de clúster de Amazon DocumentDB.

Using the AWS CLI

Para restablecer el parámetro global_db_rpo, utilice el comando reset-db-cluster-parameter-group.

Para Linux, macOS o Unix:

aws docdb reset-db-cluster-parameter-group \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --parameters "ParameterName=global_db_rpo,ApplyMethod=immediate"

Para Windows:

aws docdb reset-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --parameters "ParameterName=global_db_rpo,ApplyMethod=immediate"
Using the Amazon DocumentDB API

Para restablecer el global_db_rpo parámetro, utilice la operación de la ResetDBClusterParameterGroup API.