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.
# Administración de la base de datos de Amazon Neptune
En esta sección se muestra cómo administrar y mantener su clúster de base de datos Neptune mediante Consola de administración de AWS y. AWS CLI
Neptune funciona en clústeres de servidores de base de datos que están conectados en una topología de replicación. Por lo tanto, la administración de Neptune suele requerir la implementación de cambios en varios servidores y asegurarse de que todas las réplicas de Neptune mantengan el ritmo del servidor principal.
Dado que Neptune escala de manera transparente el almacenamiento subyacente a medida que crecen sus datos, la administración de Neptune requiere relativamente poco esfuerzo administrativo del almacenamiento en disco. Del mismo modo, dado que Neptune realiza automáticamente copias de seguridad continuas, el clúster de Neptune no requiere una planificación extensa ni tiempo de inactividad a la hora de realizarlas.
**Topics**
+ [
# Uso de la Blue/Green solución Neptune para realizar actualizaciones azul-verde
](neptune-BG-deployments.md)
+ [
# Creación de un usuario de IAM con permisos para Neptune
](manage-console-iam-user.md)
+ [
# Grupos de parámetros de Amazon Neptune
](parameter-groups.md)
+ [
# Parámetros de Amazon Neptune
](parameters.md)
+ [
# Lanzamiento de un clúster de base de datos de Neptune mediante el Consola de administración de AWS
](manage-console-launch-console.md)
+ [
# Detención e inicio de un clúster de base de datos de Amazon Neptune
](manage-console-stop-start.md)
+ [
# Vaciado de un clúster de base de datos de Amazon Neptune con la API de restablecimiento rápido
](manage-console-fast-reset.md)
+ [
# Adición de instancias de lector de Neptune a un clúster de base de datos
](manage-console-add-replicas.md)
+ [
# Creación de una instancia de lector de Neptune con la consola
](manage-console-create-replica.md)
+ [
# Modificación de un clúster de base de datos de Neptune con la consola
](manage-console-modify.md)
+ [
# Rendimiento y escalado en Amazon Neptune
](manage-console-performance-scaling.md)
+ [
# Escalado automático del número de réplicas de un clúster de bases de datos de Amazon Neptune
](manage-console-autoscaling.md)
+ [
# Mantenimiento del clúster de base de datos de Amazon Neptune
](cluster-maintenance.md)
+ [
# 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)
+ [
# Clonación de bases de datos en Neptune
](manage-console-cloning.md)
+ [
# Administración de instancias de Amazon Neptune
](manage-console-instances.md)
# Uso de la Blue/Green solución Neptune para realizar actualizaciones azul-verde
Las actualizaciones del motor de Amazon Neptune pueden requerir un tiempo de inactividad de las aplicaciones, ya que la base de datos no está disponible mientras se instalan y verifican las actualizaciones. Esto se aplica tanto si se inician de forma manual como automática.
Neptune proporciona una solución de Blue/Green despliegue que se puede ejecutar mediante una CloudFormation pila y que reduce considerablemente ese tiempo de inactividad. Crea un entorno de almacenamiento provisional verde que se sincroniza con el entorno de producción azul. A continuación, puede actualizar ese entorno de almacenamiento provisional para realizar una actualización principal o secundaria de la versión del motor, un cambio en el modelo de datos de gráficos o una actualización del sistema operativo, y comprobar el resultado. Por último, puede cambiarlo rápidamente para que se convierta en su entorno de producción, con muy poco tiempo de inactividad.
La Blue/Green solución de Neptune pasa por dos fases, como se ilustra en este diagrama:
![\[Diagrama de flujo de alto nivel de la estrategia de implementación azul-verde\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/BG-flow.png)
**La fase 1 crea un clúster de base de datos verde idéntico al clúster de producción**
La solución crea un clúster de base de datos con un identificador de blue/green implementación único y con la misma topología de clúster que su clúster de producción. Es decir, tiene el mismo número y tamaño de instancias de base de datos, los mismos grupos de parámetros y todas las mismas configuraciones que el clúster de base de datos de producción (azul), excepto que se ha actualizado a la versión de motor de destino que especificó, que debe ser posterior a la versión de motor actual (azul). Puede especificar una versión de motor principal y secundaria del motor para el destino. Si es necesario, la solución realizará las actualizaciones intermedias necesarias para alcanzar la versión especificada del motor de destino. Este nuevo clúster se convierte en el entorno de almacenamiento provisional verde.
**La fase 2 establece la sincronización continua de datos**
Una vez que el entorno verde se ha preparado por completo, la solución establece una replicación continua entre el clúster de origen (azul) y el clúster de destino (verde) mediante transmisiones de Neptune. Cuando la diferencia de replicación entre ellos llegue a cero, el entorno de almacenamiento provisional estará listo para las pruebas. En ese momento, debe hacer una pausa en la escritura en el clúster azul para evitar más retrasos en la replicación.
La versión del motor de destino puede tener nuevas características o dependencias que afecten a las aplicaciones. Consulte la página Versión del motor de destino y las páginas Intervención de las versiones del motor en [Versiones del motor](engine-releases.md) para ver qué ha cambiado desde la versión actual del motor. Le recomendamos realizar pruebas de integración o verificar las aplicaciones manualmente en el clúster verde antes de pasarlas al entorno de producción.
Una vez que haya probado y calificado los cambios en el clúster verde, tan solo tiene que cambiar el punto de conexión de la base de datos de las aplicaciones del clúster azul al verde.
Tras el cambio, la Blue/Green solución Neptune no elimina el antiguo entorno de producción azul. Seguirá teniendo acceso a él para realizar validaciones y pruebas adicionales si es necesario. Se aplican cargos de facturación estándar a sus instancias hasta que las elimine. La Blue/Green solución también utiliza otros AWS servicios, cuyos costes se facturan a precios normales. Podrá encontrar información sobre cómo eliminar la solución cuando haya terminado de utilizarla en la [sección de limpieza](neptune-BG-cleanup.md).
## Requisitos previos para ejecutar la pila de Neptune Blue/Green
Antes de lanzar la pila de Neptune Blue/Green :
+ Asegúrese de [habilitar las transmisiones de Neptune](streams-using.md) en el clúster de producción (azul).
+ Todas las instancias del clúster azul deben estar en el estado **disponible**. Puedes comprobar los estados de las instancias en la [consola de Neptune](https://console.aws.amazon.com/neptune) o mediante la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html)API.
+ Todas las instancias también deben estar sincronizadas con el [grupo de parámetros del clúster de base de datos](parameter-groups.md).
+ La Blue/Green solución Neptune requiere un punto final de VPC de DynamoDB en la VPC donde se encuentra el clúster azul. Consulte [Uso de puntos de conexión de VPC para tener acceso a DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb).
+ Seleccione el momento en el que desee ejecutar la solución cuando la carga de trabajo de escritura del clúster de base de datos de producción azul sea lo más reducida posible. Evite, por ejemplo, ejecutar la solución cuando se produzca una carga masiva o cuando sea probable que haya un gran número de operaciones de escritura por cualquier otro motivo.
# Uso de una CloudFormation plantilla para ejecutar la solución Neptune Blue/Green
Puede utilizarla AWS CloudFormation para implementar la solución Neptune Blue/Green . La CloudFormation plantilla crea una instancia de Amazon EC2 en la misma VPC que la base de datos de Neptune de origen azul, instala la solución allí y la ejecuta. [Puede supervisar su progreso en CloudWatch registros, tal y como se explica en Supervisión del progreso.](neptune-BG-monitoring.md)
Puede utilizar estos enlaces para revisar la plantilla de la solución o seleccionar el botón **Launch Stack** para lanzarla en la CloudFormation consola:
| | | |
| --- |--- |--- |
| [Ver](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [Ver en Designer](https://console.aws.amazon.com/cloudformation/designer/home?templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) |
En la consola, elija la AWS región en la que desee ejecutar la solución en el menú desplegable situado en la parte superior derecha de la ventana.
Establezca los parámetros de pila, tal y como se indica a continuación:
+ **`DeploymentID`**— Un identificador único para cada despliegue de Neptune Blue/Green .
Se utiliza como identificador del clúster de base de datos verde y como prefijo para asignar nombres a los nuevos recursos creados durante la implementación.
+ **`NeptuneSourceClusterId`**: el identificador del clúster de base de datos azul que desea actualizar.
+ **`NeptuneTargetClusterVersion:`** la [versión del motor de Neptune](engine-releases.md) a la que desea actualizar el clúster de base de datos azul.
Este valor debe ser posterior al de la versión del motor del clúster de la base de datos azul actual.
+ **`DeploymentMode`**: indica si se trata de una implementación nueva o de un intento de reanudar una implementación anterior. Si utiliza el mismo `DeploymentID` que una implementación anterior, establezca `DeploymentMode` en `resume`.
Los valores válidos son: `new` (valor predeterminado) y `resume`.
+ **`GraphQueryType`**: el tipo de datos del gráfico de la base de datos.
Los valores válidos son: `propertygraph` (valor predeterminado) y `rdf`.
+ **`SubnetId`**: un ID de subred de la misma VPC en la que se encuentra el clúster de base de datos azul (consulte [Conexión a un clúster de base de datos de Neptune desde una instancia de Amazon EC2 en la misma VPC](get-started-connect-ec2-same-vpc.md)).
Proporcione el ID de una subred pública si desea utilizar SSH en la instancia a través de [EC2 Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html).
+ **`InstanceSecurityGroup`**: un grupo de seguridad para la instancia de Amazon EC2.
El grupo de seguridad debe tener acceso al clúster de base de datos azul, y debe ser posible conectar SSH a la instancia. Consulte [Cree un grupo de seguridad con la consola de VPC](get-started-vpc.md#security-vpc-security-group).
Espere a que se complete la pila. En cuanto finalice, se iniciará la solución. A continuación, puede supervisar el proceso de despliegue mediante CloudWatch registros, tal y como se describe en la siguiente sección.
# Supervisión del progreso de un despliegue de Neptune Blue/Green
Para supervisar el progreso de la Blue/Green solución Neptune, vaya a la [CloudWatch consola y consulte](https://console.aws.amazon.com/cloudwatch/) los registros del grupo de `/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch registros. Puede encontrar un enlace a los CloudWatch registros en los resultados de la CloudFormation pila de la solución:
![\[Captura de pantalla del resultado de la pila azul/verde CloudFormation\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/BG-stack-output.png)
Si ha proporcionado una subred pública como parámetro de pila, también puede conectar SSH a la instancia de Amazon EC2 creada como parte de la pila y consultar el registro en `/var/log/cloud-init-output.log`.
El registro muestra las acciones realizadas por la Blue/Green solución de Neptune, como se muestra en esta captura de pantalla:
![\[Captura de pantalla de la pantalla de registro de Neptune Blue/Green\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/BG-log-screenshot.png)
Los mensajes de registro muestran el estado de sincronización entre el clúster azul y el verde:
![\[Captura de pantalla de los mensajes de registro de la Blue/Green solución Neptune\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/BG-log-messages.png)
El proceso de sincronización comprueba el retraso de la replicación calculando la diferencia entre la última transmisión del clúster azul y `eventID` el punto de control de replicación presente en la tabla de puntos de control de DynamoDB creada por la pila de replicación. Neptune-to-Neptune Con estos mensajes, puede supervisar la diferencia de replicación actual.
# Pasar del clúster azul de producción al clúster verde actualizado
Antes de pasar el clúster verde a producción, asegúrese de que la diferencia de confirmación entre el clúster azul y el verde sea cero y, a continuación, deshabilite todo el tráfico de escritura dirigido al clúster azul. Si se sigue escribiendo en el clúster azul mientras se cambia el punto de conexión de la base de datos al clúster verde, se pueden dañar los datos al escribir datos parciales en ambos clústeres. Es posible que aún no necesite deshabilitar el tráfico de lectura.
Si ha habilitado la autenticación de IAM en el clúster de origen (azul), asegúrese de actualizar las políticas de IAM utilizadas en las aplicaciones para que apunten al clúster verde (para ver un ejemplo de estas políticas, consulte esta [política de acceso sin restricciones](iam-data-access-examples.md#iam-auth-data-policy-example-general)).
Tras deshabilitar el tráfico de escritura, espere a que finalice la replicación y, a continuación, habilite el tráfico de escritura en el clúster verde (pero no en el azul). Cambie también el tráfico de lectura del clúster azul al verde.
# Limpieza después de que se haya completado la Blue/Green solución de Neptune
Una vez que haya promovido el clúster provisional (verde) a producción, limpie los recursos creados por la solución Blue/Green Neptune:
+ Elimine la instancia de Amazon EC2 que se creó para ejecutar la solución.
+ Elimine las CloudFormation plantillas para la [replicación basada en flujos de Neptune](streams-consumer-setup.md) que mantenían el clúster verde sincronizado con el clúster azul. La principal tiene el nombre de pila que proporcionó anteriormente y la otra consta del ID de implementación seguido de “-replication”, es decir, `(DeploymentID)-replication`.
Al eliminar CloudFormation las plantillas, no se eliminan los clústeres en sí. Una vez que haya comprobado que el clúster verde funciona según lo previsto, si lo desea, puede tomar una instantánea antes de eliminar manualmente el clúster azul.
# Mejores prácticas de la Blue/Green solución Neptune
+ Antes de pasar el clúster verde a producción, merece la pena comprobar minuciosamente que funciona de forma correcta. Compruebe la coherencia de los datos y la configuración de la base de datos. Es posible que algunas de las nuevas versiones del motor también requieran actualizaciones del cliente. Consulte las notas de la versión del motor antes de realizar la actualización. Vale la pena probar todo esto en entornos de desarrollo, pruebas y preproducción antes de iniciar una blue/green actualización en producción.
+ Le recomendamos realizar el cambio del servidor azul al verde durante el periodo de mantenimiento.
+ Para garantizar que todo funcione correctamente tras la actualización y la sincronización, merece la pena conservar el clúster original durante un tiempo antes de eliminarlo. Podría resultar útil si surge algún problema imprevisto.
+ Evite las operaciones de escritura pesadas, como las cargas masivas, al ejecutar la Blue/Green solución Neptune, ya que pueden provocar un retraso en la replicación que provoca un tiempo de inactividad significativo. Lo ideal es que el tiempo que transcurra entre la desactivación de las escrituras en el clúster azul y su activación en el clúster verde sea de solo unos instantes.
# Solución de problemas de la solución Neptune Blue/Green
La siguiente información destaca los problemas que pueden surgir durante el proceso de implementación de la Blue/Green solución, como los conflictos con los clústeres existentes, la necesidad de habilitar las transmisiones de Neptune, las operaciones de carga masiva en curso y los requisitos de compatibilidad de versiones. Al abordar estos posibles problemas, puede garantizar una implementación fluida y exitosa de la solución Neptune Blue/Green .
**Errores planteados por la solución de Neptune Blue/Green**
+ **`Cluster with id = (blue_green_deployment_id) already exists`**— Existe un clúster con un identificador*(blue\$1green\$1deployment\$1id)*.
Proporcione un nuevo ID de despliegue o establezca el modo de despliegue en `resume` si el clúster se creó en una ejecución anterior de Neptune Blue/Green .
+ **`Streams should be enabled on the source Cluster for Blue Green Deployment`**: permite habilitar las [transmisiones de Neptune](streams-using-enabling.md) en el clúster azul (origen).
+ **`No Bulkload should be in progress on source cluster: (cluster_id)`**— La Blue/Green solución de Neptune termina si identifica una carga masiva en curso.
Esto es para garantizar que el proceso de sincronización pueda ponerse al día con las escrituras que se están realizando. Evite o cancele cualquier trabajo de carga masiva en curso antes de iniciar la solución Neptune Blue/Green .
+ **`Blue Green deployment requires instances to be in sync with db cluster parameter group`**: cualquier cambio en el grupo de parámetros del clúster debe estar sincronizado en todo el clúster de base de datos. Consulte [Grupos de parámetros de Amazon Neptune](parameter-groups.md).
+ **`Invalid target engine version for Blue Green Deployment`**: la versión del motor de destino debe figurar como activa en [Versiones del motor para Amazon Neptune](engine-releases.md) y debe ser posterior a la versión actual del motor del clúster de origen (azul).
# Creación de un usuario de IAM con permisos para Neptune
Para acceder a la consola de Neptune para crear y administrar un clúster de base de datos Neptune, debe crear un usuario de IAM con todos los permisos necesarios.
El primer paso es crear una política de rol vinculado a un servicio de Neptune:
## Creación de una política de rol vinculado a un servicio de Amazon Neptune
1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación de la izquierda, elija **Políticas**.
1. En la página **Políticas**, seleccione **Crear una política**.
1. En la página **Crear política**, seleccione la pestaña **JSON** y copia la siguiente política de rol vinculado a un servicio:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
]
}
```
------
1. Seleccione **Siguiente: Etiquetas** y en la página **Añadir etiquetas**, seleccione **Siguiente: Revisar**.
1. En la página de **revisión de la política**, asigne el nombre "NeptuneServiceLinked» a la nueva política.
Para obtener más información acerca de los roles vinculados a servicios, consulte [Uso de roles vinculados a servicios para Amazon Neptune](security-iam-service-linked-roles.md).
## Creación de un nuevo usuario de IAM con todos los permisos necesarios
A continuación, cree el nuevo usuario de IAM con las políticas administradas adecuadas que le concederán los permisos que necesite, junto con la política de rol vinculada a un servicio que ha creado (denominada aquí `NeptuneServiceLinked`):
1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación de la izquierda, elija **Usuarios** y en la página **Usuarios**, elija **Añadir usuarios**.
1. **En la página **Añadir usuario**, introduzca un nombre para el nuevo usuario de IAM, elija **Clave de acceso: Acceso programático** para el tipo de AWS credencial y seleccione Siguiente: Permisos.**
1. En la página **Establecer permisos**, en el cuadro **Filtrar políticas**, escriba “Neptune”. Ahora seleccione lo siguiente en las políticas que aparecen en la lista:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**(suponiendo que ese sea el nombre que le dio a la política de funciones vinculadas al servicio que creó anteriormente).
1. A continuación, escriba “VPC” en el cuadro **Filtrar políticas** en lugar de “Neptune”. Selecciona **Amazon VPCFull Access** de las políticas que aparecen en la lista.
1. Seleccione **Siguiente: Etiquetas** y en la página **Añadir etiquetas**, seleccione **Siguiente: Revisar**.
1. En la página **Revisar**, compruebe que todas las políticas siguientes estén ahora asociadas al nuevo usuario:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**
+ **VPCFullAcceso a Amazon**
A continuación, seleccione **Crear usuario**.
1. Por último, descargue y guarde el ID de clave de acceso y la clave de acceso secreta del nuevo usuario.
Para interactuar con otros servicios, como Amazon Simple Storage Service (Amazon S3), tendrá que añadir más permisos y relaciones de confianza.
# Grupos de parámetros de Amazon Neptune
Use los [parámetros](parameters.md) de un grupo de parámetros para administrar la configuración de la base de datos en Amazon Neptune. Los grupos de parámetros sirven de *contenedor* para los valores de configuración del motor que se aplican a una o varias instancias de bases de datos.
Existen dos tipos de grupos de parámetros: los grupos de parámetros de clúster de base de datos y los grupos de parámetros de base de datos.
+ Los *grupos de parámetros de base de datos* se aplican en el nivel de instancia y suelen estar asociados con la configuración del motor de gráficos de Neptune, como, por ejemplo, el parámetro `neptune_query_timeout`.
+ *Los grupos de parámetros de clúster de base de datos* se aplican a todas las instancias del clúster y suelen tener una configuración más extensa. Cada clúster de Neptune se asocia a un grupo de parámetros del clúster de base de datos. Cada instancia de base de datos dentro de ese clúster hereda los valores de configuración del motor incluidos en el grupo de parámetros de clúster de base de datos.
Los valores de configuración que modifique en el grupo de parámetros de clúster de base de datos anulan los valores predeterminados en el grupo de parámetros de base de datos. Si edita los valores correspondientes en el grupo de parámetros de base de datos, dichos valores anulan la configuración del grupo de parámetros de clúster de base de datos.
Si se crea una instancia de base de datos sin especificar un grupo de parámetros de base de datos personalizado, se usa un grupo de parámetros de base de datos predeterminado. La configuración de los parámetros de un grupo de parámetros de base de datos predeterminado no se puede modificar. En su lugar, para cambiar la configuración predeterminada de parámetros, debe crear un nuevo grupo de parámetros de base de datos. No todos los parámetros del motor de base de datos pueden cambiarse en el grupo de parámetros de base de datos que cree.
Los grupos de parámetros se crean en familias que son compatibles con versiones específicas del motor Neptune. Al actualizar a una nueva versión principal o secundaria del motor, es posible que tenga que volver a crear sus grupos de parámetros personalizados utilizando la familia de grupos de parámetros correspondiente a esa versión.
La denominación de la familia de grupos de parámetros sigue el patrón`neptuneX.Y`, donde `X.Y` coincide con la versión del motor. Por ejemplo:
+ `neptune1`— para versiones de motor anteriores a la 1.2.0.0
+ `neptune1.2`— para las versiones de motor 1.2.x
+ `neptune1.3`— para las versiones de motor 1.3.x
+ `neptune1.4`— para las versiones de motor 1.4.x
Cuando actualice su clúster de Neptune, consulte las [notas de la versión](engine-releases.md) de su motor objetivo para determinar si se requiere una nueva familia de grupos de parámetros. Si es así, debe volver a crear todos los grupos de parámetros personalizados de la nueva familia antes de realizar la actualización.
Algunos parámetros de Neptune son estáticos y otros son dinámicos. Las diferencias son las siguientes.
**Parámetros estáticos**
+ Un parámetro estático es aquel que solo se aplica después de reiniciar una instancia de base de datos. Dicho de otro modo, cuando se cambia un parámetro estático y se guarda el grupo de parámetros de base de datos de la instancia, debe reiniciar manualmente la instancia de base de datos para que se aplique el cambio de parámetro. Por el momento, todos los parámetros de nivel de instancia de Neptune (en un grupo de parámetros de base de datos en lugar de en un grupo de parámetros de clúster de base de datos) son estáticos.
+ Cuando se cambia un parámetro estático de nivel de clúster y se guarda el grupo de parámetros de clúster de base de datos, el cambio de parámetros se aplicará después de reiniciar manualmente cada una de las instancias de base de datos en el clúster.
**Parámetros dinámicos**
+ Un parámetro dinámico es aquel que se aplica casi inmediatamente después de actualizar el parámetro en su grupo de parámetros. En otras palabras, no es necesario reiniciar una instancia de base de datos después de actualizar un parámetro dinámico para que se aplique el cambio de parámetro.
+ Espere un pequeño retraso para que un cambio de parámetro dinámico del clúster se aplique a todas las instancias de base de datos.
+ Un valor de parámetro dinámico actualizado no se aplica a las solicitudes que se estén ejecutando actualmente, sino solo a las que se envíen después de que se haya realizado el cambio.
+ Al cambiar un parámetro de nivel de clúster dinámico, el cambio de parámetros se aplica, de forma predeterminada, al clúster de base de datos inmediatamente, sin necesidad de reiniciar. Para aplazar el cambio de parámetros hasta que se reinicien las instancias de base de datos del clúster, puede utilizar la AWS CLI para establecer el valor `ApplyMethod` `pending-reboot` para el cambio de parámetro.
Por el momento, todos los parámetros son estáticos, excepto los siguientes parámetros de clúster nuevos:
+ `neptune_enable_slow_query_log` (en el nivel de clúster)
+ `neptune_slow_query_log_threshold` (en el nivel de clúster)
Estos son algunos puntos importantes que debe tener en cuenta para utilizar los parámetros de un grupo de parámetros de base de datos:
+ Si se configuran de forma incorrecta los parámetros de un grupo de parámetros de base de datos, pueden producirse efectos adversos no deseados, como la degradación del rendimiento y la inestabilidad del sistema. Realice siempre cualquier modificación de los parámetros de base de datos con cuidado y haga una copia de seguridad de los datos antes de modificar un grupo de parámetros de base de datos. Pruebe los cambios de configuración de los grupos de parámetros en una instancia de base de datos de prueba antes de aplicar dichos cambios a una instancia de base de datos de producción.
+ Cuando se cambia el grupo de parámetros de base de datos asociado a una instancia de base de datos, se debe reiniciar manualmente la instancia para que esta utilice el nuevo grupo de parámetros de base de datos.
**nota**
Antes de [Versión: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), todas las instancias de réplicas de lectura de un clúster de base de datos se reiniciaban automáticamente cuando se reiniciaba la instancia principal (escritor).
A partir de [Versión: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), el reinicio de la instancia principal no provoca el reinicio de ninguna de las instancias de réplica. Esto significa que si va a cambiar un parámetro de nivel de clúster, debe reiniciar cada instancia por separado para detectar el cambio de parámetro.
## Edición de un grupo de parámetros de clúster de base de datos o de un grupo de parámetros 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. Elija **Parameter groups (Grupos de parámetros)** en el panel de navegación.
1. Elija el enlace **Name (Nombre)** para el grupo de parámetros de base de datos que desea editar.
(Opcional) Elija **Create parameter group (Crear grupo de parámetros)** para crear un grupo de parámetros de clúster y crear el grupo. A continuación, elija **Name (Nombre)** para el nuevo grupo de parámetros.
**importante**
Este paso es *necesario* si solo tiene el grupo de parámetros de clúster de base de datos predeterminado, ya que dicho grupo no se puede modificar.
1. Busque el parámetro y haga clic en el campo **Valor** situado junto a la columna **Nombre**.
1. Introduzca el valor permitido y seleccione la casilla situada junto al campo de valor.
1. Seleccione **Save changes (Guardar cambios)**.
1. Reinicie todas las instancias de base de datos del clúster de Neptune si está cambiando un parámetro del clúster de base de datos, o una o varias instancias específicas si está cambiando un parámetro de instancia de base de datos.
## Creación de un grupo de parámetros de base de datos o de un grupo de parámetros de clúster de base de datos
Puede utilizar la consola de Neptune para crear un nuevo grupo de parámetros:
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. Seleccione **Parameter groups (Grupos de parámetros)** en el panel de navegación izquierdo.
1. Elija **Create DB parameter group (Crear grupo de parámetros de base de datos)**.
Aparece la página **Create DB Parameter Group (Crear grupo de parámetros de base de datos)**.
1. ****En la lista de **familias de grupos de parámetros**, elija la familia que coincida con la versión del motor Neptuno objetivo (por ejemplo, **neptune1.2, neptune1.3 o neptune1.4**).****
1. En la lista **Type (Tipo)**, elija **DB Parameter Group (Grupo de parámetros de base de datos)** o **DB Cluster Parameter Group (Grupo de parámetros de clúster de base de datos)**.
1. En el cuadro **Group name** (Nombre de grupo), escriba el nombre del nuevo grupo de parámetros de base de datos.
1. En el cuadro **Description** (Descripción) escriba una descripción para el nuevo grupo de parámetros de base de datos.
1. Seleccione **Crear**.
También puede crear un nuevo grupo de parámetros mediante la AWS CLI:
```
aws neptune create-db-parameter-group \
--db-parameter-group-name (a name for the new DB parameter group) \
--db-parameter-group-family (the family matching your engine version, such as neptune1.2, neptune1.3, or neptune1.4) \
--description (a description for the new DB parameter group)
```
# Parámetros de Amazon Neptune
Use los parámetros de los [grupos de parámetros](parameter-groups.md) para administrar la configuración de la base de datos en Amazon Neptune. Están disponibles los siguientes parámetros para configurar la base de datos de Neptune:
**Parámetros de nivel de clúster**
+ [neptune\$1enable\$1audit\$1log](#parameters-db-cluster-parameters-neptune_enable_audit_log)
+ [neptune\$1enable\$1slow\$1query\$1log](#parameters-db-cluster-parameters-neptune_enable_slow_query_log)
+ [neptune\$1slow\$1query\$1log\$1threshold](#parameters-db-cluster-parameters-neptune_slow_query_log_threshold)
+ [neptune\$1lab\$1mode](#parameters-db-cluster-parameters-neptune_lab_mode)
+ [neptune\$1query\$1timeout](#parameters-db-cluster-parameters-neptune_query_timeout)
+ [neptune\$1streams](#parameters-db-cluster-parameters-neptune_streams)
+ [neptune\$1streams\$1expiry\$1days](#parameters-db-cluster-parameters-neptune_streams_expiry_days)
+ [neptune\$1lookup\$1cache](#parameters-db-cluster-parameters-neptune_lookup_cache)
+ [neptune\$1autoscaling\$1config](#parameters-db-cluster-parameters-neptune_autoscaling_config)
+ [neptune\$1ml\$1iam\$1role](#parameters-db-cluster-parameters-neptune_ml_iam_role)
+ [neptune\$1ml\$1endpoint](#parameters-db-cluster-parameters-neptune_ml_endpoint)
+ [neptune\$1enable\$1inline\$1server\$1generated\$1edge\$1id](#parameters-db-cluster-parameters-neptune_inline_edge_id)
**Parámetros de nivel de instancia**
+ [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine)
+ [neptune\$1query\$1timeout](#parameters-instance-parameters-neptune_query_timeout)
+ [neptune\$1result\$1cache](#parameters-db-instance-parameters-neptune_result_cache)
+ [UndoLogPurgeConfig](#parameters-db-instance-parameters-undo_log_purge_config)
**Parámetros no disponibles**
+ [neptune\$1enforce\$1ssl](#parameters-db-cluster-parameters-neptune_enforce_ssl)
## `neptune_enable_audit_log` (parámetro de nivel de clúster)
Este parámetro cambia el registro de auditoría de Neptune.
Los valores permitidos son `0` (deshabilitado) y `1` (habilitado). El valor predeterminado es `0`.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Puedes publicar registros de auditoría en Amazon CloudWatch, tal y como se describe en[Uso de la CLI para publicar los registros de auditoría de Neptune en Logs CloudWatch](cloudwatch-logs.md#cloudwatch-logs-cli).
## `neptune_enable_slow_query_log` (parámetro de nivel de clúster)
Utilice este parámetro para habilitar o deshabilitar la característica [registro de consultas lentas](slow-query-logs.md) de Neptune.
Se trata de un parámetro dinámico, lo que significa que cambiar su valor no requiere ni provoca el reinicio del clúster de base de datos.
Los valores permitidos son:
+ **`info`**: permite el registro de consultas lentas y registra los atributos seleccionados que podrían dando lugar a un rendimiento lento.
+ **`debug`**: permite el registro de consultas lentas y registra todos los atributos disponibles de la ejecución de la consulta.
+ **`disabled`**: deshabilita el registro de consultas lentas.
El valor predeterminado es `disabled`.
Puedes publicar registros de consultas lentas en Amazon CloudWatch, tal y como se describe en. [Uso de la CLI para publicar registros de consultas lentas de Neptune en Logs CloudWatch](cloudwatch-logs.md#cloudwatch-slow-query-logs-cli)
## `neptune_slow_query_log_threshold` (parámetro de nivel de clúster)
Este parámetro especifica el umbral de tiempo de ejecución, en milisegundos, tras el cual una consulta se considera lenta. Si el [registro de consultas lentas](slow-query-logs.md) está habilitado, las consultas que superen este umbral se registrarán junto con algunos de sus atributos.
El valor predeterminado es de 5000 milisegundos (5 segundos).
Se trata de un parámetro dinámico, lo que significa que cambiar su valor no requiere ni provoca el reinicio del clúster de base de datos.
## `neptune_lab_mode` (parámetro de nivel de clúster)
Cuando se establece, este parámetro habilita características experimentales específicas de Neptune. Consulte [Modo de laboratorio de Neptune](features-lab-mode.md) para ver las características experimentales que están disponibles actualmente.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Para activar o desactivar una función experimental, incluya *(feature name)* `=enabled` o *(feature name)* `=disabled` en este parámetro. Puede habilitar o deshabilitar varias características separándolas con comas; por ejemplo:
*(feature \$11 name)*`=enabled,` *(feature \$12 name)*`=enabled`
Las características del modo de laboratorio suelen estar deshabilitadas de forma predeterminada. Una excepción es la característica `DFEQueryEngine`, que se habilitó de forma predeterminada para su uso con sugerencias de consulta (`DFEQueryEngine=viaQueryHint`) a partir de la [versión 1.0.5.0 del motor de Neptune](engine-releases-1.0.5.0.md). A partir de la [versión 1.1.1.0 del motor de Neptune](engine-releases-1.1.1.0.md), el motor DFE ya no está en modo de laboratorio y ahora se controla mediante el parámetro de instancia [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) del grupo de parámetros de base de datos de una instancia.
## `neptune_query_timeout` (parámetro de nivel de clúster)
Especifica un determinado tiempo de espera para las consultas de gráficos, en milisegundos.
Los valores permitidos van desde `10` hasta `2,147,483,647` (231 - 1). El valor predeterminado es `120,000` (2 minutos).
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Cuando se configuran varios ajustes de tiempo de espera (a nivel de clúster, a nivel de instancia y por consulta), en la siguiente tabla se muestra qué valor de tiempo de espera tiene prioridad:
| Clúster PG | Instancia PG | Sugerencia de consulta | Resultado |
| --- | --- | --- | --- |
| Predeterminado | Predeterminado | none | Clúster |
| Personalizada | Predeterminado | none | Clúster |
| Personalizada | Personalizada | none | Instancia |
| Predeterminado | Personalizada | none | Instancia |
| Cualquiera | Cualquiera | lowest | Consultar |
| Predeterminado | Personalizada | no la más baja | Instancia |
| Personalizada | Predeterminado | no el más bajo | Clúster |
| Personalizada | Personalizada | no el más bajo | Instancia |
**nota**
Es posible incurrir en costos inesperados si se establece un valor de tiempo de espera de consulta demasiado alto, especialmente en una instancia sin servidor. Sin una configuración de tiempo de espera razonable, es posible que, sin darse cuenta, emita una consulta que siga ejecutándose durante mucho más tiempo del esperado, lo que dará lugar a costos que no había previsto. Esto ocurre especialmente en una instancia sin servidor que podría escalarse verticalmente hasta convertirse en un tipo de instancia grande y caro mientras se ejecuta la consulta.
Para evitar gastos inesperados de este tipo, utilice un valor de tiempo de espera de consulta que se adapte a la mayoría de las consultas y que solo provoque que se agoten inesperadamente las que se ejecutan durante mucho tiempo.
## `neptune_streams` (parámetro de nivel de clúster)
Habilita o deshabilita [Flujos de Neptune](streams.md).
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Los valores permitidos son `0` (deshabilitado, que es el valor predeterminado) y `1` (habilitado).
## `neptune_streams_expiry_days` (parámetro de nivel de clúster)
Especifica cuántos días deben transcurrir antes de que el servidor elimine los registros de transmisión.
Los valores permitidos son de `1` a `90`, ambos incluidos. El valor predeterminado es `7`.
Este parámetro se introdujo en la [versión 1.2.0.0 del motor](engine-releases-1.2.0.0.md).
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
## `neptune_lookup_cache` (parámetro de nivel de clúster)
Deshabilita o vuelve a habilitar la [caché de búsqueda de Neptune](feature-overview-lookup-cache.md) en instancias `R5d`.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Los valores permitidos son `1` (habilitado) y `0` (deshabilitado). El valor predeterminado es `0`, pero siempre que se crea una instancia `R5d` en el clúster de base de datos, el parámetro `neptune_lookup_cache` se establece automáticamente en `1` y se crea una caché de búsqueda en esa instancia.
## `neptune_autoscaling_config` (parámetro de nivel de clúster)
Establece los parámetros de configuración de las instancias de réplica de lectura que el [escalado automático de Neptune](manage-console-autoscaling.md) crea y administra.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Con una cadena JSON que establezca como valor del parámetro `neptune_autoscaling_config`, puede especificar:
+ El tipo de instancia que utiliza el escalado automático de Neptune para todas las nuevas instancias de réplica de lectura que crea.
+ Los periodos de mantenimiento asignados a esas réplicas de lectura.
+ Las etiquetas que se asociarán a todas las réplicas de lectura nuevas.
La cadena JSON tiene una estructura como esta:
```
"{
\"tags\": [
{ \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" },
{ \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" },
],
\"maintenanceWindow\" : \"wed:12:03-wed:12:33\",
\"dbInstanceClass\" : \"db.r5.xlarge\"
}"
```
Tenga en cuenta que a todas las comillas de la cadena se les debe aplicar una secuencia de escape con un carácter de barra diagonal inversa (`\`).
Cualquiera de los tres ajustes de configuración no especificados en el parámetro `neptune_autoscaling_config` se copia de la configuración de la instancia de escritor principal del clúster de base de datos.
## `neptune_ml_iam_role` (parámetro de nivel de clúster)
Especifica el ARN del rol de IAM utilizado en Neptune ML. El valor puede ser cualquier ARN válido de rol de IAM.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Puede especificar el ARN predeterminado del rol de IAM para el machine learning en los gráficos.
## `neptune_ml_endpoint` (parámetro de nivel de clúster)
Especifica el punto de conexión utilizado para Neptune ML. El valor puede ser cualquier [nombre de punto final de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateEndpoint.html#sagemaker-CreateEndpoint-request-EndpointName) válido.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Puede especificar el punto final de SageMaker IA predeterminado para el aprendizaje automático en los gráficos.
## `neptune_enable_inline_server_generated_edge_id` (parámetro de nivel de clúster)
Habilita o deshabilita la característica de ID periférico generado por el servidor en línea de Neptune.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Los valores permitidos son `1` (habilitado) y `0` (deshabilitado). El valor predeterminado es `0`.
## `neptune_dfe_query_engine` (parámetro de nivel de instancia)
A partir de la [versión 1.1.1.0 del motor Neptune](engine-releases-1.1.1.0.md), este parámetro de instancia de base de datos se utiliza para controlar el uso del [motor de consultas DFE](neptune-dfe-engine.md). Los valores permitidos son los siguientes:
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
+ **`enabled`**: hace que se utilice el motor DFE siempre que sea posible, excepto cuando la sugerencia de consulta `useDFE` esté presente y establecida en `false`.
+ **`viaQueryHint`** (valor predeterminado): hace que el motor DFE se utilice únicamente para consultas que incluyen explícitamente la sugerencia de consulta `useDFE` establecida en `true`.
Si este parámetro no se ha establecido de forma explícita, se utiliza el valor predeterminado, `viaQueryHint`, al iniciar la instancia.
**nota**
El motor DFE ejecuta todas las consultas de openCypher, independientemente de cómo esté establecido este parámetro.
Antes de la versión 1.1.1.0, era un parámetro de modo laboratorio y no un parámetro de instancia de base de datos.
## `neptune_query_timeout` (parámetro de nivel de instancia)
Este parámetro de instancia de base de datos especifica el tiempo de espera para las consultas de gráficos, en milisegundos, para una instancia.
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Los valores permitidos van desde `10` hasta `2,147,483,647` (231 - 1). El valor predeterminado es `120,000` (2 minutos).
**nota**
Es posible incurrir en costos inesperados si se establece un valor de tiempo de espera de consulta demasiado alto, especialmente en una instancia sin servidor. Sin una configuración de tiempo de espera razonable, es posible que, sin darse cuenta, emita una consulta que siga ejecutándose durante mucho más tiempo del esperado, lo que dará lugar a costos que no había previsto. Esto ocurre especialmente en una instancia sin servidor que podría escalarse verticalmente hasta convertirse en un tipo de instancia grande y caro mientras se ejecuta la consulta.
Para evitar gastos inesperados de este tipo, utilice un valor de tiempo de espera de consulta que se adapte a la mayoría de las consultas y que solo provoque que se agoten inesperadamente las que se ejecutan durante mucho tiempo.
## `neptune_result_cache` (parámetro de nivel de instancia)
**`neptune_result_cache`**: este parámetro de instancia de base de datos habilita o deshabilita [Almacenamiento en caché de resultados de las consultas](gremlin-results-cache.md).
Este parámetro es estático, lo que significa que los cambios que se realicen en él no se aplican en ninguna instancia hasta que se haya reiniciado.
Los valores permitidos son `0` (deshabilitado, que es el valor predeterminado) y `1` (habilitado).
## `UndoLogPurgeConfig` (parámetro de nivel de instancia)
**`UndoLogPurgeConfig`**— Utilice este parámetro para activar o desactivar la UndoLog purga agresiva en Neptune.
Los valores permitidos son `default`, que utiliza el número estándar de subprocesos para la purga del registro de deshacer, y `aggressive`, que utilizan un mayor número de subprocesos para acelerar la limpieza de los registros de deshacer. Cuando se selecciona la opción `agressive`, lo normal es que la métrica `NumUndoPagesPurged` tenga un valor más alto.
## `neptune_enforce_ssl`(Parámetro de nivel de clúster NO DISPONIBLE)
(**No disponible**) Solía haber regiones que permitían las conexiones HTTP a Neptune, y este parámetro se utilizó para forzar a todas las conexiones a usar HTTPS cuando estaba establecida en 1. Sin embargo, este parámetro ya no es relevante, ya que Neptune ahora solo acepta conexiones HTTPS en todas las regiones.
# Lanzamiento de un clúster de base de datos de Neptune mediante el Consola de administración de AWS
La forma más sencilla de lanzar un nuevo clúster de base de datos de Neptune es utilizar una CloudFormation plantilla que cree todos los recursos necesarios, como se explica en. [Creación de un clúster de Neptune](get-started-create-cluster.md)
Si lo prefiere, también puede utilizar la consola de Neptune para lanzar un nuevo clúster de base de datos manualmente, tal y como se explica aquí.
**nota**
Para poder tener acceso a la consola de Neptune y crear un clúster de Neptune, debe tener un usuario de con los permisos suficientes. Si su usuario actual no tiene estos permisos, puede crear un usuario de IAM con los permisos necesarios, tal y como se explica en [Creación de un usuario de IAM con permisos para Neptune](manage-console-iam-user.md).
Una vez que haya comprobado que su usuario tiene los permisos correctos, o haya creado un usuario con los permisos correctos, inicie sesión Consola de administración de AWS como ese usuario de IAM y siga los pasos que se indican a continuación para crear un nuevo clúster de base de datos:
**Para lanzar un clúster de base de datos de Neptune mediante la consola**
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. Vaya a la página **Clústeres** en **Bases de datos** y seleccione **Crear base de datos**, lo que abrirá la página **Crear base de datos**.
1. En **Configuración**, introduzca un nombre para el nuevo clúster de base de datos o acepte el nombre predeterminado que se proporciona allí. Este nombre se utiliza en la dirección del punto de conexión de la instancia y debe cumplir las siguientes restricciones:
+ Debe contener de 1 a 63 caracteres alfanuméricos o guiones.
+ El primer carácter debe ser una letra.
+ No puede terminar con un guion ni contener dos guiones consecutivos.
+ Debe ser único en todas las instancias de base de datos de su AWS cuenta en una AWS región determinada.
1. En **Plantillas**, elija **Producción** o **Desarrollo y pruebas**.
1. En **Tamaño de la instancia de base de datos**, elija un tamaño de instancia. Esto determinará el procesamiento y la capacidad de memoria de la instancia de escritura principal del nuevo clúster de base de datos.
Si ha seleccionado la plantilla **Producción**, solo podrá elegir entre las clases de memoria optimizada disponibles de la lista, pero si ha seleccionado **Desarrollo y pruebas**, también puede elegir entre las clases por ráfagas más económicas (consulte [Instancias con ráfagas T3](manage-console-instances-t3.md) para obtener información sobre las clases ampliables).
**nota**
Neptune ya no admite tipos de `R4` instancias.
1. En **Disponibilidad y durabilidad**, puede elegir si desea habilitar o no la implementación multi-availability-zone (Multi-AZ). La plantilla de producción permite la implementación multi-AZ de forma predeterminada, mientras que la plantilla de desarrollo y pruebas no lo permite. Si la implementación Multi-AZ está habilitada, Neptune localiza las instancias de réplica y lectura que cree en diferentes zonas AZs de disponibilidad () para mejorar la disponibilidad.
1. En **Conectividad**, seleccione la nube privada virtual (VPC) que alojará el nuevo clúster de base de datos entre las opciones disponibles. Aquí puede elegir **Crear nueva VPC** si desea que Neptune cree la VPC por usted. Debe crear una instancia de Amazon EC2 en esta misma VPC para acceder a la instancia de Neptune (para obtener más información, consulte [Protección de la base de datos de Amazon Neptune con Amazon VPC](security-vpc.md)). Tenga en cuenta que no puede cambiar la VPC después de crear el clúster de base de datos.
Si lo necesita, puede configurar aún más la conectividad del clúster en **Configuración de conectividad adicional**:
1. En **Grupo de subredes**, puede elegir el grupo de subredes de base de datos de Neptune que se debe usar para el nuevo clúster de base de datos. Si la VPC no tiene aún ningún grupo de subred, Neptune crea un grupo de subred de base de datos (consulte [Protección de la base de datos de Amazon Neptune con Amazon VPC](security-vpc.md)).
1. En **Grupos de seguridad de la VPC**, elija uno o varios grupos de seguridad de la VPC existentes para proteger el acceso de red al nuevo clúster de base de datos o elija **Crear nuevo** si desea que Neptune cree uno por usted y, a continuación, proporcione un nombre para el nuevo grupo de seguridad de la VPC (consulte [Cree un grupo de seguridad con la consola de VPC](get-started-vpc.md#security-vpc-security-group)).
1. En **Puerto de base de datos, introduzca el TCP/IP puerto** que utilizará la base de datos para las conexiones de las aplicaciones. Neptune usa el número de puerto `8182` de forma predeterminada.
1. En **Configuración de cuaderno**, seleccione **Crear cuaderno** si desea que Neptune cree cuadernos de Jupyter en el entorno de trabajo de Neptune (consulte [Uso de Amazon Neptune con cuadernos de gráficos](graph-notebooks.md) y [Uso del entorno de trabajo de Neptune para alojar los cuadernos de Neptune](graph-notebooks.md#graph-notebooks-workbench)). A continuación, puede elegir cómo deben configurarse los nuevos cuadernos:
1. En **Tipo de instancia de cuaderno**, elija una de las clases de instancias disponibles para el cuaderno.
1. En **Nombre del cuaderno**, escriba un nombre para el cuaderno.
1. Si lo desea, también puedes introducir una descripción del cuaderno en **Descripción: opcional**.
1. En el **nombre del rol de IAM**, elija que Neptune cree un rol de IAM para el cuaderno e introduzca un nombre para el nuevo rol, o elija un rol de IAM existente entre los roles disponibles.
1. Por último, elija si su portátil se conecta a Internet directamente o a través de Amazon SageMaker AI o a través de una VPC con una puerta de enlace NAT. Consulte [Conexión de una instancia de cuaderno a los recursos de una VPC](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html) para obtener más información.
1. En **Etiquetas**, puede asociar hasta 50 etiquetas al nuevo clúster de base de datos.
1. En **Configuración adicional**, puede realizar más ajustes para el nuevo clúster de base de datos (en muchos casos, puede omitirlos y aceptar, por ahora, los valores predeterminados):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/manage-console-launch-console.html)
1. Elija **Crear base de datos** para lanzar su nuevo clúster de base de datos de Neptune y su instancia principal.
En la consola de Amazon Neptune, el nuevo clúster de base de datos aparece en la lista de bases de datos. El clúster de base de datos tendrá el estado **Creating (Creándose)** hasta que se cree y se pueda usar. Cuando el estado cambie a **Available (Disponible)**, podrá conectarse a la instancia principal de su clúster de base de datos. Dependiendo de la clase de instancia de base de datos y del almacenamiento asignado, es posible que las nuevas instancias tarden varios minutos en estar disponibles.
Para ver el clúster que acaba de crear, elija la vista **Bases de datos** en la consola de Neptune.
**nota**
Si elimina todas las instancias de base de datos de Neptune de un clúster de base de datos mediante el Consola de administración de AWS, la consola elimina automáticamente el propio clúster de base de datos. Si utiliza el SDK AWS CLI o el SDK, debe eliminar el clúster de base de datos manualmente después de eliminar su última instancia.
Anote el valor de **Punto de conexión de clúster**. Lo necesitará para conectarse al clúster de base de datos de Neptune.
# Detención e inicio de un clúster de base de datos de Amazon Neptune
Detener e iniciar los clústeres de Amazon Neptune le ayuda a administrar los costos de entornos de desarrollo y pruebas. Puede detener temporalmente todas las instancias de base de datos su clúster, en lugar de configurar y eliminar todas las instancias de base de datos cada vez que use el clúster.
**Topics**
+ [
## Información general sobre la detención e inicio de un clúster de base de datos de Neptune
](#manage-console-start-stop-overview)
+ [
## Detención de un clúster de base de datos de Neptune
](#manage-console-stopping)
+ [
## Inicio de un clúster de base de datos de Neptune detenido
](#manage-console-start)
## Información general sobre la detención e inicio de un clúster de base de datos de Neptune
Durante los periodos en los que no necesite un clúster de Neptune, puede detener a la vez todas las instancias de dicho clúster. Puede volver a iniciar el clúster en cualquier momento que necesite usarlo. El inicio y la detención simplifican los procesos de configuración y eliminación de clústeres usados para desarrollo, pruebas o actividades similares que no requieren disponibilidad continua. Puede lograrlo Consola de administración de AWS con una sola acción, independientemente del número de instancias que haya en el clúster.
Mientras su instancia de base de datos esté detenida, solo se le cobrará el almacenamiento del clúster, las instantáneas manuales y el almacenamiento de la copia de seguridad automática dentro de su intervalo de retención especificado. No se le cobrarán las horas de ninguna instancia de base de datos.
Después de siete días, Neptune vuelve a iniciar automáticamente el clúster de base de datos para asegurarse de que no se quede atrás con las actualizaciones de mantenimiento necesarias.
Para minimizar los cargos de un clúster de Neptune de carga ligera, puede detener el clúster en lugar de eliminar todas sus réplicas de lectura. Para los clústeres con más de una o dos instancias, eliminar y volver a crear las instancias de base de datos con frecuencia solo resulta práctico con la API AWS CLI o Neptune, y las eliminaciones también pueden resultar difíciles de realizar en el orden correcto. Por ejemplo, debe eliminar todas las réplicas de lectura antes de eliminar la instancia principal para evitar activar el mecanismo de conmutación por error.
No utilice la opción de iniciar y detener si necesita mantener el clúster de base de datos en ejecución, pero desea reducir la capacidad. Si el clúster es demasiado costoso o no está muy ocupado, puede eliminar una o más instancias de base de datos o cambiar las instancias de base de datos para utilizar una clase de instancia más pequeña, pero no puede detener una instancia de base de datos individual.
## Detención de un clúster de base de datos de Neptune
Cuando no lo vaya a utilizar durante un tiempo, puede detener un clúster de base de datos de Neptune en ejecución y, a continuación, volver a iniciarlo cuando lo necesite. Mientras el clúster esté detenido, se le cobrará el almacenamiento del clúster, las instantáneas manuales y el almacenamiento de la copia de seguridad automática dentro de su intervalo de retención especificado, pero no se le cobrarán las horas de instancia de base de datos.
La operación de detención detiene todas las instancias de réplica de lectura del clúster antes de detener la instancia principal, para evitar activar el mecanismo de conmutación por error.
### Detener un clúster de base de datos mediante Consola de administración de AWS
**Para usar el Consola de administración de AWS para detener un cúmulo de Neptuno**
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)** y, a continuación, elija un clúster. Puede realizar la operación de detención desde esta página o navegar a la página de detalles del clúster de bases de datos que desea detener.
1. En **Actions (Acciones)**, elija **Stop (Detener)**.
### Detener un clúster de base de datos mediante AWS CLI
Para detener una instancia de base de datos mediante el AWS CLI[stop-db-cluster](api-clusters.md#StopDBCluster)comando, utilice el `--db-cluster-identifier` parámetro para identificar el clúster de base de datos que desea detener.
**Example**
```
aws neptune stop-db-cluster --db-cluster-identifier mydbcluster
```
### Detención de un clúster de base de datos con la API de administración de Neptune
Para detener una instancia de base de datos mediante la API de administración de Neptune, llame a la DBCluster API [Stop](api-clusters.md#StopDBCluster) y utilice el `DBClusterIdentifier` parámetro para identificar el clúster de base de datos que desea detener.
### Qué puede suceder mientras un clúster de base de datos está detenido
+ **Se puede** restaurar a partir de una instantánea (consulte [Restauración de una instantánea de clúster de base de datos](backup-restore-restore-snapshot.md)).
+ **No se puede** modificar la configuración del clúster de base de datos ni de ninguna de sus instancias de base de datos.
+ **No se pueden** añadir ni eliminar instancias de base de datos del clúster.
+ **No se puede** eliminar el clúster si todavía tiene instancias de base de datos asociadas.
+ En general, debe volver a iniciar un clúster de base de datos detenido para realizar la mayoría de las acciones administrativas.
+ Neptune aplica cualquier mantenimiento programado al clúster detenido en cuanto se vuelva a iniciar. Recuerde que, al cabo de siete días, Neptune vuelve a iniciar automáticamente un clúster detenido para que no se quede demasiado rezagado en el estado de mantenimiento.
+ Neptune no realiza ninguna copia de seguridad automática de un clúster de base de datos detenido, porque los datos subyacentes no pueden cambiar mientras el clúster esté detenido.
+ Neptune no amplía el periodo de retención de copia de seguridad del clúster de base de datos mientras esté detenido.
## Inicio de un clúster de base de datos de Neptune detenido
Solo se puede iniciar un clúster de base de datos de Neptune que se encuentre en estado detenido. Cuando inicia el clúster, todas sus instancias de base de datos se vuelven disponibles otra vez. El clúster conserva sus ajustes de configuración como puntos de enlace, grupos de parámetros y grupos de seguridad de VPC.
### Iniciar un clúster de base de datos detenido mediante Consola de administración de AWS
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)** y, a continuación, elija un clúster. Puede realizar la operación de inicio desde esta página o acceder a la página de detalles del clúster de base de datos y empezar ahí.
1. En **Actions (Acciones)**, elija **Start (Iniciar)**.
### Iniciar un clúster de base de datos detenido mediante el AWS CLI
Para iniciar un clúster de base de datos detenido mediante el AWS CLI, llame al [start-db-cluster](api-clusters.md#StartDBCluster)comando mediante el `--db-cluster-identifier` parámetro para especificar el clúster de base de datos detenido que desea iniciar. Indique el nombre del clúster que haya elegido al crear el clúster de base de datos o utilice un nombre de instancia de base de datos que haya elegido, con `-cluster` anexado al final del mismo.
**Example**
```
aws neptune start-db-cluster --db-cluster-identifier mydbcluster
```
### Inicio de un clúster de base de datos detenido mediante la API de administración de Neptune
Para iniciar un clúster de base de datos de Neptune mediante la API de administración de Neptune, llame a la DBCluster API [Start](api-clusters.md#StartDBCluster) mediante el `DBCluster` parámetro para especificar el clúster de base de datos detenido que desea iniciar. Indique el nombre del clúster que haya elegido al crear el clúster de base de datos o utilice un nombre de instancia de base de datos que haya elegido, con `-cluster` anexado al final del mismo.
# Vaciado de un clúster de base de datos de Amazon Neptune con la API de restablecimiento rápido
La API de REST de restablecimiento rápido de Neptune le permite restablecer un gráfico de Neptune de forma rápida y sencilla, eliminando todos sus datos.
Puede hacerlo en un cuaderno de Neptune con el comando mágico de línea [%db\$1reset](#manage-console-fast-reset-db-reset-magic).
+ En la mayoría de los casos, la operación de restablecimiento rápido se completa en un par de minutos. La duración puede variar un poco en función de la carga del clúster cuando se inicia la operación.
+ Una operación de restablecimiento rápido no genera E/S adicionales.
+ El tamaño del volumen de almacenamiento no se reduce después de un restablecimiento rápido. En cambio, el almacenamiento se vuelve a utilizar a medida que se introducen nuevos datos. Esto significa que los tamaños de volumen de las instantáneas tomadas antes y después de una operación de restablecimiento rápido serán los mismos. Los tamaños de volumen de los clústeres restaurados con las instantáneas creadas antes y después de una operación de restablecimiento rápido también serán los mismos
+ Como parte de la operación de restablecimiento, se reinician todas las instancias en el clúster de base de datos.
**nota**
En casos excepcionales, estos reinicios del servidor también pueden provocar una conmutación por error del clúster.
**importante**
El uso del restablecimiento rápido puede interrumpir la integración del clúster de base de datos de Neptune con otros servicios. Por ejemplo:
El restablecimiento rápido elimina todos los datos de transmisión de la base de datos y restablece completamente las transmisiones. Esto significa que es posible que los consumidores de transmisiones ya no funcionen sin una nueva configuración.
El restablecimiento rápido elimina todos los metadatos sobre los recursos de SageMaker IA que utiliza Neptune ML, incluidos los trabajos y los puntos finales. Siguen existiendo en la SageMaker IA y se pueden seguir utilizando los puntos finales de SageMaker IA existentes para las consultas de inferencia de ML de Neptune, pero la APIs administración de Neptune ML ya no funciona con ellos.
Las integraciones, como la full-text-search integración con, también ElasticSearch se eliminan al restablecerse rápidamente y deben restablecerse manualmente antes de poder volver a utilizarlas.
**Para eliminar todos los datos de un clúster de base de datos de Neptune con la API**
1. En primer lugar, se genera un token que, a continuación, se puede utilizar para restablecer la base de datos. El objetivo de este paso es evitar que alguien restablezca por error una base de datos.
Para ello, debe enviar una solicitud `HTTP POST` al punto de conexión `/system` de la instancia de escritor del clúster de base de datos para especificar la acción `initiateDatabaseReset`.
El comando `curl` con el tipo de contenido JSON sería:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{ "action" : "initiateDatabaseReset" }'
```
O bien, con el tipo de contenido `x-www-form-urlencoded`:
```
curl -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
https://your_writer_instance_endpoint:8182/system \
-d 'action=initiateDatabaseReset '
```
La solicitud `initiateDatabaseReset` devuelve el token de restablecimiento en su respuesta JSON, tal y como se indica a continuación:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
El token sigue siendo válido durante una hora (60 minutos) después de su emisión.
Si envía la solicitud a una instancia de lector o al punto de conexión de estado, Neptune lanzará una `ReadOnlyViolationException`.
Si envía varias solicitudes `initiateDatabaseReset`, solo el último token generado será válido para el segundo paso, en el que realmente realiza el restablecimiento.
Si el servidor se reinicia justo después de la solicitud `initiateDatabaseReset`, el token generado deja de ser válido y tendrá que enviar una nueva solicitud para obtener uno nuevo.
1. A continuación, envíe una solicitud `performDatabaseReset` con el token que ha recibido de `initiateDatabaseReset` a punto de conexión `/system` de la instancia de escritor del clúster de base de datos. De este modo, se eliminan todos los datos del clúster de base de datos.
El comando `curl` con el tipo de contenido JSON es:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{
"action" : "performDatabaseReset",
"token" : "token_guid"
}'
```
O bien, con el tipo de contenido `x-www-form-urlencoded`:
```
curl -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
https://your_writer_instance_endpoint:8182/system \
-d 'action=performDatabaseReset&token=token_guid'
```
La solicitud devuelve una respuesta JSON. Si se acepta la solicitud, la respuesta es:
```
{
"status" : "200 OK"
}
```
Si el token que envió no coincide con el que se emitió, la respuesta tendrá el siguiente aspecto:
```
{
"code" : "InvalidParameterException",
"requestId":"token_guid",
"detailedMessage" : "System command parameter 'token' : 'token_guid' does not match database reset token"
}
```
Si se acepta la solicitud y comienza el restablecimiento, el servidor se reinicia y elimina los datos. No puede enviar ninguna otra solicitud al clúster de base de datos mientras se está restableciendo.
## Uso de la API de restablecimiento rápido con IAM-Auth
Si ha habilitado IAM-auth en el clúster de base de datos, puede utilizar [awscurl](https://github.com/okigan/awscurl) para enviar comandos de restablecimiento rápido que se autentiquen mediante IAM-Auth:
**Uso de awscurl para enviar solicitudes de restablecimiento rápido con IAM-Auth**
1. Configure las variables de entorno `AWS_ACCESS_KEY_ID` y `AWS_SECRET_ACCESS_KEY` correctamente (y también `AWS_SECURITY_TOKEN` si utiliza una credencial temporal).
1. Una solicitud `initiateDatabaseReset` tiene este aspecto:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "initiateDatabaseReset" }'
```
1. Una solicitud `performDatabaseReset` tiene este aspecto:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "performDatabaseReset" }'
```
## Uso del comando mágico de línea `%db_reset` del entorno de trabajo de Neptune para restablecer un clúster de base de datos
El entorno de trabajo de Neptune admite un comando mágico de línea `%db_reset` que le permite restablecer rápidamente la base de datos en un cuaderno de Neptune.
Si invoca el comando mágico sin ningún parámetro, verá una pantalla en la que se le preguntará si desea eliminar todos los datos del clúster, con una casilla de verificación en la que se le pide que confirme que los datos del clúster dejarán de estar disponibles después de eliminarlos. En ese momento, puede elegir entre eliminar los datos o cancelar la operación.
Una opción más peligrosa es invocar `%db_reset` con la opción `--yes` o `-y`, lo que hace que la eliminación se realice sin más solicitudes.
También puedes realizar el restablecimiento en dos pasos, igual que con la API de REST:
```
%db_reset --generate-token
```
La respuesta es:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
Haga lo siguiente:
```
%db_reset --token new_token_guid
```
La respuesta es:
```
{
"status" : "200 OK"
}
```
## Códigos de error comunes para las operaciones de restablecimiento rápido
| Código de error de Neptune | Estado HTTP | Mensaje | Ejemplo |
| --- | --- | --- | --- |
| `InvalidParameterException` | 400 | El parámetro de comando del sistema '*action*' tiene un valor no admitido '' *XXX* | Parámetro no válido |
| `InvalidParameterException` | 400 | Se han proporcionado demasiados valores para: *action* | Se envió una solicitud de restablecimiento rápido con más de una acción con el encabezado «x-www-form-urlencodedContent-Type:Application/» |
| `InvalidParameterException` | 400 | Campo duplicado “acción” | Una solicitud de restablecimiento rápido con más de una acción enviada con el encabezado “Content-Type: application/json” |
| `MethodNotAllowedException` | 400 | Ruta incorrecta:/*bad\$1endpoint* | Solicitud enviada a un punto de conexión incorrecto |
| `MissingParameterException` | 400 | Faltan parámetros obligatorios: [acción] | Una solicitud de restablecimiento rápido no incluye el parámetro “acción” necesario |
| `ReadOnlyViolationException` | 400 | No se permiten escritores en una instancia de réplica de lectura | Se ha enviado una solicitud de restablecimiento rápido a un lector o punto de conexión de estado |
| `AccessDeniedException` | 403 | Falta token de autenticación | Se ha enviado una solicitud de restablecimiento rápido sin las firmas correctas a un punto de conexión de base de datos con la opción IAM-Auth habilitada |
| `ServerShutdownException` | 500 | El restablecimiento de la base de datos está en curso. Vuelva a intentar la consulta cuando el clúster esté disponible. | Cuando comienza el restablecimiento rápido, se produce un error en las consultas de Gremlin/Sparql existentes y entrantes. |
# Adición de instancias de lector de Neptune a un clúster de base de datos
En clústeres de base de datos de Neptune, hay una instancia de base de datos principal y hasta 15 instancias de lector de Neptune. La instancia principal de base de datos admite operaciones de lectura y escritura y realiza todas las modificaciones de los datos en el volumen del clúster. Las instancias de lector de Neptune se conectan con el mismo volumen de almacenamiento que la instancia de base de datos principal y solo admite operaciones de lectura.
Utilice las instancias de lector para descargar las cargas de trabajo de lectura desde la instancia de base de datos principal.
Le recomendamos que distribuya la instancia principal y los lectores de Neptune del clúster de base de datos entre varias zonas de disponibilidad para mejorar la disponibilidad del clúster de base de datos.
En la [siguiente sección](manage-console-create-replica.md) se describe cómo crear una instancia de lector en el clúster de base de datos.
# Creación de una instancia de lector de Neptune con la consola
Tras crear la instancia principal para el clúster de base de datos de Neptune, puede añadir instancias de lector de Neptune adicionales con la consola de Neptune.
**Para crear una instancia de lector de Neptune con la Consola de administración de AWS**
1. Inicie sesión en la consola de administración de AWS y abra la consola de Amazon Neptune en [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Seleccione el clúster de base de datos en el que desee crear la instancia de lector.
1. Elija **Acciones** y, a continuación, **Añadir lector**.
1. En la página **Crear instancia de base de datos de réplica**, especifique las opciones de la réplica de Neptune. En la siguiente tabla se muestra la configuración de una réplica de lectura de Neptune.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/manage-console-create-replica.html)
1. Elija **Crear réplica de lectura** para crear la instancia de réplica de Neptune.
Para eliminar una instancia de lector de Neptune de un clúster de base de datos, siga las instrucciones de [Eliminar una instancia de base de datos en Amazon Neptune](manage-console-instances-delete.md).
# Modificación de un clúster de base de datos de Neptune con la consola
Al modificar una instancia de base de datos mediante el Consola de administración de AWS, puede optar por aplicar los cambios de inmediato seleccionando **Aplicar inmediatamente**. Si opta por aplicar los cambios inmediatamente, se aplican los nuevos cambios y cualquier cambio de la cola de modificaciones pendientes a la vez.
Si decide no aplicar los cambios inmediatamente, estos se colocan en la cola de modificaciones pendientes. Los cambios pendientes en la cola se aplican durante el siguiente periodo de mantenimiento.
**importante**
Si alguna modificación pendiente requiere un tiempo de inactividad, elegir aplicarlas inmediatamente puede producir un tiempo de inactividad inesperado para la instancia de base de datos en cuestión. No hay tiempo de inactividad para el resto de instancias de base de datos en el clúster de base de datos.
**nota**
Al modificar un clúster de base de datos en Neptune, el ajuste **Aplicar inmediatamente** solo afecta a los cambios realizados en el **Identificador de clúster de base de datos**, **Autenticación de base de datos IAM**. Todas las demás modificaciones se aplican de inmediato, con independencia del valor del ajuste **aplicar inmediatamente**.
**Para modificar un clúster de base de datos mediante la consola**
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 **Clusters (Clústeres)** y elija el clúster de base de datos que desea modificar.
1. Elija **Actions (Acciones)** y, a continuación, **Modify cluster (Modificar clúster)**. Aparece la página **Modificar clúster de base de datos**.
1. Cambie los parámetros que desee.
**nota**
En la consola, algunos cambios en el nivel de instancia solo se aplican a la instancia actual de la base de datos, mientras que otros se aplican a la totalidad del clúster de base de datos. Para cambiar una configuración que modifique todo el clúster de base de datos en el nivel de la instancia en la consola, siga las instrucciones de [Modificación de una instancia de base de datos en un clúster de base de datos](#manage-console-modify-instance).
1. Cuando haya realizado todos los cambios que desee, elija **Continue (Continuar)** y compruebe el resumen.
1. Para aplicar los cambios inmediatamente, seleccione **Apply immediately**.
1. En la página de confirmación, revise los cambios. Si son correctos, elija **Modify clúster (Modificar clúster)** para guardarlos.
Para editar los cambios elija **Back (Atrás)** o para cancelar sus cambios elija **Cancel (Cancelar)**.
## Modificación de una instancia de base de datos en un clúster de base de datos
**Para modificar una instancia de base de datos en un clúster de base de datos con la consola.**
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 **Instances (Instancias)** y, a continuación, seleccione la instancia de base de datos que desea modificar.
1. Elija **Instance actions (Acciones de instancias)** y, a continuación, **Modify (Modificar)**. Aparece la página **Modificar instancia de base de datos**.
1. Cambie los parámetros que desee.
**nota**
Algunos ajustes se aplican a todo el clúster de la base de datos y deben cambiarse a nivel del clúster. Para cambiar dichos ajustes, siga las instrucciones de [Modificación de un clúster de base de datos de Neptune con la consola](#manage-console-modify).
En el Consola de administración de AWS, algunos cambios a nivel de instancia se aplican solo a la instancia de base de datos actual, mientras que otros se aplican a todo el clúster de base de datos.
1. Cuando haya realizado todos los cambios que desee, elija **Continue (Continuar)** y compruebe el resumen.
1. Para aplicar los cambios inmediatamente, seleccione **Apply immediately**.
1. En la página de confirmación, revise los cambios. Si son correctos, elija **Modify DB Instance** para guardarlos.
Para editar los cambios elija **Back (Atrás)** o para cancelar sus cambios elija **Cancel (Cancelar)**.
# Rendimiento y escalado en Amazon Neptune
Los clústeres de base de datos y las instancias de Neptune se escalan en tres niveles diferentes:
+ [Escalado del almacenamiento](#manage-console-performance-scaling-storage)
+ [Escalado de instancia;](#manage-console-performance-scaling-instances)
+ [Escalado de lectura](#manage-console-performance-scaling-reads)
## Escalado del almacenamiento en Neptune
El almacenamiento de Neptune se escala automáticamente con los datos del volumen de clúster. A medida que los datos aumentan, también lo hace el almacenamiento de volumen del clúster, hasta alcanzar 128 TiB en todas las regiones compatibles, excepto en China y GovCloud, donde está limitado a 64 TiB.
El tamaño del volumen de clúster se comprueba cada hora para determinar los costos de almacenamiento.
El almacenamiento consumido por la base de datos de Neptune se factura en incrementos mensuales en GB y las E/S se facturan en incrementos de solicitudes por millón. Solo tiene que pagar por el almacenamiento y las E/S que consuma la base de datos de Neptune y no tiene que hacerlo con antelación.
Para obtener información acerca de los precios, consulte la [página de producto de Neptune](https://aws.amazon.com/neptune/pricing).
## Escalado de instancias en Neptune
Puede escalar el clúster de base de datos de Neptune como considere necesario modificando la clase de instancia de base de datos para cada instancia de base de datos del clúster de base de datos. Neptune admite varias clases de instancias de bases de datos optimizadas.
## Escalado de lectura en Neptune
Puede realizar el escalado de lectura del clúster de base de datos de Neptune creando un máximo de 15 réplicas de Neptune en el clúster de base de datos. Cada réplica de Neptune devuelve los mismos datos desde el volumen de clúster con un retardo de réplica mínimo, a menudo mucho menos de 100 milisegundos una vez que la instancia principal haya escrito una actualización. A medida que el tráfico de lectura aumenta, puede crear réplicas de Neptune adicionales y conectarlas directamente para distribuir la carga de lectura del clúster de base de datos. Las réplicas de Neptune no tienen que ser de la misma clase de instancia de base de datos que la instancia principal.
Para obtener más información acerca de la adición de réplicas de Neptune a un clúster de base de datos, consulte [Adición de instancias de lector](manage-console-create-replica.md).
# Escalado automático del número de réplicas de un clúster de bases de datos de Amazon Neptune
Puede usar el escalado automático de Neptune para ajustar automáticamente el número de réplicas de Neptune en un clúster de base de datos para cumplir con los requisitos de conectividad y carga de trabajo. El escalado automático permite que el clúster de base de datos de Neptune gestione los aumentos de carga de trabajo y, luego, cuando la carga de trabajo disminuye, elimina las réplicas innecesarias, por lo que no tiene que pagar por la capacidad no utilizada.
Solo puede usar el escalado automático con un clúster de base de datos de Neptune que ya tenga una instancia de escritor principal y al menos una instancia de réplica de lectura (consulte [Clústeres e instancias de base de datos de Amazon Neptune](feature-overview-db-clusters.md)). Además, todas las instancias de réplica de lectura del clúster deben estar en un estado disponible. Si alguna réplica de lectura está en un estado distinto al disponible, el ajuste de escalado automático de Neptune no hace nada hasta que estén disponibles todas las réplicas de lectura del clúster.
Si necesita crear un nuevo clúster, consulte [Creación de un clúster de Neptune](get-started-create-cluster.md).
Con la AWS CLI puede definir y aplicar una [política de escalado](#manage-console-autoscaling-define-policy) al clúster de base de datos. También puede utilizar la AWS CLI para editar o eliminar la política de escalado automático. La política especifica los siguientes parámetros de escalado automático:
+ El número mínimo y máximo de réplicas que se van a tener en el clúster.
+ Un intervalo `ScaleOutCooldown` entre la actividad de escalado de adición de réplicas y un intervalo `ScaleInCooldown` entre la actividad de escalado de eliminación de réplicas.
+ La métrica de CloudWatch y el valor del desencadenador de métrica para escalar o reducir verticalmente.
La frecuencia de las acciones de escalado automático de Neptune se reduce de varias maneras:
+ Inicialmente, para que el escalado automático añada o elimine un lector, la alarma de umbral máximo `CPUUtilization` debe superarse durante al menos tres minutos o la alarma de umbral mínimo debe superarse durante al menos 15 minutos.
+ Tras la primera adición o eliminación, la frecuencia de las siguientes acciones de escalado automático de Neptune queda limitada por la configuración `ScaleOutCooldown` y `ScaleInCooldown` de la política de escalado automático.
Si la métrica de CloudWatch que está utilizando alcanza el umbral máximo que especificó en la política, si el intervalo `ScaleOutCooldown` ha transcurrido desde la última acción de escalado automático y si el clúster de base de datos aún no tiene el número máximo de réplicas que estableció, el escalado automático de Neptune crea una nueva réplica con el mismo tipo de instancia que la instancia principal del clúster de base de datos.
Del mismo modo, si la métrica alcanza el umbral mínimo que especificó y si el intervalo `ScaleInCooldown` ha transcurrido desde la última acción de escalado automático, y si el clúster de base de datos tiene más réplicas que el número mínimo que especificó, el escalado automático de Neptune elimina una de las réplicas.
**nota**
Escalado automático de Neptune solo elimina las réplicas que ha creado. No elimina las réplicas preexistentes.
Con el parámetro de clúster de base de datos [neptune\$1autoscaling\$1config](parameters.md#parameters-db-cluster-parameters-neptune_autoscaling_config), también puede especificar el tipo de instancia de las nuevas réplicas de lectura que crea el escalado automático de Neptune, los periodos de mantenimiento de esas réplicas de lectura y las etiquetas que se asociarán a cada una de las nuevas réplicas de lectura. Estos ajustes de configuración se proporcionan en una cadena JSON como valor del parámetro `neptune_autoscaling_config`, tal y como se muestra a continuación:
```
"{
\"tags\": [
{ \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" },
{ \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" },
],
\"maintenanceWindow\" : \"wed:12:03-wed:12:33\",
\"dbInstanceClass\" : \"db.r5.xlarge\"
}"
```
Tenga en cuenta que a todas las comillas de la cadena JSON se les debe aplicar una secuencia de escape con un carácter de barra diagonal inversa (`\`). Todos los espacios en blanco de la cadena son opcionales, como de costumbre.
Cualquiera de los tres ajustes de configuración no especificados en el parámetro `neptune_autoscaling_config` se copia de la configuración de la instancia de escritor principal del clúster de base de datos.
Cuando el [escalado automático](https://docs.aws.amazon.com/autoscaling/plans/userguide/) añade una nueva instancia de réplica de lectura, antepone `autoscaled-reader` al ID de instancia de base de datos (por ejemplo, `autoscaled-reader-7r7t7z3lbd-20210828`). También añade una etiqueta a cada réplica de lectura que cree con la clave `autoscaled-reader` y un valor de `TRUE`. Puede verla en la pestaña **Etiquetas** de la página de detalles de la instancia de base de datos de la Consola de administración de AWS.
```
"key" : "autoscaled-reader", "value" : "TRUE"
```
El nivel de promoción de todas las instancias de réplica de lectura creadas mediante el escalado automático es el de menor prioridad, que, de forma predeterminada es `15`. Esto significa que durante una conmutación por error, cualquier réplica con una mayor prioridad, como una creada manualmente, se promocionaría primero. Consulte [Tolerancia a errores para un clúster de base de datos de Neptune](backup-restore-overview-fault-tolerance.md).
El escalado automático de Neptune se implementa mediante Application Auto Scaling con una [política de escalado de seguimiento de destino](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) que utiliza una métrica de CloudWatch [`CPUUtilization`](cw-metrics.md#cw-metrics-available) en Neptune como métrica predefinida.
## Uso del escalado automático en un clúster de base de datos de Neptune sin servidor
Neptune sin servidor responde mucho más rápido que el escalado automático de Neptune cuando la demanda supera la capacidad de una instancia y escala verticalmente la instancia en lugar de añadir otra. Mientras que el escalado automático se ha diseñado para adaptarse a aumentos o disminuciones relativamente estables de la carga de trabajo, la tecnología sin servidor destaca a la hora de gestionar los picos y fluctuaciones rápidos de la demanda.
Al comprender sus puntos fuertes, puede combinar el escalado automático y la tecnología sin servidor para crear una infraestructura flexible que gestione los cambios en la carga de trabajo de forma eficaz y haga frente a la demanda y, al mismo tiempo, minimice los costos.
Para permitir que el escalado automático funcione de forma eficaz junto con la tecnología sin servidor, es importante [establecer la configuración `maxNCU` del clúster sin servidor](neptune-serverless-capacity-scaling.md#neptune-serverless-capacity-range-max) lo suficientemente alta como para adaptarse a los picos y los cambios breves en la demanda. De lo contrario, los cambios transitorios no desencadenan el escalado sin servidor, lo que puede provocar que el escalado automático genere muchas instancias adicionales innecesarias. Si la opción `maxNCU` está establecida en un nivel lo suficientemente alto, el escalado sin servidor puede gestionar esos cambios de forma más rápida y económica.
## Cómo habilitar el escalado automático para Amazon Neptune
El escalado automático solo se puede habilitar para un clúster de base de datos de Neptune con la AWS CLI. No se puede habilitar el escalado automático con la Consola de administración de AWS.
Además, el escalado automático no se admite en las siguientes regiones de Amazon:
+ África (Ciudad del Cabo): `af-south-1`
+ Medio Oriente (EAU): `me-central-1`
+ AWS GovCloud (EE. UU. Este): `us-gov-east-1`
+ AWS GovCloud (EE. UU. Oeste): `us-gov-west-1`
La habilitación del escalado automático para un clúster de base de datos de Neptune consta de tres pasos:
### 1. Registro de un clúster de base de datos con Application Auto Scaling
El primer paso para habilitar el escalado automático de un clúster de base de datos de Neptune consiste en registrar el clúster con Application Auto Scaling, con la AWS CLI o uno de los SDK de Application Auto Scaling. El clúster ya debe tener una instancia principal y al menos una instancia de lectura de réplica:
Por ejemplo, para registrar un clúster para que se escale automáticamente con de una a ocho réplicas adicionales, puede usar el comando [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) de la AWS CLI de la siguiente manera:
```
aws application-autoscaling register-scalable-target \
--service-namespace neptune \
--resource-id cluster:(your DB cluster name) \
--scalable-dimension neptune:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8
```
Esto equivale a usar la operación de la API de Application Auto Scaling [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html).
El comando `register-scalable-target` de la AWS CLI usa los siguientes parámetros:
+ **`service-namespace`** – establezca en `neptune`.
Este parámetro equivale al parámetro `ServiceNamespace` de la API de Application Auto Scaling.
+ **`resource-id`**: configure esta opción en el identificador de recursos del clúster de base de datos de Neptune. El tipo de recurso es `cluster`, seguido de dos puntos (“`:`”) y, a continuación, el nombre del clúster de base de datos.
Este parámetro equivale al parámetro `ResourceID` de la API de Application Auto Scaling.
+ **`scalable-dimension`**: la dimensión escalable en este caso es el número de instancias de réplica en el clúster de base de datos, por lo que este parámetro está establecido en `neptune:cluster:ReadReplicaCount`.
Este parámetro equivale al parámetro `ScalableDimension` de la API de Application Auto Scaling.
+ **`min-capacity`**: el número mínimo de instancias de réplica de base de datos de lector que Application Auto Scaling va a administrar. Este valor debe establecerse en el rango comprendido entre 0 y 15 y debe ser igual o inferior al valor especificado para el número máximo de réplicas de Neptune en `max-capacity`. Debe haber al menos un lector en el clúster de base de datos para que funcione el escalado automático.
Este parámetro equivale al parámetro `MinCapacity` de la API de Application Auto Scaling.
+ **`max-capacity`**: el número máximo de instancias de réplica de base de datos de lector en el clúster de base de datos, incluidas las instancias preexistentes y las instancias nuevas administradas por Application Auto Scaling. Este valor debe establecerse en el rango comprendido entre 0 y 15 y debe ser igual o superior al valor especificado para el número mínimo de réplicas de Neptune en `min-capacity`.
El parámetro `max-capacity` de la AWS CLI equivale al parámetro `MaxCapacity` de la API de Application Auto Scaling.
Al registrar el clúster de base de datos, Application Auto Scaling crea un rol vinculado a un servicio `AWSServiceRoleForApplicationAutoScaling_NeptuneCluster`. Para obtener más información, consulte [Roles vinculados a servicios para el escalado automático de aplicaciones](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) en la *Guía del usuario de Application Auto Scaling*.
### 2. Definición de una política de escalado automático para su uso con un clúster de base de datos
Una política de escalado de seguimiento de destino se define como un objeto de texto JSON que también se puede guardar en un archivo de texto. En el caso de Neptune, esta política actualmente solo puede utilizar la métrica [`CPUUtilization`](cw-metrics.md#cw-metrics-available) de CloudWatch en Neptune como una métrica predefinida denominada `NeptuneReaderAverageCPUUtilization`.
A continuación se muestra un ejemplo de la política de configuración de escalado de seguimiento de destino para Neptune:
```
{
"PredefinedMetricSpecification": { "PredefinedMetricType": "NeptuneReaderAverageCPUUtilization" },
"TargetValue": 60.0,
"ScaleOutCooldown" : 600,
"ScaleInCooldown" : 600
}
```
Este elemento **`TargetValue`** incluye el porcentaje de utilización de la CPU por encima del cual el escalado automático *se escala horizontalmente* (es decir, añade más réplicas) y por debajo *se escala verticalmente* (es decir, elimina las réplicas). En este caso, el porcentaje de destino que desencadena el escalado es de `60.0` %.
El elemento **`ScaleInCooldown`** especifica la cantidad de tiempo, en segundos, tras completarse un actividad de reducción horizontal antes de que pueda comenzar otra. El valor predeterminado es de 300 segundos. En este caso, el valor de 600 especifica que deben transcurrir al menos diez minutos entre la finalización de la eliminación de una réplica y el inicio de otra.
El elemento **`ScaleOutCooldown`** especifica la cantidad de tiempo, en segundos, tras completarse un actividad de escalado horizontal antes de que pueda comenzar otra. El valor predeterminado es de 300 segundos. En este caso, el valor de 600 especifica que deben transcurrir al menos diez minutos entre la finalización de la adición de una réplica y el inicio de otra.
El elemento **`DisableScaleIn`** es un valor booleano que, si está presente y establecido en `true` deshabilita la reducción horizontal por completo, lo que significa que el escalado automático puede añadir réplicas, pero nunca eliminará ninguna. De forma predeterminada, el escalado interno está habilitado, y el valor `DisableScaleIn` está establecido en `false`.
###
Tras registrar el clúster de base de datos de Neptune con Application Auto Scaling y definir una política de escalado JSON en un archivo de texto, puede aplicar la política de escalado al clúster de base de datos registrado. Puede utilizar el comando [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) de la AWS CLI con los siguientes parámetros:
```
aws application-autoscaling put-scaling-policy \
--policy-name (name of the scaling policy) \
--policy-type TargetTrackingScaling \
--resource-id cluster:(name of your Neptune DB cluster) \
--service-namespace neptune \
--scalable-dimension neptune:cluster:ReadReplicaCount \
--target-tracking-scaling-policy-configuration file://(path to the JSON configuration file)
```
Cuando haya aplicado la política de escalado automático, este se habilitará en el clúster de base de datos.
También puede usar el comando [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) de la AWS CLI para actualizar una política de escalado automático existente.
Consulte también [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) en la *Referencia de la API de Application Auto Scaling*.
## Eliminación del escalado automático de un clúster de base de datos de Neptune
Para eliminar el escalado automático de un clúster de base de datos de Neptune, utilice los comandos [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) y [deregister-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/deregister-scalable-target.html) de la AWS CLI.
# 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).
# Uso de una CloudFormation plantilla para actualizar la versión del motor de su clúster de base de datos Neptune
Puede volver a utilizar la plantilla CloudFormation Neptune que utilizó para crear su clúster de base de datos Neptune para actualizar su versión de motor.
Las actualizaciones de la versión del motor de Neptune pueden ser secundarias o principales. El uso de una CloudFormation plantilla puede ayudarle a realizar actualizaciones importantes de las versiones, que suelen contener cambios importantes. Dado que las actualizaciones principales de la versión pueden incluir cambios realizados en la base de datos que no son compatibles con las versiones anteriores de las aplicaciones, es posible que también necesite realizar cambios realizados en las aplicaciones durante la actualización. Siempre [realice una prueba antes de realizar un actualización](engine-maintenance-management.md#always-test-before-upgrading), y le recomendamos encarecidamente que siempre cree una instantánea manual del clúster de base de datos antes de realizar una actualización.
Tenga en cuenta que debe realizar una actualización del motor independiente para cada versión principal. No puede omitir una versión principal ni actualizarla directamente a la siguiente versión principal siguiente.
Antes del 17 de mayo de 2023, si utilizaba la CloudFormation pila de Neptune para actualizar la versión de su motor, simplemente creaba un nuevo clúster de base de datos vacío en lugar del actual. Sin embargo, a partir del 17 de mayo de 2023, la CloudFormation pila de Neptune ahora admite actualizaciones de motor locales que preservan los datos existentes.
**nota**
Si está utilizando el AWS Cloud Development Kit (AWS CDK), asegúrese de que la AWS CDK versión que se está utilizando sea la 2.82.0 o posterior. Las versiones anteriores a la 2.82.0 no admiten las actualizaciones locales del motor de Neptune.
Para una actualización de una versión principal, la plantilla debe establecer las siguientes propiedades en `DBCluster`:
+ `DBClusterParameterGroup` (personalizado o predeterminado)
+ `DBInstanceParameterGroupName`
+ `EngineVersion`
Del mismo modo, para DBInstances adjuntarlo a, DBCluster debe configurar:
+ `DBParameterGroup` (personalizado/predeterminado)
Asegúrese de que todos los grupos de parámetros estén definidos en la plantilla, ya sean predeterminados o personalizados.
En el caso de un grupo personalizado de parámetros, asegúrese de que la familia del grupo personalizado de existente sea compatible con la nueva versión del motor. Las versiones del motor anteriores a la versión [1.2.0.0](engine-releases-1.2.0.0.md) utilizaban la familia de grupos de parámetros `neptune1`, mientras que las versiones del motor a partir de la versión 1.2.0.0 requieren la familia de grupos de parámetros `neptune1.2`. Para obtener más información, consulte [Grupos de parámetros de Amazon Neptune](parameter-groups.md).
Para las principales actualizaciones de la versión del motor, especifique un grupo de parámetros con la familia adecuada en el campo `DBInstanceParameterGroupName` de `DBCluster`.
El grupo predeterminado de parámetros debe actualizarse a uno que sea compatible con la nueva versión del motor.
Tenga en cuenta que Neptune reinicia automáticamente las instancias de base de datos tras una actualización del motor.
**Topics**
+ [
# Ejemplo: actualización secundaria del motor de la versión 1.2.0.1 a la versión 1.2.0.2
](cfn-engine-update-1201-1202.md)
+ [
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con los grupos de parámetros predeterminados
](cfn-engine-update-1110-1202-default.md)
+ [
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con los grupos de parámetros personalizados
](cfn-engine-update-1110-1202-custom.md)
+ [
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con una combinación de grupos de parámetros predeterminados y personalizados
](cfn-engine-update-1110-1202-mixed.md)
# Ejemplo: actualización secundaria del motor de la versión 1.2.0.1 a la versión 1.2.0.2
Busque el clúster de base de datos que desea actualizar y la plantilla que utilizó para crearlo. Por ejemplo:
```
Description: Base Template to create Neptune Stack with Engine Version 1.2.0.1 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-cluster-parameter-group-description
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-parameter-group-description
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.1
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Actualice la propiedad `EngineVersion` de `1.2.0.1` a `1.2.0.2`:
```
Description: Template to upgrade minor engine version to 1.2.0.2
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-cluster-parameter-group-description
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-parameter-group-description
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Ahora usa CloudFormation para ejecutar la plantilla revisada.
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con los grupos de parámetros predeterminados
Busque el `DBCluster` que desea actualizar y la plantilla que utilizó para crearlo. Por ejemplo:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using default Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Actualice el `DBClusterParameterGroup` predeterminado al de la familia de grupos de parámetros utilizada en la nueva versión del motor (en este caso, `default.neptune1.2`).
+ En cada `DBInstance` asociada al `DBCluster`, actualice el `DBParameterGroup` predeterminado al de la familia utilizada en la nueva versión del motor (en este caso, `default.neptune1.2`).
+ Establezca la propiedad `DBInstanceParameterGroupName` en el grupo predeterminado de parámetros de esa familia (en este caso, `default.neptune1.2`).
+ Actualice la propiedad `EngineVersion` de `1.1.0.0` a `1.2.0.2`.
La plantilla debe tener el siguiente aspecto:
```
Description: Template to upgrade major engine version to 1.2.0.2 by using upgraded default parameter groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName: default.neptune1.2
DBInstanceParameterGroupName: default.neptune1.2
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
```
Ahora se usa CloudFormation para ejecutar la plantilla revisada.
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con los grupos de parámetros personalizados
Busque el `DBCluster` que desea actualizar y la plantilla que utilizó para crearlo. Por ejemplo:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Name: engineupgradetestcpg
Family: neptune1
Description: 'NeptuneDBClusterParameterGroup with family neptune1'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Name: engineupgradetestpg
Family: neptune1
Description: 'NeptuneDBParameterGroup1 with family neptune1'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Actualice la familia `DBClusterParameterGroup` personalizada a la utilizada en la nueva versión del motor (en este caso, `default.neptune1.2`).
+ En cada `DBInstance` asociada al `DBCluster`, actualice la familia `DBParameterGroup` personalizada a la utilizada en la nueva versión del motor (en este caso, `default.neptune1.2`).
+ Establezca la propiedad `DBInstanceParameterGroupName` en el grupo de parámetros de esa familia (en este caso, `default.neptune1.2`).
+ Actualice la propiedad `EngineVersion` de `1.1.0.0` a `1.2.0.2`.
La plantilla debe tener el siguiente aspecto:
```
Description: Template to upgrade major engine version to 1.2.0.2 by modifying existing custom parameter groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Name: engineupgradetestcpgnew
Family: neptune1.2
Description: 'NeptuneDBClusterParameterGroup with family neptune1.2'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Name: engineupgradetestpgnew
Family: neptune1.2
Description: 'NeptuneDBParameterGroup1 with family neptune1.2'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DBInstanceParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Ahora se usa CloudFormation para ejecutar la plantilla revisada.
# Ejemplo: actualización principal de la versión 1.1.1.0 a la versión 1.2.0.2 con una combinación de grupos de parámetros predeterminados y personalizados
Busque el `DBCluster` que desea actualizar y la plantilla que utilizó para crearlo. Por ejemplo:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1
Description: 'NeptuneDBClusterParameterGroup with family neptune1'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1
Description: 'NeptuneDBParameterGroup with family neptune1'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
CustomNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
DefaultNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Para un grupo personalizado de parámetros de clúster, actualice la familia de `DBClusterParameterGroup` a la que corresponda de la nueva versión del motor, es decir, `neptune1.2`.
+ Para un grupo predeterminado de parámetros de clúster, actualice el `DBClusterParameterGroup` a la opción predeterminada que corresponda de la nueva versión del motor, es decir, `default.neptune1.2`.
+ Para cada `DBInstance` asociada a `DBCluster`, actualice un `DBParameterGroup` predeterminado al de la familia utilizada en la nueva versión del motor (en este caso, `default.neptune1.2`) y un grupo personalizado de parámetros a uno que utilice la familia compatible con la nueva versión del motor (en este caso, `neptune1.2`).
+ Establezca la propiedad `DBInstanceParameterGroupName` en el grupo de parámetros de la familia compatible con la nueva versión del motor.
La plantilla debe tener el siguiente aspecto:
```
Description: Template to update Neptune Stack to Engine Version 1.2.0.1 using custom and default Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: 'NeptuneDBClusterParameterGroup with family neptune1.2'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: 'NeptuneDBParameterGroup1 with family neptune1.2'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DBInstanceParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBClusterParameterGroup
CustomNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
DefaultNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Ahora se usa CloudFormation para ejecutar la plantilla revisada.
# Clonación de bases de datos en Neptune
Mediante la clonación de bases de datos, puede crear de una forma rápida y rentable clones de todas las bases de datos en Amazon Neptune. Las bases de datos clonadas requieren un espacio adicional mínimo cuando se crean inicialmente. La clonación de bases de datos utiliza un *protocolo de copia en escritura*. Los datos se copian en el momento en que cambian, tanto en las bases de datos de origen como en las clonadas. Puede crear varios clones partiendo del mismo clúster de base de datos. También puede crear clones adicionales desde otros clones. Para obtener más información acerca del funcionamiento del protocolo de copia en escritura en el contexto del almacenamiento de Neptune, consulte [Protocolo de copia en escritura](#manage-console-cloning-protocol).
Puede usar la clonación de bases de datos en diversos casos de uso, especialmente cuando no desee que su entorno de producción se vea afectado, como por ejemplo en las siguientes situaciones:
+ Experimentar con el impacto de los cambios, como por ejemplo los cambios de esquema o los cambios de grupos de parámetros, y valorar dicho impacto.
+ Realizar operaciones intensivas, como exportar datos o ejecutar consultas analíticas.
+ Crear una copia de un clúster de base de datos de producción en un entorno que no sea de producción para el desarrollo o las pruebas.
**Para crear un clon de un clúster de base de datos con la Consola de administración de AWS**
1. Inicie sesión en la consola de administración de AWS y abra la consola de Amazon Neptune en [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. En el panel de navegación, seleccione **Instances (Instancias)**. Elija la instancia principal del clúster de base de datos del que desea crear un clon.
1. Elija **Instance actions (Acciones de instancias)** y, a continuación, elija **Create clone (Crear clon)**.
1. En la página **Create Clone (Crear clon)**, escriba un nombre para la instancia principal del clúster de base de datos clonado como **DB instance identifier (Identificador de instancias de bases de datos)**.
Si lo desea, configure los demás ajustes del clúster de base de datos clonado. Para obtener información acerca de los distintos ajustes de clúster de base de datos, consulte [Lanzamiento mediante la consola](manage-console-launch-console.md).
1. Elija **Create Clone (Crear clon)** para lanzar el clúster de base de datos clonado.
**Para crear un clon de un clúster de base de datos con la AWS CLI**
+ Llame al comando de la AWS CLI [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) de Neptune y proporcione los siguientes valores:
+ `--source-db-cluster-identifier`: el nombre del clúster de base de datos origen del que desea crear un clon.
+ `--db-cluster-identifier`: el nombre del clúster de base de datos clonado.
+ `--restore-type copy-on-write`: el valor `copy-on-write` indica que se debe crear un clúster de base de datos clonado.
+ `--use-latest-restorable-time`: indica que se utiliza la hora de la última copia de seguridad restaurable.
**nota**
El comando [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) de la AWS CLI solo clona el clúster de la base de datos, no las instancias de base de datos dicho clúster.
El ejemplo siguiente de Linux/UNIX crea un clon a partir del clúster de base de datos `source-db-cluster-id` y le asigna un nombre al clon `db-clone-cluster-id`.
```
aws neptune restore-db-cluster-to-point-in-time \
--region us-east-1 \
--source-db-cluster-identifier source-db-cluster-id \
--db-cluster-identifier db-clone-cluster-id \
--restore-type copy-on-write \
--use-latest-restorable-time
```
El mismo ejemplo funciona en Windows si el carácter de escape del extremo de la línea `\` se sustituye por el `^` equivalente de Windows:
```
aws neptune restore-db-cluster-to-point-in-time ^
--region us-east-1 ^
--source-db-cluster-identifier source-db-cluster-id ^
--db-cluster-identifier db-clone-cluster-id ^
--restore-type copy-on-write ^
--use-latest-restorable-time
```
## Limitaciones
La clonación de bases de datos en Neptune tiene las siguientes limitaciones:
+ No puede crear bases de datos clonadas entre regiones de AWS diferentes. Las bases de datos clonadas se deben crear en la misma región que las bases de datos de origen.
+ Una base de datos clonada siempre utiliza el parche más reciente de la versión del motor de Neptune que utiliza la base de datos a partir del que se ha clonado. Esto se aplica incluso si la base de datos de origen aún no se ha actualizado a esa versión de parche. Sin embargo, la versión del motor no cambia.
+ Por el momento, existe un límite de no más de 15 clones por copia del clúster de base de datos de Neptune, incluidos los clones basados en otros clones. Una vez alcanzado ese límite, debe hacer otra copia de la base de datos en lugar de clonarla. No obstante, si ace una copia nueva, puede tener también hasta 15 clones.
+ La clonación de bases de datos entre varias cuentas no se admite actualmente.
+ Puede proporcionar una Virtual Private Cloud (VPC) diferente para su clon. Sin embargo, las subredes de esas VPC deben estar asignadas al mismo conjunto de zonas de disponibilidad.
## Protocolo de copia en escritura para la clonación de bases de datos
Las siguientes situaciones ilustran el funcionamiento del protocolo de copia en escritura.
+ [Base de datos de Neptune antes de la clonación](#manage-console-cloning-protocol-before)
+ [Base de datos de Neptune después de la clonación](#manage-console-cloning-protocol-after)
+ [Cuando se efectúa un cambio en la base de datos de origen](#manage-console-cloning-protocol-source-write)
+ [Cuando se realiza un cambio en la base de datos clonada](#manage-console-cloning-protocol-clone-write)
### Base de datos de Neptune antes de la clonación
En una base de datos de origen, los datos se almacenan en páginas. En el diagrama siguiente, la base de datos de origen tiene cuatro páginas.
![\[Base de datos de origen de Neptune antes de la clonación de bases de datos con cuatro páginas.\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/neptune-clone-1.png)
### Base de datos de Neptune después de la clonación
Como se muestra en el diagrama siguiente, no se producen cambios en la base de datos de origen después de la clonación. Tanto la base de datos de origen como la base de datos clonada apuntan a las mismas cuatro páginas. Ninguna página se ha copiado físicamente, por lo que no se necesita almacenamiento adicional.
![\[Base de datos de origen de Neptune y base de datos clonada que apuntan a las mismas páginas después de la clonación de bases de datos.\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/neptune-clone-2.png)
### Cuando se efectúa un cambio en la base de datos de origen
En el siguiente ejemplo, la base de datos de origen realiza un cambio en los datos de la `Page 1`. En lugar de escribir en la `Page 1` original, usa almacenamiento adicional para crear una nueva página denominada `Page 1'`. Ahora, la base de datos de origen apunta a la nueva `Page 1'` y también a la `Page 2`, la `Page 3` y la `Page 4`. La base de datos clonada sigue apuntando a la `Page 1` a través de la `Page 4`.
![\[Base de datos de origen de Neptune y base de datos clonada después de los cambios en la base de datos de origen.\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/neptune-clone-3.png)
### Cuando se realiza un cambio en la base de datos clonada
En el siguiente diagrama, la base de datos clonada también ha cambiado, esta vez en la `Page 4`. En lugar de escribir en la `Page 4` original, se usa almacenamiento adicional para crear una nueva página denominada `Page 4'`. La base de datos de origen sigue apuntando a la `Page 1'` y también a la `Page 2` a través de la `Page 4`, pero ahora la base de datos clonada apunta a la `Page 1` a través de la `Page 3` y también de la `Page 4'`.
![\[Base de datos de origen de Neptune y base de datos clonada, después de los cambios en la base de datos clonada.\]](http://docs.aws.amazon.com/es_es/neptune/latest/userguide/images/neptune-clone-4.png)
Como se muestra en la segunda situación, después de la clonación de la base de datos no se requiere almacenamiento adicional en el momento de la creación del clon. Sin embargo, a medida que se producen cambios en la base de datos de origen y en la base de datos clonada, solo se crean las páginas modificadas, como se muestra en las situaciones tercera y cuarta. A medida que se producen más cambios a lo largo del tiempo tanto en la base de datos de origen como en la base de datos clonada, irá necesitando más almacenamiento para capturar y almacenar los cambios.
## Eliminación de una base de datos de origen
La eliminación de una base de datos de origen no afecta a las bases de datos clonadas asociadas a ella. Las bases de datos clonadas siguen apuntando a las páginas que antes pertenecían a la base de datos de origen.
# Administración de instancias de Amazon Neptune
Las siguientes secciones contienen información sobre las operaciones de nivel de instancia.
**Topics**
+ [
# Clase de instancia ampliable de Neptune T3
](manage-console-instances-t3.md)
+ [
# Modificación de una instancia de base de datos de Neptune (y aplicación inmediata)
](manage-console-instances-modify.md)
+ [
# Cambio del nombre de una instancia de base de datos de Neptune
](manage-console-instances-rename.md)
+ [
# Reinicio de una instancia de base de datos en Amazon Neptune
](manage-console-instances-reboot.md)
+ [
# Eliminación de una instancia de base de datos en Amazon Neptune
](manage-console-instances-delete.md)
# Clase de instancia ampliable de Neptune T3
Además de las clases de instancias de rendimiento fijo como `R5` y `R6`, Amazon Neptune le da la opción de usar una instancia `T3` de rendimiento ampliable. Mientras desarrolla la aplicación de gráficos, desea que la base de datos sea rápida y que tenga capacidad de respuesta, pero no necesita usarla todo el tiempo. La clase de instancia `db.t3.medium` de Neptune es justo lo que debería usar en esa situación, a un costo bastante más bajo que la clase de instancia de rendimiento fijo menos costosa.
Las instancias de ráfaga se ejecutan en un nivel de referencia de rendimiento de la CPU hasta que una carga de trabajo necesita más, y entonces rompen la referencia durante tanto tiempo como sea necesario para la carga de trabajo. Su precio por hora cubre las ráfagas, siempre que la utilización media de la CPU no supere la base de referencia durante un periodo de 24 horas. En la mayoría de las situaciones de desarrollo y prueba, eso se traduce en un buen rendimiento a un bajo coste.
Si empieza con una clase de instancia `T3`, más tarde podrá cambiar con facilidad a una clase de instancia de rendimiento fijo cuando esté preparado para entrar en producción mediante la Consola de administración de AWS, la AWS CLI o uno de los SDK de AWS.
## Las ráfagas T3 se rigen por créditos de CPU
Un crédito de CPU representa el uso total de un núcleo de CPU virtual (vCPU) durante un minuto. Esto también puede traducirse como el 50 % del uso de una vCPU durante dos minutos, o un 25 % del uso de dos vCPU durante dos minutos, y así sucesivamente.
Una instancia `T3` acumula créditos de CPU cuando está inactiva y los usa cuando está activa, y lo mide con una resolución de milisegundos. La clase de instancia `db.t3.medium` tiene dos vCPU, cada una de las cuales gana 12 créditos de CPU por hora cuando está inactiva. Esto significa que el 20 % del uso de cada vCPU deriva en un balance de crédito de CPU de cero. Los 12 créditos de CPU obtenidos se emplean en un 20 % del uso de la CPU (ya que el 20 % de 60 minutos también es 12). Este uso del 20 % es, por lo tanto, la tasa de uso *de referencia* que no produce un balance positivo ni negativo de créditos de la CPU.
El tiempo de inactividad (el uso de la CPU inferior al 20 % del total disponible) hace que los créditos de la CPU se almacenen en un depósito de balance de crédito, hasta un límite de 576 (el número máximo de créditos de la CPU que pueden acumularse en 24 horas, es decir, 2 x 12 x 24) para una clase de instancia `db.t3.medium`. Por encima de ese límite, los créditos de CPU simplemente se descartan.
El uso de la CPU puede aumentar hasta un 100 % cuando sea necesario y durante el tiempo requerido para una carga de trabajo, incluso después de que el balance de créditos de la CPU caiga por debajo de cero. Si la instancia mantiene un balance negativo continuo durante 24 horas, incurre en un coste adicional de 0,05 USD por cada -60 créditos de la CPU acumulados durante ese periodo. Sin embargo, en la mayoría de las cargas de trabajo de desarrollo y prueba, la fragmentación suele estar cubierta por el tiempo de inactividad antes o después de la ráfaga.
**nota**
La clase de instancia `T3` de Neptune está configurada como el[modo ilimitado](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) de Amazon EC2.
## Usar la Consola de administración de AWS para crear una instancia de ráfagas T3
En la Consola de administración de AWS, puede crear una instancia de clúster de base de datos principal o una instancia de réplica de lectura que utilice la clase de instancia `db.t3.medium`, o puede modificar una instancia existente para utilizar la clase de instancia `db.t3.medium`.
Por ejemplo, para crear una nueva instancia principal del clúster de base de datos en la consola de Neptune:
+ Elija **Create Database (Crear base de datos)**.
+ Elija una **versión del motor de la base de datos** igual o posterior a `1.0.2.2`.
+ En **Purpose (Finalidad)**, elija **Development and Testing (Desarrollo y pruebas)**.
+ Como **DB Instance class (Clase de instancia de base de datos)**, acepte el valor predeterminado: `db.t3.medium — 2 vCPU, 4 GiB RAM`.
## Usar la AWS CLI para crear una instancia de ráfagas T3
También puede usar la AWS CLI para hacer lo mismo:
```
aws neptune create-db-cluster \
--db-cluster-identifier (name for a new DB cluster) \
--engine neptune \
--engine-version "1.0.2.2"
aws neptune create-db-instance \
--db-cluster-identifier (name of the new DB cluster) \
--db-instance-identifier (name for the primary writer instance in the cluster) \
--engine neptune \
--db-instance-class db.t3.medium
```
# Modificación de una instancia de base de datos de Neptune (y aplicación inmediata)
Puede aplicar la mayoría de cambios a una instancia de base de datos de Amazon Neptune de forma inmediata o retrasarlos hasta el próximo periodo de mantenimiento. Algunas modificaciones, como los cambios de grupo de parámetros, requieren que reinicie manualmente la instancia de base de datos para que el cambio surta efecto.
**importante**
Las modificaciones provocan una interrupción, ya que Neptune debe reiniciar la instancia de base de datos para que el cambio se aplique. Antes de modificar la configuración de una instancia de base de datos, evalúe los efectos que puede tener en la base de datos y en las aplicaciones.
## Configuración común e implicaciones del tiempo de inactividad
La siguiente tabla contiene detalles sobre las opciones que se pueden cambiar, cuándo se pueden aplicar los cambios y si los cambios provocan tiempo de inactividad en la instancia de base de datos.
****
| Configuración de la instancia de base de datos | Notas acerca del tiempo de inactividad |
| --- | --- |
| **DB instance class (Clase de instancia de base de datos)** | Se produce una interrupción durante este cambio, ya sea que se aplique inmediatamente o en el siguiente periodo de mantenimiento. |
| **DB Instance Identifier (Identificador de instancias de bases de datos)** | La instancia de base de datos se reinicia y se produce una interrupción durante este cambio, ya sea que se aplique inmediatamente o en el siguiente periodo de mantenimiento. |
| **Subnet group (Grupo de subredes)** | La instancia de base de datos se reinicia y se produce una interrupción durante este cambio, ya sea que se aplique inmediatamente o en el siguiente periodo de mantenimiento. |
| **Security group (Grupo de seguridad)** | El cambio se aplica de forma asíncrona lo antes posible, independientemente de cuándo especifique que se deben realizar los cambios, y no se produce ninguna interrupción. | – |
| **Certificate Authority (Entidad de certificación)** | De forma predeterminada, la instancia de base de datos se reinicia cuando se asigna una nueva entidad de certificación. |
| **Puerto de base de datos** | El cambio siempre se produce de forma inmediata, lo que provoca que la instancia de base de datos se reinicie y se produzca una interrupción. |
| **Grupo de parámetros de base de datos** | Cambiar este ajuste no produce una interrupción. El nombre del grupo de parámetros se modifica inmediatamente, pero los cambios del parámetro no se aplican hasta que se reinicia la instancia sin conmutación por error. En este caso, la instancia de base de datos no se reiniciará automáticamente y los cambios en los parámetros no se aplicarán en el siguiente periodo de mantenimiento. Sin embargo, si modifica parámetros dinámicos en el grupo de parámetros de base de datos recién asociado, dichos cambios se aplican inmediatamente sin reiniciar. Para obtener más información, consulte [Reinicio de una instancia de base de datos en Amazon Neptune](manage-console-instances-reboot.md). |
| **Grupo de parámetros de clúster de base de datos** | El nombre del grupo de parámetros de base de datos se cambia inmediatamente. |
| **Backup retention period (Periodo de retención de copia de seguridad)** | Si especifica que los cambios deben producirse inmediatamente, este cambio se produce de forma inmediata. De lo contrario, si cambia la configuración de un valor distinto de cero a otro valor distinto de cero, el cambio se aplica de forma asíncrona, tan pronto como sea posible. Cualquier otro cambio se produce en el siguiente periodo de mantenimiento. Se produce una interrupción si se cambia el valor de cero a un valor distinto de cero o de un valor distinto de cero a cero. |
| **Registro de auditoría** | Seleccione **Registro de auditoría** si desea utilizar el registro de auditoría a través de CloudWatch registros. También debe establecer el parámetro `neptune_enable_audit_log` del grupo de parámetros del clúster de base de datos en `enable` (1) para habilitar el registro de auditoría. |
| **Actualización automática de versiones secundarias** | Seleccione **Actualización automática a versiones secundarias** si desea habilitar el clúster de base de datos de Neptune para recibir actualizaciones de las versiones secundarias del motor de base de datos de Neptune automáticamente cuando estén disponibles. La opción *Actualización automática a versiones secundarias* solo es válida para las actualizaciones secundarias de las versiones del motor para el clúster de base de datos de Amazon Neptune. No tiene validez para los parches periódicos que se utilizan para mantener la estabilidad del sistema. |
# Cambio del nombre de una instancia de base de datos de Neptune
Puede cambiar el nombre de una instancia de base de datos de Amazon Neptune mediante la Consola de administración de AWS. Cambiar el nombre de una instancia de base de datos puede tener grandes repercusiones. A continuación, podrá encontrar una lista de consecuencias que debería conocer antes de hacerlo.
+ Cuando cambia el nombre de una instancia de base de datos, se modifica su punto de enlace, porque la URL incluye el nombre asignado a dicha instancia. Deberá redirigir siempre el tráfico desde la URL antigua a la nueva.
+ Si cambia el nombre de una instancia de base de datos, el nombre DNS anterior que utilizaba la instancia se elimina de inmediato, pero puede quedar almacenado en la caché durante varios minutos. El nuevo nombre de DNS de la instancia de base de datos se hace efectivo después de, aproximadamente, 10 minutos. La instancia de base de datos en cuestión no estará disponible hasta que se haga efectivo el nombre nuevo.
+ Si cambia el nombre de una instancia, no puede usar el nombre de una instancia de base de datos existente.
+ Todas las réplicas de lectura asociadas a una instancia de base de datos quedan asociadas a esa instancia después de cambiarle el nombre. Por ejemplo, suponga que tiene una instancia de base de datos que atiende a su base de datos de producción y que esa instancia tiene varias réplicas de lectura asociadas. Si cambia el nombre de la instancia de base de datos y, luego, lo reemplaza en el entorno de producción con una instantánea de base de datos, la instancia de base de datos cuyo nombre cambió sigue teniendo asociadas esas réplicas de lectura.
+ Las métricas y los eventos asociados al nombre de una instancia de base de datos se mantienen si se reutiliza dicho nombre. Por ejemplo, si promociona una réplica de lectura y le asigna el nombre de la instancia de base de datos principal anterior, los eventos y las métricas asociados a esta instancia se asocian a la instancia con el nuevo nombre.
+ Las etiquetas de la instancia de base de datos permanecen con dicha instancia, independientemente del cambio de nombre.
+ Las instantáneas de base de datos se conservan para una instancia de base de datos a la que se le haya cambiado el nombre.
**Para cambiar el nombre de una instancia de base de datos con la consola de Neptune**
1. Inicie sesión en la consola de administración de AWS y abra la consola de Amazon Neptune en [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Seleccione el botón de opción situado junto a la instancia de base de datos cuyo nombre desea cambiar.
1. En el menú **Instance actions (Acciones de instancias)**, elija **Modify (Modificar)**.
1. Escriba un nombre nuevo en el cuadro de texto **DB Instance Identifier (Identificador de instancias de bases de datos)**. Seleccione **Apply immediately (Aplicar inmediatamente)** y, a continuación, elija **Continue (Continuar)**.
1. Elija **Modify DB instance (Modificar instancia de base de datos)** para completar el cambio.
# Reinicio de una instancia de base de datos en Amazon Neptune
En algunos casos, si modifica una instancia de base de datos de Amazon Neptune, cambia el grupo de parámetros de base de datos asociado a la instancia o cambia un parámetro estático de base de datos de un grupo de parámetros utilizado por la instancia, debe reiniciar la instancia para aplicar los cambios.
Cuando se reinicia una instancia de base de datos, se reinicia el servicio del motor de base de datos. El reinicio también aplica a la instancia de base de datos cualquier cambio realizado en el grupo de parámetros de base de datos asociado que estuviera pendiente. Al reiniciar una instancia de base de datos, se produce una interrupción momentánea de la instancia, durante la cual su estado se establece en *rebooting*. Si la instancia de Neptune está configurada para Multi-AZ, el reinicio puede realizarse mediante una conmutación por error. Cuando finaliza el reinicio, se crea un evento de Neptune.
Si la instancia de base de datos es una implementación Multi-AZ, es posible forzar una conmutación por error desde una zona de disponibilidad a otra cuando se elige la opción **Reboot (Reiniciar)**. Cuando se fuerza una conmutación por error de la instancia de base de datos, Neptune cambia automáticamente a una réplica en espera de otra zona de disponibilidad. A continuación, actualiza el registro DNS de la instancia para que apunte a la instancia de base de datos en espera. Como consecuencia, debe eliminar y restablecer las conexiones existentes a la instancia de base de datos.
**Reboot with failover (Reinicio con conmutación por error)** resulta beneficioso cuando se desea simular un error en una instancia de base de datos para realizar pruebas o restaurar operaciones en la zona de disponibilidad original después de que se produzca una conmutación por error. Para obtener más información, consulte [Alta disponibilidad (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) en la *Guía del usuario de Amazon RDS*. Al reiniciar un clúster de base de datos, este conmuta por error a la réplica en espera. El reinicio de una réplica de Neptune no inicia una conmutación por error.
El tiempo necesario para reiniciar es una función del proceso de recuperación tras bloqueo. Para mejorar el tiempo de reinicio, recomendamos reducir las actividades de la base de datos tanto como sea posible durante el proceso de reinicio para reducir la actividad de restauración para las transacciones en tránsito.
En la consola, la opción **Reboot (Reiniciar)** puede estar deshabilitada si la instancia de base de datos no se encuentra en el estado **Available (Disponible)**. Esto puede deberse a varias razones, como un backup en curso, una modificación solicitada por el cliente o una acción durante un periodo de mantenimiento.
**nota**
Antes de [Versión: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), todas las réplicas de lectura de un clúster de base de datos se reiniciaban automáticamente cuando se reiniciaba la instancia principal (escritor).
A partir de [Versión: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), el reinicio de la instancia principal no provoca el reinicio de ninguna de las réplicas. Esto significa que si va a cambiar un parámetro de clúster, debe reiniciar cada instancia por separado para detectar el cambio de parámetro (consulte [Grupos de parámetros](parameter-groups.md)).
**Para reiniciar una instancia de base de datos con la consola de Neptune**
1. Inicie sesión en la consola de administración de AWS y abra la consola de Amazon Neptune en [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Elija la instancia de base de datos que desea reiniciar.
1. Elija **Instance actions** y, a continuación, **Reboot**.
1. Para forzar una conmutación por error de una zona de disponibilidad a otra, seleccione **Reboot with failover? (¿Reiniciar con conmutación por error?)** en el cuadro de diálogo **Reboot DB Instance (Reiniciar instancia de base de datos)**.
1. Elija **Reboot**. Para cancelar el reinicio, elija **Cancel (Cancelar)** en su lugar.
# Eliminación de una instancia de base de datos en Amazon Neptune
Puede eliminar una instancia de base de datos de Amazon Neptune en cualquier estado y en cualquier momento, siempre y cuando la instancia se haya iniciado.
**aviso**
Si elimina la última instancia que queda en un clúster mediante la **consola web**, también se eliminará el volumen de almacenamiento del clúster subyacente.
## Realización de una instantánea final de la instancia de base de datos antes de eliminarla
Para eliminar una instancia de base de datos, debe especificar el nombre de la instancia e indicar si desea crear una instantánea de base de datos final. Si la instancia de base de datos que está eliminando tiene el estado **Creating (Creándose)**, no podrá tomar una instantánea de base de datos final. Si la instancia de base de datos está en un estado de error y tiene el estado **failed**, **incompatible-restore** o **incompatible-network**, solo puede eliminar la instancia cuando el parámetro `SkipFinalSnapshot` esté establecido en `true`.
Si elimina todas las instancias de base de datos de Neptune de un clúster de base de datos mediante el Consola de administración de AWS, todo el clúster de base de datos se elimina automáticamente. Si utiliza el SDK AWS CLI o el SDK, debe eliminar el clúster de base de datos manualmente después de eliminar la última instancia.
**importante**
Si elimina todo un clúster de base de datos, todas sus copias de seguridad automatizadas se eliminarán al mismo tiempo y no se podrán recuperar. Esto significa que, a no ser que decida crear una instantánea de base de datos final, no podrá restaurar posteriormente la instancia de base de datos a su estado final. Las instantáneas manuales de una instancia no se eliminan cuando se elimina el clúster.
Si la instancia de base de datos que desea eliminar tiene una réplica de lectura, debe promocionar la réplica de lectura o eliminarla.
En los siguientes ejemplos, se elimina una instancia de base de datos creando y sin crear una instantánea de base de datos final.
## Eliminación de una instancia de base de datos sin crear una instantánea final
Puede omitir la creación de una instantánea de base de datos final si desea eliminar rápidamente una instancia de base de datos. Al eliminar una instancia de base de datos, se eliminan todas las copias de seguridad automatizadas y no se pueden recuperar. Las instantáneas manuales no se eliminan.
**Para eliminar una instancia de base de datos sin una instantánea de base de datos final 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 **Databases** (Bases de datos).
1. En la lista **Instances (Instancias)**, seleccione el botón de opción situado junto a la instancia de base de datos que desea eliminar.
1. Elija **Instance actions** y, a continuación, **Delete**.
1. Elija **No** en el cuadro de lista desplegable **Create final Snapshot? (¿Crear instantánea final?)**.
1. Elija **Eliminar**.
## Eliminación de una instancia de base de datos creando una instantánea de base de datos final
Si desea poder restaurar más adelante una instancia de base de datos eliminada, puede crear una instantánea de base de datos final. Todas las copias de seguridad automatizadas se eliminan también y no se pueden recuperar. Las instantáneas manuales no se eliminan.
**Para eliminar una instancia de base de datos con una instantánea de base de datos final 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 **Databases** (Bases de datos).
1. En la lista **Instances (Instancias)**, seleccione el botón de opción situado junto a la instancia de base de datos que desea eliminar.
1. Elija **Instance actions** y, a continuación, **Delete**.
1. Elija **Yes (Sí)** en el cuadro **Create final Snapshot? (¿Crear instantánea final?)**.
1. En el cuadro **Final Snapshot name (Nombre de instantánea final)**, escriba el nombre de la instantánea de base de datos final.
1. Elija **Eliminar**.
Puede comprobar el estado de una instancia, determinar qué tipo de instancia es, averiguar qué versión del motor tiene instalada actualmente y obtener otra información sobre una instancia utilizando la [API instance-status](access-graph-status.md).