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-0230` para 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 `AutoAppliedAfterDate` de 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` (consulte[Fechas de aplicación](#db-instance-updates-apply-date)). Las notas de la [ versión de Amazon DocumentDB ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) 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.
**Topics**
+ [Acciones de mantenimiento para Amazon DocumentDB](#maintenance-actions)
+ [Numeración de versiones del motor](#engine-version-numbering)
+ [Administración de los periodos de mantenimiento de Amazon DocumentDB](#maintenance-window)
+ [Notificaciones de parches del motor de Amazon DocumentDB](#patch-notifications)
+ [Visualización de las operaciones de mantenimiento pendientes de Amazon DocumentDB](#view-pending-maintenance)
+ [Actualizaciones del motor de Amazon DocumentDB](#db-instance-updates-apply)
+ [Actualizaciones de la versión secundaria](#minor-version-upgrades)
+ [Actualizaciones del sistema operativo de Amazon DocumentDB](#os-system-updates)
+ [User-initiated actualizaciones](#user-initiated-updates)
+ [Aplicación de parches a clústeres globales](#global-clusters-patching)
## 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](#db-instance-updates-apply).
+ `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](#os-system-updates).
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úster`os-upgrade`. Para obtener más información, consulte [Actualizaciones del sistema operativo de Amazon DocumentDB](#os-system-updates).
## 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}}.{{minor}}` (por ejemplo, `5.0.0` o). `5.0.1` Las 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.{{patch}}` (por ejemplo,`3.0.17983`) que identifica el nivel de parche aplicado al clúster. El dígito del medio es siempre`0`. 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.{{x}} | 3.6 |
| 2.0.{{x}} | 4.0 |
| 3.0.{{x}} | 5.0 |
| 4.0.{{x}} | 8.0 |
Para comprobar la versión del parche que está ejecutando su clúster, conéctese y ejecútelo`db.runCommand({getEngineVersion: 1})`.
Para ver la lista de las versiones de parches del motor publicadas y lo que contiene cada una de ellas, consulte[Notas de la versión](release-notes.md).
## 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](db-cluster-modify.md).
+ Para una instancia, consulte [Modificación de una instancia de base de datos de Amazon DocumentDB](db-instance-modify.md).
## 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 fecha`AutoAppliedAfterDate`, 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ándola`db.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 ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) 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](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html).
## 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ón`system-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. `AutoAppliedAfterDate` Una vez que pase esa fecha, la acción se aplicará automáticamente durante el siguiente período de mantenimiento. Una vez que `ForcedApplyDate` pase, 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.
------
#### [ Using the Consola de administración de AWS ]
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](https://console.aws.amazon.com/docdb).
1. En el panel de navegación, seleccione **Clusters (Clústeres)**.
1. La ** columna de ** mantenimiento del clúster muestra la ventana ** Disponible ****, ** Necesaria o ** Siguiente ** cuando hay una actualización pendiente.
1. Abra el clúster y, a continuación, seleccione ** Mantenimiento y copias de seguridad ** para ver los ** elementos ** pendientes de mantenimiento y tomar medidas al respecto.
------
#### [ Using the AWS CLI ]
Corre `describe-pending-maintenance-actions` para ver lo que está pendiente. El siguiente ejemplo muestra una cuenta sin acciones pendientes.
```
aws docdb describe-pending-maintenance-actions
```
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{
"PendingMaintenanceActions": []
}
```
Una cuenta con una acción pendiente devuelve un resultado parecido al siguiente:
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "db-version-upgrade",
"CurrentApplyDate": "2026-05-15T03:01:00Z",
"AutoAppliedAfterDate": "2026-05-15T03:01:00Z"
}
]
}
]
}
```
Puedes asignar el listado a clústeres específicos con `--filters` el formulario`Name={{filter-name}},Values={{resource-id}},...`. El filtro aceptado `Name` es `db-cluster-id` el que contiene una lista de identificadores de clústeres o ARN.
**Example**
Para Linux, macOS o Unix:
```
aws docdb describe-pending-maintenance-actions \
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
Para Windows:
```
aws docdb describe-pending-maintenance-actions ^
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
------
### 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 anterior`AutoAppliedAfterDate`. 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.
------
#### [ Using the Consola de administración de AWS ]
**Administración de la actualización de un clúster**
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](https://console.aws.amazon.com/docdb).
1. En el panel de navegación, seleccione **Clusters (Clústeres)**.
1. Seleccione el clúster que desea actualizar.
1. En el ** menú ** Acciones, elige una de las siguientes opciones:
+ **Actualice ahora**: ejecute el mantenimiento pendiente de inmediato.
+ **Actualice en la siguiente ventana**: ejecútela durante la próxima ventana de mantenimiento del clúster.
También puede utilizar la opción ** Aplicar ahora ** o ** Aplicar en la próxima ventana ** de mantenimiento desde la ** sección Mantenimiento ** pendiente de la ** pestaña ** Mantenimiento y copias de seguridad del clúster (consulte[Visualización de las operaciones de mantenimiento pendientes de Amazon DocumentDB](#view-pending-maintenance)).
**nota**
Si no hay nada pendiente, todas estas opciones están inactivas.
------
#### [ Using the AWS CLI ]
Aplica una actualización pendiente con`apply-pending-maintenance-action`.
**Parameters**
+ **--resource-identifier**—el nombre de recurso de Amazon (ARN) de Amazon DocumentDB del recurso al que se dirige la acción pendiente.
+ **--apply-action**—La acción de mantenimiento pendiente de aplicar. Se usa `system-update` para aplicar un parche al motor.
+ **--opt-in-type**: el tipo de solicitud de suscripción o si se debe deshacer una. Valores válidos:
+ `immediate`—solicítelo ahora. No se puede deshacer una vez enviado.
+ `next-maintenance`—se aplica durante la próxima ventana de mantenimiento del recurso.
+ `undo-opt-in`—cancelar una suscripción existente`next-maintenance`.
**Example**
Para Linux, macOS o Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} \
--apply-action system-update \
--opt-in-type immediate
```
Para Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} ^
--apply-action system-update ^
--opt-in-type immediate
```
------
### 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](docdb-mvu.md)
### 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 en[Notificaciones de parches del motor de Amazon DocumentDB](#patch-notifications).
## 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 ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) 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](docdb-minor-version-upgrade.md).
## 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 menor`BufferCacheHitRatio`.
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](failover.md).
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 viceversa`os-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](event-subscriptions.subscribe.md).
**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 (consulta[Actualizaciones del motor de Amazon DocumentDB](#db-instance-updates-apply)).
Usa el Consola de administración de AWS o AWS CLI para comprobar si hay una actualización disponible.
------
#### [ Using the Consola de administración de AWS ]
Para comprobar si hay una actualización del sistema operativo desde la consola:
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](https://console.aws.amazon.com/docdb).
1. En el panel de navegación, elija ** Clústeres ** y, a continuación, seleccione el nombre del clúster.
1. Selecciona la ** pestaña ** Mantenimiento y copias de seguridad.
1. En Mantenimiento ** pendiente**, la `os-upgrade` acción aparece si hay una actualización del sistema operativo disponible.
1. Seleccione la `os-upgrade` acción y elija ** Aplicar ahora ** o ** Aplicar en la próxima ventana de mantenimiento. ** Si el valor es la ** siguiente ventana**, puedes ** aplazar la actualización ** mientras la acción no se haya iniciado.
------
#### [ Using the AWS CLI ]
Comprueba si hay una actualización pendiente del sistema operativo:
```
aws docdb describe-pending-maintenance-actions
```
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "os-upgrade",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-2",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
Las actualizaciones del sistema operativo aparecen a nivel de clúster como `os-upgrade` y a nivel de instancia como`system-update`. Utilice la acción a nivel de clúster`os-upgrade`.
**Example**
En el siguiente ejemplo, se aplica la actualización del sistema operativo de forma inmediata.
Para Linux, macOS o Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} \
--apply-action os-upgrade \
--opt-in-type immediate
```
Para Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} ^
--apply-action os-upgrade ^
--opt-in-type immediate
```
------
## 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:
+ [Modificación de un clúster de Amazon DocumentDB](db-cluster-modify.md)
+ [Modificación de una instancia de base de datos de Amazon DocumentDB](db-instance-modify.md)
Para enumerar los cambios iniciados por el usuario que aún están pendientes:
**Example**
**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 en`db.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 ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) 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.