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 del clúster de base de datos de Amazon Neptune
Neptune realiza un mantenimiento periódico de todos los recursos que utiliza, incluidos:
+ **Sustitución del hardware subyacente según sea necesario.** Esto ocurre en segundo plano, sin que tenga que realizar ninguna acción y, por lo general, no afecta a sus operaciones.
+ **Actualización del sistema operativo subyacente.** Las actualizaciones del sistema operativo de las instancias del clúster de base de datos se llevan a cabo para mejorar el rendimiento y la seguridad, por lo que, en general, debe completarlas lo antes posible. Normalmente, las actualizaciones tardan unos 10 minutos en completarse. Las actualizaciones del sistema operativo no cambian la versión del motor de la base de datos ni la clase de instancia de la base de datos.
Normalmente, es mejor actualizar primero las instancias de lector en un clúster de base de datos y, posteriormente, la instancia de escritor. La actualización simultánea de los lectores y del escritor puede provocar un tiempo de inactividad en caso de una conmutación por error. Tenga en cuenta que no se realiza una copia de seguridad de forma automática de las instancias de base de datos antes de una actualización del sistema operativo, así que asegúrese de realizar copias de seguridad manuales antes de aplicar una actualización del sistema operativo.
+ **Actualización del motor de base de datos de Neptune.** Neptune publica periódicamente una serie de actualizaciones del motor para introducir nuevas características y mejoras y corregir errores.
## Números de la versión del motor
### Numeración de versiones antes de la versión 1.3.0.0 del motor
Antes de noviembre de 2019, Neptune solo admitía una versión de motor a la vez y todos los números de versión de motor tenían el formato `1.0.1.0.200`, donde `xxx` era el número de parche. Todas las nuevas versiones de motor se publicaron como parches de las versiones anteriores.
A partir de noviembre de 2019, Neptune empezó a admitir varias versiones, lo que permite a los clientes un mejor control sobre sus rutas de actualización. Como resultado, la numeración de las versiones de motor ha cambiado.
Desde noviembre de 2019 hasta la [versión 1.3.0.0 del motor](engine-releases-1.3.0.0.md), los números de versión del motor constaban de 5 partes. Tome como ejemplo el número de versión `1.0.2.0.R2`:
+ La primera parte siempre era 1.
+ La segunda parte, `0` en `1.0.2.0.R2`), era el número de versión principal de la base de datos.
+ La tercera y la cuarta parte, `2.0` en `1.0.2.0.R2`), eran números de versión secundarios.
+ La quinta parte (`R2` en `1.0.2.0.R2`) era el número de parche.
La mayoría de las actualizaciones eran actualizaciones de parches, y la distinción entre parches y actualizaciones de versiones secundarias no siempre estaba clara.
### Numeración de versiones a partir de la versión 1.3.0.0 del motor
A partir de la [versión 1.3.0.0 del motor](engine-releases-1.3.0.0.md), Neptune cambió la forma en que se numeran y gestionan las actualizaciones del motor.
Los números de versión del motor ahora tienen cuatro partes, cada una de las cuales corresponde a un tipo de versión, como se indica a continuación:
*product-version***.***major-version***.***minor-version***.***patch-version*
Los cambios de no separación, que antes se publicaban como parches, ahora se publican como versiones secundarias que se pueden gestionar mediante la configuración de la instancia [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu).
Esto significa que, si lo desea, puede recibir una notificación cada vez que se publique una nueva versión secundaria suscribiéndose al evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Suscripción a la notificación de eventos de Neptune](events-subscribing.md)).
Las versiones de los parches ahora están reservadas para correcciones urgentes seleccionadas, y se numeran utilizando la última parte del número de versión (`*.*.*.1`, `*.*.*.2`, etc.).
# Diferentes tipos de versiones de motor en Amazon Neptune
Los cuatro tipos de versión del motor que corresponden a las cuatro partes del número de versión del motor son los siguientes:
+ **Versión del producto**: solo cambia si el producto sufre cambios radicales y fundamentales en la funcionalidad o la interfaz. La versión actual del producto Neptune es 1.
+ [**Versión principal**](#major-versions): las versiones principales introducen nuevas características y cambios importantes y, por lo general, tienen una vida útil de al menos dos años.
+ [**Versión secundaria**](#minor-versions): las versiones secundarias pueden contener nuevas características, mejoras y correcciones de errores, pero no contienen cambios importantes. Puede elegir si desea que se apliquen automáticamente o no durante el siguiente período de mantenimiento, y también puede optar por recibir una notificación cada vez que se publique una.
+ [**Versión de parche**](#patch-version-updates): las versiones de parche se publican únicamente para corregir errores urgentes o realizar actualizaciones de seguridad críticas. Rara vez contienen cambios importantes y se aplican automáticamente durante el siguiente período de mantenimiento tras su publicación.
## Actualizaciones de las versiones principales de Amazon Neptune
Por lo general, una actualización de una versión principal introduce una o varias características nuevas importantes y, a menudo, contiene cambios bruscos. Por lo general, tiene una vida útil de soporte de alrededor de dos años. Las versiones principales de Neptune se indican en las [versiones del motor](engine-releases.md), junto con la fecha en que se publicaron y su fecha estimada de fin de vida útil.
Las actualizaciones de las versiones principales son totalmente opcionales hasta que la versión principal que esté utilizando llegue al final de su vida útil. Si decide actualizar a una nueva versión principal, debe instalar la nueva versión usted mismo utilizando la consola Neptune AWS CLI o la consola Neptune, tal y como se describe en. [Actualizaciones de la versión principal](engine-updates-manually.md)
No obstante, si la versión principal que está utilizando llega al final de su vida útil, se le notificará que debe actualizar a una versión principal más reciente. A continuación, si no realiza la actualización dentro de un período de gracia tras la notificación, se programará automáticamente una actualización a la versión principal más reciente durante el siguiente período de mantenimiento. Para obtener más información, consulte [Vida útil de la versión del motor](engine-updates-eol-planning.md).
## Actualizaciones de versiones secundarias de Amazon Neptune
La mayoría de las actualizaciones del motor de Neptune son actualizaciones de versiones secundarias. Se producen con bastante frecuencia y no contienen cambios importantes.
Si el campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) está establecido en `true` en la instancia de escritura (principal) del clúster de base de datos, las actualizaciones de las versiones secundarias se aplicarán automáticamente a todas las instancias del clúster de base de datos durante el siguiente período de mantenimiento tras su publicación.
Si el campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) está establecido en `false` en la instancia de escritor de su clúster de base de datos, solo se aplicarán si [las instala de forma explícita](engine-updates-manually.md).
**nota**
Las actualizaciones de las versiones secundarias son independientes (no dependen de las actualizaciones anteriores de la misma versión principal) y acumulativas (contienen todas las características y correcciones introducidas en las actualizaciones de versiones secundarias anteriores). Esto significa que puede instalar cualquier actualización de versión secundaria independientemente de si ha instalado las anteriores o no.
Realizar un seguimiento de las publicaciones de versiones secundarias es sencillo. Para ello, suscríbase al evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Suscripción a la notificación de eventos de Neptune](events-subscribing.md)). Recibirá una notificación cada vez que se publique una nueva versión secundaria.
Además, tanto si se suscribe a las notificaciones como si no, siempre podrá [comprobar qué actualizaciones están pendientes](engine-maintenance-management.md#check-pending-updates).
## Actualizaciones de versiones de parche de Amazon Neptune
En el caso de problemas de seguridad u otros defectos graves que afecten a la fiabilidad de la instancia, Neptune implementa parches obligatorios. Se aplican a todas las instancias del clúster de base de datos durante el siguiente período de mantenimiento sin ninguna intervención por su parte.
Una versión de parche solo se implementa cuando los riesgos de no implementarla superan los riesgos y el tiempo de inactividad asociados a su implementación. Las versiones de parche tiene lugar con poca frecuencia (normalmente, una vez cada varios meses) y suele requerir tan solo una fracción del período de mantenimiento.
# Planificación de la vida útil de la versión principal del motor de Amazon Neptune
Las versiones del motor de Neptune casi siempre llegan al final de su vida útil al final de un trimestre natural. Solo se realizan excepciones cuando surgen problemas importantes de seguridad o disponibilidad.
Cuando una versión del motor llegue al final de su vida útil, tendrá que actualizar la base de datos de Neptune a una versión más reciente.
En general, las versiones del motor de Neptune siguen estando disponibles de la siguiente manera:
+ **Versiones de motor secundarias:** las versiones del motor secundarias permanecen disponibles durante al menos 6 meses después de su lanzamiento.
+ **Versiones de motor principales:** las versiones del motor principales permanecen disponibles durante al menos 6 meses después de su lanzamiento.
Al menos 3 meses antes de que la versión del motor llegue al final de su vida útil, AWS enviará una notificación automática por correo electrónico a la dirección de correo electrónico asociada a su AWS cuenta y publicará el mismo mensaje en su [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html). Esto le dará tiempo a planificar y prepararse para la actualización.
Cuando una versión del motor llegue al final de su vida útil, ya no podrá crear nuevos clústeres o instancias con esa versión. Tampoco se podrán crear instancias con esa versión mediante el escalado automático.
Una versión del motor que llegue al final de su vida útil se actualiza automáticamente durante un período de mantenimiento. El mensaje que se le envía tres meses antes del final de la vida útil de la versión de motor contiene detalles sobre lo que implica esa actualización automática, incluida la versión a la que se actualizaría automáticamente, el impacto en sus clústeres de bases de datos y las acciones que recomendamos.
**importante**
Usted es responsable de mantener actualizadas las versiones de su motor de base de datos. AWS insta a todos los clientes a actualizar sus bases de datos a la última versión del motor para poder beneficiarse de las medidas de seguridad, privacidad y disponibilidad más actuales. Si utiliza su base de datos en un motor o software no compatibles después de la fecha de caducidad (“motor heredado”), es probable que corra riesgos operativos, de seguridad y de privacidad, lo que incluye sufrir períodos de inactividad.
El funcionamiento de su base de datos en cualquier motor está sujeto al Acuerdo que rige su uso de los AWS Servicios. Los motores antiguos no están disponibles de forma general. AWS ya no es compatible con el Legacy Engine y AWS puede limitar el acceso o el uso de cualquier Legacy Engine en cualquier momento si se AWS determina que el Legacy Engine representa un riesgo de seguridad o responsabilidad, o un riesgo de daño, para los Servicios AWS, sus Filiales o cualquier tercero. Su decisión de seguir publicando su contenido en un motor heredado podría tener como consecuencia que su contenido deje de estar disponible, se dañe o sea irrecuperable. Las bases de datos que se ejecutan en un motor heredado están sujetas a las excepciones del acuerdo de nivel de servicio (SLA).
LAS BASES DE DATOS Y EL SOFTWARE RELACIONADO QUE SE EJECUTAN EN UN MOTOR ANTIGUO CONTIENEN ERRORES, DEFECTOS Y COMPONENTES AND/OR DAÑINOS. EN CONSECUENCIA, Y SIN PERJUICIO DE CUALQUIER DISPOSICIÓN EN CONTRARIO EN EL CONTRATO O EN LAS CONDICIONES DEL SERVICIO, AWS SE PROPORCIONA EL MOTOR ANTIGUO «TAL CUAL».
# Administración de las actualizaciones del motor de su clúster de base de datos de Neptune
**nota**
Las actualizaciones se aplican a todas las instancias en un clúster de base de datos simultáneamente. Una actualización requiere un reinicio de la base de datos en esas instancias, por lo que se experimentará un tiempo de inactividad que oscila entre 20-30 segundos y varios minutos, tras el cual se puede reanudar el uso del clúster de base de datos. En raras ocasiones puede ser necesaria una conmutación por error Multi-AZ para que se complete una actualización de mantenimiento en una instancia.
En el caso de las actualizaciones de las versiones principales que pueden tardar más en aplicarse, puede utilizar una [estrategia de implementación azul-verde](neptune-BG-deployments.md) para minimizar el tiempo de inactividad.
## Determinación de la versión del motor que utiliza actualmente
Puede usar el AWS CLI [`get-engine-status`](access-graph-status.md)comando para comprobar qué versión de lanzamiento del motor utiliza actualmente su clúster de base de datos:
```
aws neptunedata get-engine-status
```
La [salida de JSON](access-graph-status.md#access-graph-status-sample-output) incluye un campo `"dbEngineVersion"` como este:
```
"dbEngineVersion": "1.3.0.0",
```
## Comprobar qué actualizaciones están pendientes y disponibles
Puede comprobar las actualizaciones pendientes de su clúster de base de datos mediante la consola de Neptune. Seleccione **Bases de datos** en la columna de la izquierda y, a continuación, seleccione su clúster de base de datos en el panel de bases de datos. Las actualizaciones pendientes se muestran en la columna **Mantenimiento**. Si selecciona **Acciones** y, a continuación, **Mantenimiento**, tiene tres opciones sobre qué hacer:
+ Actualizar ahora.
+ Actualizar en el siguiente periodo.
+ Aplazar la actualización.
Puede enumerar las actualizaciones del motor pendientes de la AWS CLI siguiente manera:
```
aws neptune describe-pending-maintenance-actions \
--resource-identifier (ARN of your DB cluster)
--region (your region) \
--engine neptune
```
También puede enumerar las actualizaciones de motor disponibles de la AWS CLI siguiente manera:
```
aws neptune describe-db-engine-versions \
--region (your region) \
--engine neptune
```
La lista de versiones de motor disponibles solo incluye las versiones que tienen un número de versión superior al actual y para las que se define una ruta de actualización.
## Realice siempre una prueba antes de realizar la actualización
Cuando se publique una nueva versión principal o secundaria del motor de Neptune, pruebe siempre las aplicaciones de Neptune en ella antes de actualizar. En una actualización secundaria podría haber nuevas características o comportamientos que podrían afectar al código incluso sin ningún cambio brusco.
Comience por comparar las páginas de notas de la versión actual con las de la versión de destino para ver si hay cambios en las versiones del lenguaje de consulta u otros cambios importantes.
La mejor forma de probar una nueva versión antes de actualizar el clúster de base de datos de producción es utilizar la [solución de implementación azul/verde de Neptune](neptune-BG-deployments.md). De esta forma, puede ejecutar aplicaciones y consultas en la nueva versión sin que ello afecte a su clúster de base de datos de producción.
## Cree siempre una instantánea manual antes de realizar la actualización
Antes de realizar una actualización, se recomienda crear siempre una instantánea manual del clúster de base de datos. Una instantánea automática solo ofrece protección a corto plazo, mientras que una instantánea manual está disponible hasta que la elimine explícitamente.
En algunos casos, Neptune crea una instantánea manual para usted como parte del proceso de actualización, pero no debe confiar en eso y crear su propia instantánea manual.
Cuando tenga la seguridad de que no necesitará revertir el clúster de base de datos al estado anterior a la actualización, puede eliminar de forma explícita la instantánea manual que ha creado, así como la instantánea manual que Neptune podría haber creado. Si Neptune crea una instantánea manual, tendrá un nombre que empieza por `preupgrade`, seguido del nombre del clúster de base de datos, la versión del motor de origen, la versión del motor de destino y la fecha.
## Periodo de mantenimiento de Neptune
El período de mantenimiento semanal es un período de 30 minutos durante el cual se aplican las actualizaciones programadas del motor y otros cambios del sistema. La mayoría de los eventos de mantenimiento se completan durante el periodo de 30 minutos, aunque, en ocasiones, otros eventos de mantenimiento pueden tardar más en completarse.
Cada clúster de base de datos tiene un período de mantenimiento semanal de 30 minutos. Si no especifica una hora preferida al crear el clúster de base de datos, Neptune elige al azar un día de la semana y, a continuación, asigna al azar un período de 30 minutos dentro de un bloque de 8 horas que varía según la región.
Por ejemplo, aquí se pueden ver los bloques de tiempo de 8 horas para los períodos de mantenimiento que se utilizan en varias regiones de AWS :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/engine-maintenance-management.html)
El período de mantenimiento determina cuándo comienzan las operaciones pendientes. La mayoría de las operaciones de mantenimiento se completan dentro del período, pero las tareas de mantenimiento más grandes pueden continuar más allá de la hora de finalización del período.
### Traslado del período de mantenimiento de base de datos
Lo ideal es que el período de mantenimiento coincida con el momento de menor uso del clúster. Si ese no es el caso de su período actual, puede cambiarlo a un momento mejor, de la siguiente manera:
**Para cambiar la ventana de mantenimiento del clúster de base de datos**
1. [Inicie sesión en la consola AWS de administración y abra la consola de Amazon Neptune en https://console.aws.amazon.com/neptune/ casa.](https://console.aws.amazon.com/neptune/home)
1. En el panel de navegación, seleccione **bases** de datos.
1. Elija el clúster de base de datos cuyo periodo de mantenimiento desea cambiar.
1. Elija **Modify**.
1. Seleccione **Mostrar más** en la parte inferior de la página **Modificar el clúster**.
1. En la sección **Período de mantenimiento preferido**, defina el día, la hora y la duración del período de mantenimiento como prefiera.
1. Elija **Siguiente**.
En la página de confirmación, revise los cambios.
1. Para aplicar los cambios al periodo de mantenimiento de forma inmediata, seleccione **Apply immediately** (Aplicar inmediatamente).
1. Seleccione **Enviar** para aplicar los cambios.
Para editar los cambios elija **Atrás** o para cancelar sus cambios elija **Cancelar**.
## Se utiliza AutoMinorVersionUpgrade para controlar las actualizaciones automáticas de versiones secundarias
**importante**
`AutoMinorVersionUpgrade` solo es efectivo para las actualizaciones de versiones secundarias superiores a la [versión 1.3.0.0 del motor](engine-releases-1.3.0.0.md).
Si el campo `AutoMinorVersionUpgrade` está establecido en `true` en la instancia de escritura (principal) del clúster de base de datos, las actualizaciones de las versiones secundarias se aplicarán automáticamente a todas las instancias del clúster de base de datos durante el siguiente período de mantenimiento tras su publicación.
Si el campo `AutoMinorVersionUpgrade` está establecido en `false` en la instancia de escritor de su clúster de base de datos, solo se aplicarán si [las instala de forma explícita](engine-updates-manually.md#engine-minor-updates-using-console).
**nota**
Las versiones de parche (`*.*.*.1`, `*.*.*.2`, etc.) siempre se instalan automáticamente durante el siguiente período de mantenimiento, independientemente de cómo esté configurado el parámetro `AutoMinorVersionUpgrade`.
Puede configurarlo `AutoMinorVersionUpgrade` de la Consola de administración de AWS siguiente manera:
**Para establecer `AutoMinorVersionUpgrade` mediante la consola de Neptune**
1. [Inicie sesión en la consola AWS de administración y abra la consola de Amazon Neptune en https://console.aws.amazon.com/neptune/ casa.](https://console.aws.amazon.com/neptune/home)
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Elija la instancia principal (escritor) del clúster de base de datos para el que desea establecer `AutoMinorVersionUpgrade`.
1. Elija **Modificar**.
1. Seleccione **Mostrar más** en la parte inferior de la página **Modificar el clúster**.
1. En la parte inferior de la página ampliada, seleccione **Activar la actualización automática de versiones secundarias** o **Desactivar la actualización automática de versiones secundarias**.
1. Elija **Siguiente**.
En la página de confirmación, revise los cambios.
1. Para aplicar los cambios a la actualización automática de la versión secundaria, seleccione **Aplicar inmediatamente**.
1. Seleccione **Enviar** para aplicar los cambios.
Para editar los cambios elija **Atrás** o para cancelar sus cambios elija **Cancelar**.
También puede usar el AWS CLI para configurar el `AutoMinorVersionUpgrade` campo. Por ejemplo, para establecerlo en `true`, puede utilizar un comando como este:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --auto-minor-version-upgrade \
4. --apply-immediately
```
Del mismo modo, para establecerlo en `false`, utilice un comando como este:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --no-auto-minor-version-upgrade \
4. --apply-immediately
```
# Instalación manual de las actualizaciones del motor de Neptune
## Instalación de una actualización de versión principal del motor
Las versiones principales del motor siempre deben instalarse de forma manual. Para minimizar el tiempo de inactividad y disponer de tiempo suficiente para las pruebas y la validación, la mejor forma de instalar una nueva versión principal suele ser utilizar la [solución de implementación azul/verde de Neptune](neptune-BG-deployments.md).
En algunos casos, también puede utilizar la CloudFormation plantilla con la que creó el clúster de base de datos para instalar una actualización de la versión principal (consulte[Uso de una CloudFormation plantilla para actualizar la versión del motor de su clúster de base de datos Neptune](cfn-engine-update.md)).
Si desea instalar inmediatamente una actualización de la versión principal, puede utilizar un comando de la CLI como el siguiente:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (identifier for your neptune cluster) \
--engine neptune \
--engine-version (the new engine version) \
--apply-immediately
```
Asegúrese de especificar la versión del motor a la que desea actualizar. Si no lo hace, puede que el motor se actualice a una versión que no sea la más reciente o la que espera.
En lugar de `--apply-immediately`, puede especificar `--no-apply-immediately`.
Si el clúster utiliza un grupo de parámetros del clúster personalizado, asegúrese de especificarlo con este parámetro:
```
--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)
```
Del mismo modo, si alguna instancia del clúster utiliza un grupo de parámetros de base de datos personalizado, asegúrese de especificar este parámetro:
```
---db-instance-parameter-group-name (name of the custom instance parameter group)
```
## Instalación de una actualización del motor de una versión menor mediante el Consola de administración de AWS
**Para realizar una actualización de versión menor con la consola de Neptune**
1. [Inicie sesión en la consola AWS de administración y abra la consola de Amazon Neptune en https://console.aws.amazon.com/neptune/ casa.](https://console.aws.amazon.com/neptune/home)
1. En el panel de navegación, elija **Bases de datos** y, a continuación, elija el clúster de base de datos que desee modificar.
1. Elija **Modificar**.
1. En **Especificaciones de la instancia**, elija la nueva versión a la que desea actualizar.
1. Elija **Siguiente**.
1. Si desea aplicar los cambios inmediatamente, active la casilla **Aplicar inmediatamente**.
1. Seleccione **Enviar** para actualizar el clúster de base de datos.
## Instalación de una actualización del motor de una versión menor mediante el AWS CLI
Puede utilizar un comando como el siguiente para realizar una actualización de una versión secundaria sin tener que esperar al siguiente período de mantenimiento:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your-neptune-cluster) \
--engine-version (new-engine-version) \
--apply-immediately
```
Si va a realizar la actualización manualmente mediante el AWS CLI, asegúrese de incluir la versión del motor a la que desea actualizar. Si no lo hace, puede que el motor se actualice a una versión que no sea la más reciente o la que espera.
# Actualización del motor a la versión 1.2.0.0 o posterior desde una versión anterior a la 1.2.0.0
En la [versión 1.2.0.0 del motor](engine-releases-1.2.0.0.md), se introdujeron varios cambios importantes que podrían complicar más de lo normal la actualización desde una versión anterior:
+ En la [versión 1.2.0.0 del motor](engine-releases-1.2.0.0.md), se introdujo un nuevo formato para los grupos de parámetros personalizados y los grupos de parámetros de clústeres personalizados. En consecuencia, si va a actualizar una versión de motor anterior a la 1.2.0.0 a una versión de motor 1.2.0.0 o posterior, debe volver a crear todos los grupos de parámetros personalizados y los grupos de parámetros de clúster personalizados existentes utilizando la familia de grupos de parámetros `neptune1.2`. En las versiones anteriores, se utilizaba la familia de grupos de parámetros `neptune1`, y esos grupos de parámetros no funcionan con la versión 1.2.0.0 y las versiones posteriores. Para obtener más información, consulte [Grupos de parámetros de Amazon Neptune](parameter-groups.md).
+ La versión 1.2.0.0 del motor introdujo un nuevo formato para los registros de deshacer. Por consiguiente, si va a actualizar a la versión 1.2.0.0 o superior desde una versión anterior a la 1.2.0.0, la [`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)métrica debe estar por debajo de un umbral determinado. De lo contrario, el parche se revertirá y fallará. Los umbrales se basan en el tipo de instancia: el límite predeterminado es de 40 000 para las instancias 4xlarge o más y de 10 000 para las instancias menores de 4xlarge. Si `UndoLogListSize` supera el límite al intentar realizar la actualización, el proceso de revisión se revertirá, la actualización se cancelará y aparecerá un evento con el motivo en la página de eventos del clúster. Estos límites pueden cambiar por motivos operativos sin previo aviso.
Para acelerar la velocidad de depuración, actualice la instancia del escritor del clúster, que es donde se realiza la depuración. Hacerlo antes de intentar la actualización puede ayudar a reducir los valores `UndoLogListSize` por debajo del umbral aplicable. Si se aumenta el tamaño del escritor a un tipo de instancia 24XL, se puede aumentar la velocidad de purga a más de un millón de registros por hora.
Si la `UndoLogListSize` CloudWatch métrica es extremadamente grande, abrir un caso de soporte puede ayudarte a explorar estrategias adicionales para reducirla por debajo del límite requerido.
+ Por último, se ha producido un cambio importante en la versión 1.2.0.0 que afecta al código anterior que utilizaba el protocolo Bolt con autenticación de IAM. A partir de la versión 1.2.0.0, Bolt necesita una ruta de recursos para la firma de IAM. En Java, la ruta del recurso podría tener este aspecto: `request.setResourcePath("/openCypher"));`. En otros lenguajes, `/openCypher` se puede agregar al URI del punto de conexión. Para ver ejemplos, consulte [Uso del protocolo Bolt](access-graph-opencypher-bolt.md).