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.
Mantenimiento de Amazon DocumentDB
Amazon DocumentDB realiza periódicamente dos tipos de mantenimiento:
-
El mantenimiento del clúster actualiza el motor de la base de datos. Las actualizaciones del motor incluyen correcciones de seguridad, correcciones de errores, nuevas funciones y otras mejoras del motor.
-
El mantenimiento de la instancia actualiza el sistema operativo (SO) de la instancia.
Los parches del motor y las actualizaciones del sistema operativo utilizan las mismas tres categorías de ciclo de vida (opcionales , obligatorias y forzadas) con el mismo comportamiento de notificación y aplicación para cada categoría. Las versiones del motor también tienen una cuarta categoría: las versiones secundarias, a las que se actualizan manualmente. Las categorías son:
-
Opcional: contiene mejoras no críticas. Sin fecha de solicitud automática ni notificación de AHD; solicítela cuando le convenga. (Para las actualizaciones del sistema operativo, puedes suscribirte
RDS-EVENT-0230para recibir una notificación cuando haya una disponible). -
Obligatorio: contiene correcciones de seguridad y otras soluciones críticas. Recibirá una notificación a través del Panel de estado (AHD) y por correo electrónico. Una acción obligatoria se aplica automáticamente durante el período de mantenimiento del clúster o instancia, una vez finalizado el período
AutoAppliedAfterDatede mantenimiento. Puedes aplazarla cambiando la ventana de mantenimiento antes de esa fecha. -
Forzado: una solución poco frecuente y muy crítica. Auto-applies fuera de su período de mantenimiento una vez finalizado
ForcedApplyDate. Amazon DocumentDB solo designa una acción forzada cuando no hay otra opción disponible. -
Versión secundaria (solo versiones del motor): una versión del motor numerada encima de la versión principal (por ejemplo,
5.0.1). User-driven: se actualiza modificando la versión del motor del clúster. Nunca se aplica automáticamente; no hay notificación de AHD. Las versiones secundarias no se publican para las versiones principales anteriores a la 5.0.
Los parches del motor se publican en una sola categoría (opcional, obligatoria o obligatoria) y permanecen allí. Las actualizaciones del sistema operativo avanzan: la mayoría comienzan como opcionales y, si no se aplican, pasan a ser obligatorias y, finalmente, forzadas. La fecha exacta depende del parche y se publica en la notificación de AHD y en los campos de fecha devueltos por describe-pending-maintenance-actions (consulteFechas de aplicación). Las notas de la versión de Amazon DocumentDB utilizan estos nombres de categoría al anunciar cambios en el motor.
Al aplicar cualquier parche al motor, el clúster se desconecta brevemente. El resto de este tema explica cómo funcionan las ventanas de mantenimiento, cómo encontrar el trabajo pendiente, cómo aplicar los parches del motor y las versiones secundarias, cómo funcionan las actualizaciones del sistema operativo y cómo tratar los clústeres globales.
Temas
Acciones de mantenimiento para Amazon DocumentDB
Las siguientes acciones de mantenimiento se aplican a los clústeres de Amazon DocumentDB:
-
system-update— Actualice el parche del motor para el clúster de Amazon DocumentDB. Para obtener más información, consulte Actualizaciones del motor de Amazon DocumentDB. -
os-upgrade— Actualice los sistemas operativos de todas las instancias de base de datos del clúster de Amazon DocumentDB mediante actualizaciones sucesivas. Para obtener más información, consulte Actualizaciones del sistema operativo de Amazon DocumentDB.
Las siguientes acciones de mantenimiento se aplican a las instancias de Amazon DocumentDB:
-
system-update— Actualice el sistema operativo de la instancia de Amazon DocumentDB. En su lugar, le recomendamos que utilice la acción de mantenimiento a nivel de clústeros-upgrade. Para obtener más información, consulte Actualizaciones del sistema operativo de Amazon DocumentDB.
Numeración de versiones del motor
Amazon DocumentDB usa dos identificadores de versión independientes:
-
Versión del motor: un número de tres partes en el formulario
major.major.minor5.0.0o).5.0.1Las dos primeras partes (5.0) son la versión compatible con MongoDB; la tercera parte es la versión secundaria, que se incrementa cuando Amazon DocumentDB publica una versión secundaria que contiene correcciones de errores y mejoras importantes. Esta es la versión que especifica al crear o actualizar un clúster. -
Versión del parche del motor: un número independiente de tres partes en el formulario
major.0.patch3.0.17983) que identifica el nivel de parche aplicado al clúster. El dígito del medio es siempre0. Las versiones de parches contienen correcciones críticas de seguridad y estabilidad.
Puede determinar la versión del motor a partir del prefijo de la versión del parche del motor, como se muestra en la tabla siguiente.
| Prefijo de la versión del parche del motor | Versión del motor de Amazon DocumentDB |
|---|---|
1.0. |
3.6 |
2.0. |
4.0 |
3.0. |
5.0 |
4.0. |
8.0 |
Para comprobar la versión del parche que está ejecutando su clúster, conéctese y ejecútelodb.runCommand({getEngineVersion: 1}).
Para ver la lista de las versiones de parches del motor publicadas y lo que contiene cada una de ellas, consulteNotas de la versión.
Administración de los periodos de mantenimiento de Amazon DocumentDB
Cada clúster y cada instancia tienen su propio período de mantenimiento semanal de 30 minutos, es decir, el período en el que se ejecutan las modificaciones programadas y los parches de software. La mayoría de los eventos se completan en 30 minutos; los más grandes pueden durar más tiempo.
Si no elige una ventana al crear el recurso, Amazon DocumentDB asigna una de forma aleatoria dentro de un bloque diario de 8 horas definido para la región, en un día seleccionado al azar. Elija ventanas que minimicen el impacto en su aplicación, por ejemplo, por la noche o los fines de semana.
Para las actualizaciones de los motores de bases de datos, Amazon DocumentDB utiliza la ventana del clúster, no las ventanas de las instancias individuales.
La siguiente tabla muestra los bloques de tiempo predeterminados por región.
| Nombre de la región | Region | Bloque de tiempo en UTC |
|---|---|---|
| Este de EE. UU. (Ohio) | us-east-2 | 03:00-11:00 |
| Este de EE. UU. (Norte de Virginia) | us-east-1 | 03:00-11:00 |
| Oeste de EE. UU. (Oregón) | us-west-2 | 06:00-14:00 |
| África (Ciudad del Cabo) | af-south-1 | 03:00-11:00 |
| Asia Pacífico (Hong Kong) | ap-east-1 | 06:00-14:00 |
| Asia-Pacífico (Hyderabad) | ap-south-2 | 06:30–14:30 |
| Asia-Pacífico (Malasia) | ap-southeast-5 | 13:00-21:00 |
| Asia-Pacífico (Mumbai) | ap-south-1 | 06:00-14:00 |
| Asia-Pacífico (Osaka) | ap-northeast-3 | 12:00–20:00 |
| Asia-Pacífico (Seúl) | ap-northeast-2 | 13:00-21:00 |
| Asia-Pacífico (Singapur) | ap-southeast-1 | 14:00–22:00 |
| Asia-Pacífico (Sídney) | ap-southeast-2 | 12:00–20:00 |
| Asia-Pacífico (Yakarta) | ap-southeast-3 | De 08:00 a 16:00 |
| Asia-Pacífico (Melbourne) | ap-southeast-4 | 11:00-19:00 |
| Asia-Pacífico (Tailandia) | ap-southeast-7 | 15:00-23:00 |
| Asia-Pacífico (Tokio) | ap-northeast-1 | 13:00-21:00 |
| Canadá (centro) | ca-central-1 | 03:00-11:00 |
| Oeste de Canadá (Calgary) | ca-west-1 | 18:00-02:00 |
| China (Pekín) | cn-north-1 | 06:00-14:00 |
| China (Ningxia) | cn-northwest-1 | 06:00-14:00 |
| Europa (Fráncfort) | eu-central-1 | 21:00-05:00 |
| Europa (Zúrich) | eu-central-2 | 02:00-10:00 |
| Europa (Irlanda) | eu-west-1 | 22:00-06:00 |
| Europa (Londres) | eu-west-2 | 22:00-06:00 |
| Europa (Milán) | eu-south-1 | 02:00-10:00 |
| Europa (París) | eu-west-3 | 23:59-07:29 |
| Europa (España) | eu-south-2 | 02:00-10:00 |
| Europa (Estocolmo) | eu-north-1 | 04:00 — 12:00 |
| México (centro) | mx-central-1 | 03:00-11:00 |
| Medio Oriente (EAU) | me-central-1 | 05:00-13:00 |
| América del Sur (São Paulo) | sa-east-1 | 00:00-08:00 |
| Israel (Tel Aviv) | il-central-1 | 04:00-12:00 |
| AWS GovCloud (US-East) | us-gov-east-1 | 17:00-01:00 |
| AWS GovCloud (US-West) | us-gov-west-1 | 06:00-14:00 |
Cambio de los periodos de mantenimiento de Amazon DocumentDB
Elige la ventana con el tráfico más bajo que puedas y ajústala con el tiempo a medida que cambien tus patrones de tráfico. El clúster o la instancia no estarán disponibles durante ese período solo si un cambio de sistema (una operación de almacenamiento a escala o un cambio de clase de instancia, por ejemplo) requiere una interrupción y solo durante el tiempo que ese cambio sea realmente necesario.
Para cambiar el periodo de mantenimiento
-
Para un clúster, consulte Modificación de un clúster de Amazon DocumentDB.
-
Para una instancia, consulte Modificación de una instancia de base de datos de Amazon DocumentDB.
Notificaciones de parches del motor de Amazon DocumentDB
Cuando el parche de motor necesario está disponible en una AWS región, todas las AWS cuentas que tengan un clúster de Amazon DocumentDB afectado en esa región reciben una notificación a través del Panel de estado (AHD) y por correo electrónico (que se envía a la dirección del usuario raíz de la AWS cuenta). Se envía una notificación por cada versión del motor de Amazon DocumentDB afectada. Puede encontrarlas en la sección Cambios programados del AHD. Cada notificación muestra el calendario de disponibilidad de los parches, el calendario de aplicación automática, los clústeres afectados y las notas de lanzamiento.
Los parches de motor necesarios tienen un único plazo de entrega de aproximadamente 30 días. Cuando un parche esté disponible en su región, Amazon DocumentDB envía la notificación descrita anteriormente. En ese momento, el parche AutoAppliedAfterDate estará listo aproximadamente 30 días después. Hasta esa fecha, el parche seguirá pendiente: puedes aplicarlo en cualquier momento o aplazarlo si cambias el período de mantenimiento del clúster a un día posterior. A partir de esa fechaAutoAppliedAfterDate, el parche se aplicará automáticamente durante la próxima ventana de mantenimiento del clúster.
Por ejemplo, un parche obligatorio que esté disponible el 1 de junio de 2026 caducará aproximadamente el 1 AutoAppliedAfterDate de julio de 2026. Recibirás la notificación el 1 de junio de 2026 y, si no tomas ninguna medida, el parche se aplicará automáticamente durante el primer período de mantenimiento del clúster, a partir del 1 de julio de 2026.
Tras recibir la notificación, tienes dos opciones: aplicar el parche por tu cuenta antes de la fecha de aplicación automática o esperar a que se aplique automáticamente durante el próximo período de mantenimiento (opción predeterminada). Para autoaplicarlo, abre la pestaña Mantenimiento y copias de seguridad del clúster y busca el tipo de entrada. system-update
nota
El estado de la notificación en el AHD permanece en curso hasta que Amazon DocumentDB publique otro parche del motor con una nueva versión del parche.
Una vez aplicado el parche, la versión del parche del motor del clúster se actualiza para que coincida con la versión de la notificación. Verifique la nueva versión ejecutándoladb.runCommand({getEngineVersion: 1}).
Los parches opcionales y las nuevas versiones secundarias no generan notificaciones de AHD ni por correo electrónico. Para rastrearlos, consulte las notas de la versión de Amazon DocumentDB.
Los parches obligatorios (la categoría más infrecuente, reservada para las correcciones de seguridad más críticas) también se anuncian a través de AHD y por correo electrónico. A diferencia de los parches necesarios, se aplican fuera del período de mantenimiento, por lo que el ejemplo anterior sobre el tiempo de aplicación automática no se aplica.
Reaccionar a las notificaciones de parches mediante programación
AWS Health se integra con Amazon EventBridge, lo que le permite crear aplicaciones basadas en eventos para más de 20 destinos, incluido AWS Lambda Amazon Simple Queue Service (SQS). Para reaccionar de forma programática a la disponibilidad de los parches del motor, configúrala en función del evento. EventBridge AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED Desde allí, puede capturar los datos de los eventos, generar eventos adicionales, enviar notificaciones automáticas a través del AWS Console Mobile Application o realizar cualquier otra acción que necesite.
Si Amazon DocumentDB cancela un parche (poco frecuente), recibirá una notificación de AHD y un correo electrónico sobre la cancelación. Utilice el código del AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED evento con Amazon EventBridge para gestionar este caso. Para obtener más información sobre la redacción de reglas, consulta la Guía del EventBridge usuario de Amazon.
Visualización de las operaciones de mantenimiento pendientes de Amazon DocumentDB
Usa el Consola de administración de AWS o el AWS CLI para comprobar qué mantenimiento está pendiente para un clúster o una instancia.
Las actualizaciones pendientes aparecen con el tipo de acciónsystem-update, que abarca tanto los parches del motor como las actualizaciones del sistema operativo.
Cuando hay una actualización pendiente, puedes:
-
Aplícala de inmediato.
-
Prográmela para la próxima ventana de mantenimiento.
-
Aplazarlo (solo parches del motor y actualizaciones del sistema operativo) cambiando previamente el período de mantenimiento.
AutoAppliedAfterDateUna vez que pase esa fecha, la acción se aplicará automáticamente durante el siguiente período de mantenimiento. Una vez queForcedApplyDatepase, no es posible ningún otro aplazamiento.
nota
Si no realizas ninguna acción, las medidas de mantenimiento necesarias, como los parches necesarios para el motor, se aplicarán automáticamente durante el próximo período de mantenimiento. Los parches opcionales y las versiones secundarias nunca se aplican automáticamente.
La ventana de mantenimiento controla cuándo se inician las operaciones pendientes, no cuánto tardan en completarse.
Fechas de aplicación
Cada acción de mantenimiento pendiente tiene hasta tres fechas de aplicación. Aparecen en el AWS CLI resultado describe-pending-maintenance-actions e indican cuándo se ejecutará la acción. Los campos son null para mantenimiento opcional.
-
CurrentApplyDate—cuando la acción esté programada para ejecutarse, ya sea ahora o en la próxima ventana de mantenimiento. Se rellena para las acciones obligatorias y forzadas. -
AutoAppliedAfterDate: la fecha a partir de la cual comienza la aplicación automática durante el período de mantenimiento del clúster o la instancia. Se rellena para indicar las acciones necesarias. -
ForcedApplyDate—la fecha límite fija. Después de esta fecha, la acción se ejecuta automáticamente, independientemente del período de mantenimiento. Se rellena para acciones forzadas.
Para aplazar una acción pendiente, traslade el período de mantenimiento a otro día anteriorAutoAppliedAfterDate. Una vez AutoAppliedAfterDate aprobada, la acción se aplicará automáticamente durante el siguiente período de mantenimiento. Una vez ForcedApplyDate aprobada, no es posible ningún otro aplazamiento. El período exacto de aplazamiento varía según el parche; las fechas se publican en la notificación de AHD y en el AWS CLI resultado.
Actualizaciones del motor de Amazon DocumentDB
Cuando haya identificado un parche de motor pendiente, utilice uno de los siguientes procedimientos para aplicarlo o programarlo. Puede ejecutar estos procedimientos desde Consola de administración de AWS o desde AWS CLI.
Consulta la disponibilidad durante la aplicación de parches
Los motores 5.0 y 8.0 de Amazon DocumentDB conservan la disponibilidad de lectura durante la aplicación de parches cuando el clúster tiene varias instancias. Amazon DocumentDB parchea las instancias de los lectores de forma continua, dividiéndolas en tres grupos, de modo que los lectores restantes sigan distribuyendo el tráfico. El escritor no estará disponible durante un breve período mientras aplica los parches. Para lograr un tiempo de inactividad cero, defina sus preferencias de lectura de forma que la lectura recaiga en el escritor: secondaryPreferred o primaryPreferred trabajar; primary o secondary por sí sola, puede provocar un tiempo de inactividad.
| Modo de preferencia de lectura | Durante la actualización del escritor | Durante la actualización del lector | Se necesita una cantidad mínima de lectores para que no haya ningún tiempo de inactividad en la lectura |
|---|---|---|---|
primary |
Read/write tiempo de inactividad | Sin impacto | N/A |
primaryPreferred |
Tiempo de inactividad de escritura | Sin impacto | 1 |
secondary |
Tiempo de inactividad de escritura | Tiempo de inactividad de lectura (si solo hay un lector) | 2 |
secondaryPreferred |
Tiempo de inactividad de escritura | Sin impacto | 1 |
nearest |
Tiempo de inactividad de escritura | Sin impacto | 1 |
Mientras los lectores aplican los parches, el rendimiento general de lectura del clúster disminuye temporalmente. Para mantener un rendimiento estable, aprovisione lectores adicionales antes de la actualización y elimínelos una vez finalizada.
En los motores 3.6 y 4.0, estas funciones de disponibilidad de lectura no se aplican: un parche del motor provoca un tiempo de inactividad más prolongado, lo que afecta tanto a la lectura como a la escritura. Para actualizar a una versión principal que sí lo haga, consulte. Actualización local de la versión principal Amazon DocumentDB
Duración del tiempo de inactividad del parche
Engine-patch el tiempo de inactividad varía. Los factores más importantes son el uso de la CPU y la presión sobre la memoria de la instancia en el momento de la aplicación del parche, por lo que es importante ajustar el tamaño de las instancias. Para minimizar el tiempo de inactividad, ejecute la versión más reciente del motor principal de Amazon DocumentDB y distribuya las instancias en varias zonas de disponibilidad.
Actualizaciones y reemplazos de parches
Amazon DocumentDB monitoriza los parches después de su lanzamiento. En el raro caso de que se identifique un problema, Amazon DocumentDB detiene la implementación mientras prepara una versión actualizada. Cuando esto ocurre, los clústeres que aún no han recibido el parche dejan de considerarlo una acción de mantenimiento disponible y se retira la correspondiente notificación de cambio programado que aparece en el. Panel de estado Los clústeres que ya ejecutan la versión afectada siguen funcionando con normalidad y no requieren ninguna acción por tu parte.
En breve recibirá un parche actualizado. Cuando esté disponible en su región, recibirá una nueva notificación por correo electrónico, tal Panel de estado y como se describe enNotificaciones de parches del motor de Amazon DocumentDB.
Actualizaciones de la versión secundaria
Amazon DocumentDB publica versiones secundarias además de la versión principal 5.0 y posteriores (por ejemplo,5.0.1). Las versiones secundarias no se publican para las versiones principales anteriores a la 5.0. Las versiones secundarias se comportan de manera diferente a los parches de motor obligatorios y opcionales:
-
No aparecen como una acción de mantenimiento pendiente y nunca se aplican automáticamente.
-
No generan notificaciones AHD ni por correo electrónico. Las nuevas versiones secundarias se anuncian en las notas de lanzamiento de Amazon DocumentDB.
-
Para realizar la actualización, modifique la versión del motor del clúster (inmediatamente o durante el siguiente período de mantenimiento). Las actualizaciones de versiones secundarias requieren un breve tiempo de inactividad y son unidireccionales; no se puede cambiar a una versión secundaria anterior. En el caso de los clústeres globales, actualiza los clústeres secundarios antes que los principales.
Leer más:Actualización de la versión secundaria de Amazon DocumentDB.
Actualizaciones del sistema operativo de Amazon DocumentDB
Ocasionalmente, las instancias necesitan actualizaciones del sistema operativo. Amazon DocumentDB actualiza el sistema operativo para mejorar el rendimiento y reforzar la seguridad. Las actualizaciones del sistema operativo no modifican la versión del motor del clúster ni la clase de instancia. Al igual que los parches del motor, las actualizaciones del sistema operativo utilizan el ciclo de vida opcional, obligatorio o forzado que se describe al principio de este tema; a diferencia de los parches del motor, una actualización del sistema operativo puede pasar de una categoría a otra con el tiempo si se aplaza. Aplica las actualizaciones del sistema operativo tan pronto como estén disponibles y configura los periodos de mantenimiento de los clústeres e instancias según las necesidades de tu empresa.
Usa la acción de os-upgrade mantenimiento a nivel de clúster para aplicar las actualizaciones del sistema operativo en todas las instancias de un clúster. Amazon DocumentDB actualiza las instancias de forma continua, unas cuantas a la vez, y actualiza la instancia principal en último lugar para minimizar las conmutaciones por error. La actualización se ejecuta durante el período de mantenimiento del clúster (no durante el período de mantenimiento de las instancias individuales) que usted configure.
Cuando una instancia recibe una actualización del sistema operativo, su caché de búfer comienza a vaciarse. Hasta que el conjunto de trabajo no se rellene desde el volumen de almacenamiento, las consultas de esa instancia pueden experimentar una latencia mayor y menorBufferCacheHitRatio.
Cuando Amazon DocumentDB actualiza la instancia principal, una conmutación por error hace que una réplica pase a ser la nueva instancia principal. Utilice el punto de enlace del clúster para que la aplicación gestione esta situación de forma transparente. Para mantener la disponibilidad de lectura mientras se actualizan las instancias, defina su preferencia de lectura para secondaryPreferred primaryPreferred que las lecturas se basen en una instancia disponible. Mantén los posibles objetivos de conmutación por error (réplicas con el nivel de prioridad más alto) en la misma clase de instancia que la instancia principal. Esto evita la degradación del rendimiento de escritura después de la promoción. Para obtener más información, consulte Conmutación por error de Amazon DocumentDB.
Tanto las acciones a nivel de clúster como a nivel os-upgrade de instancia pueden aparecer simultáneamente como system-update acciones disponibles. describe-pending-maintenance-actions Sin embargo, no puede programar ambas al mismo tiempo. Si system-update las acciones a nivel de instancia están programadas activamente en cualquier instancia, debes cancelarlas o completarlas antes de programar la acción a nivel de clúster, y viceversaos-upgrade.
importante
Su instancia de Amazon DocumentDB se desconecta para actualizar el sistema operativo. Multi-instance los clústeres minimizan el impacto. Si ejecutas un clúster de una sola instancia, puedes agregar temporalmente un secundario para la actualización y eliminarlo después. El secundario incurre en los cargos habituales mientras exista.
nota
La system-update acción a nivel de instancia sigue disponible por motivos de compatibilidad con versiones anteriores. Si tiene que usarla, actualice primero las réplicas y al final la principal; evite aplicarles parches simultáneamente, ya que la conmutación por error durante el parche puede prolongar el tiempo de inactividad.
Para recibir un evento cuando llegue una nueva actualización opcional del sistema operativo, suscríbase a la categoría de eventos de aplicación de parches de RDS-EVENT-0230 seguridad. Para obtener más información, consulte Suscripción a eventos de Amazon DocumentDB.
nota
Es posible que sea necesario mantenerse al día con las actualizaciones opcionales y obligatorias para garantizar el cumplimiento. Aplica os-upgrade acciones de forma rutinaria durante los períodos de mantenimiento.
Las actualizaciones del sistema operativo están vinculadas a clases de instancias específicas, por lo que diferentes instancias son aptas en momentos distintos. Si tu clúster no incluye el parche de motor más reciente, es posible que la actualización del sistema operativo no aparezca. Aplica primero el último parche del motor (consultaActualizaciones del motor de Amazon DocumentDB).
Usa el Consola de administración de AWS o AWS CLI para comprobar si hay una actualización disponible.
User-initiated actualizaciones
Algunos cambios los inicias tú mismo, por ejemplo, cambiar una clase de instancia por una con más o menos memoria o cambiar el grupo de parámetros del clúster. Amazon DocumentDB los trata de manera diferente a las actualizaciones que inicia. Para obtener más información, consulte:
Para enumerar los cambios iniciados por el usuario que aún están pendientes:
ejemplo
Para enumerar los cambios pendientes iniciados por el usuario para tus instancias
Para Linux, macOS o Unix:
aws docdb describe-db-instances \ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
Para Windows:
aws docdb describe-db-instances ^ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
En este ejemplo, sample-cluster-instance tiene un cambio pendiente endb.r5.xlarge; no sample-cluster-instance-2 tiene ninguno.
[
[
"sample-cluster",
"sample-cluster-instance",
{
"DBInstanceClass": "db.r5.xlarge"
}
],
[
"sample-cluster",
"sample-cluster-instance-2",
{}
]
]Aplicación de parches a clústeres globales
En un clúster global, cada clúster miembro (principal y secundario) se actualiza durante su propio período de mantenimiento. Cuando el parche de motor necesario esté disponible en cada región, recibirá una notificación por correo electrónico y de AHD. Los parches opcionales y las nuevas versiones secundarias no generan notificaciones; consulte las notas de la versión de Amazon DocumentDB para obtener información al respecto.
Si se aplica por sí mismo, aplique siempre parches primero a los secundarios y al final al primario. Este orden mantiene la conmutación por error y la conmutación disponibles durante toda la implementación.
importante
Si primero parcheas la versión principal por error, actualiza todas las versiones secundarias a la misma versión lo antes posible. La conmutación por error y la conmutación permanecen deshabilitadas hasta que todos los clústeres estén en la misma versión.
Si no realiza ninguna acción, el parche se aplica automáticamente durante el siguiente período de mantenimiento de cada clúster: primero los secundarios y luego el principal en su ventana una vez que los secundarios hayan terminado.
Mantenga los clústeres de bases de datos principales y secundarios en la misma versión. La conmutación por error gestionada entre regiones solo funciona en una base de datos global cuando todos los clústeres comparten la misma versión del motor y el mismo nivel de parche. Lo mismo ocurre si agregas una nueva versión del motor secundaria que usa una versión del motor más reciente que la principal: crea nuevas secundarias en la versión principal antes de unirlas a la base de datos global.
Tras recibir la notificación de un parche, actualice la versión principal y secundaria a la versión más reciente lo antes posible para que la conmutación por error y la conmutación sigan funcionando. Si se rechaza una solicitud de conmutación por error o conmutación, compare las versiones de los parches del motor en los distintos clústeres; si no coinciden, aplique el parche disponible en los clústeres que no coincidan.
