As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciar o banco de dados do Amazon Neptune
Esta seção mostra como gerenciar e manter seu cluster de banco de dados Neptune usando o Console de gerenciamento da AWS e o. AWS CLI
O Neptune opera em clusters de servidores de banco de dados conectados em uma topologia de replicação. Assim, gerenciar o Neptune normalmente envolve implantar alterações em vários servidores e garantir que todas as réplicas do Neptune estejam acompanhando o servidor primário.
Como o Neptune dimensiona o armazenamento subjacente de forma transparente à medida que os dados crescem, gerenciar o Neptune exige relativamente pouco gerenciamento de armazenamento em disco. Da mesma forma, como o Neptune realiza backups contínuos automaticamente, um cluster do Neptune não exige planejamento extensivo nem tempo de inatividade para realizar backups.
**Topics**
+ [Usando a solução Blue/Green Neptune para realizar atualizações azul-esverdeadas](neptune-BG-deployments.md)
+ [Criar um usuário do IAM com permissões para o Neptune](manage-console-iam-user.md)
+ [Grupos de parâmetros do Amazon Neptune](parameter-groups.md)
+ [Parâmetros do Amazon Neptune](parameters.md)
+ [Iniciando um cluster de banco de dados Neptune usando o Console de gerenciamento da AWS](manage-console-launch-console.md)
+ [Interromper e iniciar um cluster de banco de dados do Amazon Neptune](manage-console-stop-start.md)
+ [Esvaziar um cluster de banco de dados do Amazon Neptune usando a API de redefinição rápida](manage-console-fast-reset.md)
+ [Adicionar instâncias de leitor do Neptune a um cluster de banco de dados](manage-console-add-replicas.md)
+ [Criar uma instância de leitor do Neptune usando o console](manage-console-create-replica.md)
+ [Modificar um cluster de banco de dados do Neptune usando o console](manage-console-modify.md)
+ [Desempenho e escalabilidade no Amazon Neptune](manage-console-performance-scaling.md)
+ [Ajuste de escala automático do número de réplicas em um cluster de banco de dados do Amazon Neptune](manage-console-autoscaling.md)
+ [Manter o cluster de banco de dados do Amazon Neptune](cluster-maintenance.md)
+ [Usando um CloudFormation modelo para atualizar a versão do mecanismo do seu Neptune DB Cluster](cfn-engine-update.md)
+ [Clonagem de banco de dados no Neptune](manage-console-cloning.md)
+ [Gerenciar instâncias do Amazon Neptune](manage-console-instances.md)
# Usando a solução Blue/Green Neptune para realizar atualizações azul-esverdeadas
As atualizações do mecanismo do Amazon Neptune podem precisar de tempo de inatividade da aplicação porque o banco de dados não fica disponível enquanto as atualizações estão sendo instaladas e verificadas. Isso será fato se eles forem iniciados manualmente ou automaticamente.
O Neptune fornece Blue/Green uma solução de implantação que você pode executar usando CloudFormation uma pilha e que reduz consideravelmente esse tempo de inatividade. Ela cria um ambiente de preparação verde que é sincronizado com o ambiente de produção azul. Depois, é possível atualizar esse ambiente de preparação para realizar uma atualização secundária ou principal da versão do mecanismo, uma alteração no modelo de dados de grafos ou uma atualização do sistema operacional e testar o resultado. Por fim, é possível migrá-lo rapidamente para se tornar seu ambiente de produção, com muito pouco tempo de inatividade.
A solução Blue/Green Neptune passa por duas fases, conforme ilustrado neste diagrama:
![\[Fluxograma geral da estratégia de implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/BG-flow.png)
**A fase 1 cria um cluster de banco de dados verde idêntico ao cluster de produção**
A solução cria um cluster de banco de dados com um identificador de blue/green implantação exclusivo e com a mesma topologia de cluster do seu cluster de produção. Ou seja, ele tem o mesmo número e tamanho de instâncias de banco de dados, os mesmos grupos de parâmetros e todas as mesmas configurações do cluster de banco de dados de produção (azul), exceto que ele foi atualizado para a versão do mecanismo de destino que você especificou, que deve ser superior à versão atual do mecanismo (azul). É possível especificar uma versão secundária e principal do mecanismo para o destino. Se necessário, a solução executará todas as atualizações intermediárias necessárias para alcançar a versão especificada do mecanismo de destino. Esse novo cluster se torna o ambiente de preparação verde.
**A fase 2 configura a sincronização contínua de dados**
Depois que o ambiente verde estiver totalmente preparado, a solução vai configurar a replicação contínua entre o cluster de origem (azul) e o cluster de destino (verde) usando fluxos do Neptune. Quando a diferença de replicação entre eles chegar a zero, o ambiente de teste estará pronto para testes. Nesse ponto, você deve pausar a gravação no cluster azul para evitar mais atrasos na replicação.
A versão do mecanismo de destino pode ter novos recursos ou dependências que afetam as aplicações. Confira a página de versão do mecanismo de destino e as páginas de versão do mecanismo de intervenção em [Versões do mecanismo](engine-releases.md) para ver o que mudou desde a versão atual do mecanismo. É melhor executar testes de integração ou verificar as aplicações manualmente no cluster verde antes de promovê-lo ao ambiente de produção.
Depois de testar e qualificar as alterações no cluster verde, basta mudar o endpoint do banco de dados nas aplicações do cluster azul para o verde.
Após a transição, a Blue/Green solução Neptune não exclui o antigo ambiente de produção azul. Você ainda terá acesso a ele para validação e testes adicionais, se necessário. As cobranças de faturamento padrão se aplicam às instâncias até a exclusão. A Blue/Green solução também usa outros AWS serviços, cujos custos são cobrados a preços normais. Os detalhes sobre como excluir a solução quando terminar de usá-la são abordados na [seção sobre limpeza](neptune-BG-cleanup.md).
## Pré-requisitos para executar a pilha Neptune Blue/Green
Antes de lançar a pilha Blue/Green Neptune:
+ [Habilite os fluxos do Neptune](streams-using.md) no cluster de produção (azul).
+ Todas as instâncias no cluster azul devem estar no estado **disponível**. Você pode verificar os estados da instância no console do [Neptune](https://console.aws.amazon.com/neptune) ou usando a API. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html)
+ Todas as instâncias também devem estar sincronizadas com o [grupo de parâmetros do cluster de banco de dados](parameter-groups.md).
+ A solução Blue/Green Neptune requer um endpoint VPC do DynamoDB na VPC em que seu cluster azul está localizado. Consulte [Usar endpoints da Amazon VPC para acessar o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb).
+ Selecione um momento para executar a solução quando a workload de gravação no cluster de banco de dados azul de produção for a mais leve possível. Evite, por exemplo, executar a solução durante um carregamento em massa ou quando houver probabilidade de um grande número de operações de gravação por qualquer outro motivo.
# Usando um CloudFormation modelo para executar a solução Neptune Blue/Green
Você pode usar AWS CloudFormation para implantar a solução Blue/Green Neptune. O CloudFormation modelo cria uma instância do Amazon EC2 na mesma VPC do seu banco de dados Blue Source Neptune, instala a solução lá e a executa. Você pode monitorar seu progresso em CloudWatch registros, conforme explicado em [Monitoramento do progresso](neptune-BG-monitoring.md).
Você pode usar esses links para revisar o modelo de solução ou selecionar o botão **Launch Stack** para iniciá-lo no CloudFormation console:
| | | |
| --- |--- |--- |
| [Visão](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [Visualizar no 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) |
No console, escolha a AWS região em que você deseja executar a solução no menu suspenso no canto superior direito da janela.
Defina os parâmetros da pilha da seguinte forma:
+ **`DeploymentID`**— Um identificador exclusivo para cada implantação do Blue/Green Neptune.
Ele é usado como o identificador verde do cluster de banco de dados e como um prefixo para nomear novos recursos criados durante a implantação.
+ **`NeptuneSourceClusterId`**: o identificador do cluster de banco de dados azul que você deseja atualizar.
+ **`NeptuneTargetClusterVersion:`**: a [versão do mecanismo do Neptune](engine-releases.md) para a qual você deseja atualizar o cluster de banco de dados azul.
Esse valor deve ser mais recente do que a versão do mecanismo atual do cluster de banco de dados azul.
+ **`DeploymentMode`**: indica se essa é uma nova implantação ou uma tentativa de retomar uma implantação anterior. Quando você estiver usando o mesmo `DeploymentID` de uma implantação anterior, defina `DeploymentMode` como `resume`.
Os valores válidos são: `new` (o padrão) e `resume`.
+ **`GraphQueryType`**: o tipo de dados de grafos para o banco de dados.
Os valores válidos são: `propertygraph` (o padrão) e `rdf`.
+ **`SubnetId`**: um ID de sub-rede da mesma VPC em que o cluster de banco de dados azul está localizado. (Consulte [Connecting to a Neptune DB Cluster from an Amazon EC2 instance in the same VPC](get-started-connect-ec2-same-vpc.md).)
Forneça o ID de uma sub-rede pública se você quiser usar o SSH para a instância por meio do [EC2 Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html).
+ **`InstanceSecurityGroup`**: um grupo de segurança para a instância do EC2.
O grupo de segurança deve ter acesso ao cluster de banco de dados azul e você deve poder usar SSH para a instância. Consulte [Criar um grupo de segurança usando o console da VPC](get-started-vpc.md#security-vpc-security-group).
Espere até que a pilha esteja completa. Assim que finalizar, a solução será iniciada. Em seguida, você pode monitorar o processo de implantação usando CloudWatch registros, conforme descrito na próxima seção.
# Monitorando o progresso de uma implantação do Neptune Blue/Green
Você pode monitorar o progresso da solução Blue/Green Neptune acessando o console e examinando [CloudWatch os](https://console.aws.amazon.com/cloudwatch/) registros no `/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch grupo de registros. Você pode encontrar um link para os CloudWatch registros nas saídas da CloudFormation pilha da solução:
![\[Captura de tela da saída da pilha azul/verde CloudFormation\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/BG-stack-output.png)
Se você forneceu uma sub-rede pública como parâmetro de pilha, também poderá usar SSH para a instância do Amazon EC2 criada como parte da pilha e consultar o login em `/var/log/cloud-init-output.log`.
O registro mostra as ações tomadas pela solução Blue/Green Neptune, conforme mostrado nesta captura de tela:
![\[Captura de tela da tela de registro do Neptune Blue/Green\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/BG-log-screenshot.png)
As mensagens de log mostram o status de sincronização entre os clusters azul e verde:
![\[Captura de tela das mensagens de log da solução Blue/Green Neptune\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/BG-log-messages.png)
O processo de sincronização verifica o atraso de replicação calculando a diferença entre o fluxo mais recente `eventID` no cluster azul e o ponto de verificação de replicação presente na tabela de pontos de verificação do DynamoDB criada pela pilha de replicação. Neptune-to-Neptune Usando essas mensagens, é possível monitorar a diferença de replicação atual.
# Passar do cluster azul de produção para o cluster verde atualizado
Antes de promover o cluster verde para produção, garanta que a diferença de confirmação entre os clusters azul e verde seja zero e, depois, desabilite todo o tráfego de gravação no cluster azul. Continuar gravando no cluster azul e alternando o endpoint do banco de dados para o cluster verde pode ocasionar a corrupção de dados causada pela gravação parcial de dados nos dois clusters. Talvez você ainda não precise desabilitar o tráfego de leitura.
Se você habilitou a autenticação do IAM no cluster de origem (azul), atualize todas as políticas do IAM usadas nas aplicações para apontar para o cluster verde (para ver um exemplo dessa política, consulte esta [política de acesso irrestrito](iam-data-access-examples.md#iam-auth-data-policy-example-general)).
Depois de desabilitar o tráfego de gravação, aguarde a conclusão da replicação e habilite o tráfego de gravação no cluster verde (mas não no cluster azul). Também alterne o tráfego de leitura do cluster azul para o verde.
# Limpando após a conclusão da solução Blue/Green Neptune
Depois de promover o cluster de teste (verde) para produção, limpe os recursos criados pela solução Neptune Blue/Green :
+ Exclua a instância do Amazon EC2 que foi criada para executar a solução.
+ Exclua os CloudFormation modelos da replicação [baseada em Neptune Streams](streams-consumer-setup.md) que manteve o cluster verde sincronizado com o cluster azul. O principal tem o nome da pilha que você forneceu anteriormente e o outro é composto pelo ID de implantação seguida por “-replication”: ou seja, `(DeploymentID)-replication`.
A exclusão de CloudFormation modelos não exclui os clusters em si. Depois de verificar se o cluster verde está funcionando conforme o esperado, você pode criar um snapshot antes de excluir manualmente o cluster azul.
# Melhores práticas da solução Blue/Green Neptune
+ Antes de mudar o cluster verde para produção, vale a pena verificar minuciosamente se ele está funcionando da forma correta. Confira a consistência dos dados e a configuração do banco de dados. É possível que algumas das novas versões do mecanismo também exijam atualizações do cliente. Confira as notas de versão do mecanismo antes de fazer a atualização. Vale a pena testar tudo isso em ambientes de desenvolvimento, teste e pré-produção antes de iniciar uma blue/green atualização na produção.
+ É melhor realizar a transição do servidor azul para o verde durante a janela de manutenção.
+ Para garantir que tudo esteja funcionando corretamente após a atualização e a sincronização, vale a pena manter o cluster original por algum tempo antes de excluí-lo. Isso poderá ser útil se surgir um problema imprevisto.
+ Evite operações de gravação pesadas, como cargas em massa, ao executar a solução Blue/Green Neptune, pois elas podem causar atrasos na replicação que introduzem um tempo de inatividade significativo. Preferencialmente, o tempo entre desativar as gravações no cluster azul e ativá-las no cluster verde deve ser de apenas alguns instantes.
# Solução de problemas da solução Neptune Blue/Green
As informações a seguir destacam problemas que podem surgir durante o processo de implantação da Blue/Green solução, como conflitos com clusters existentes, a necessidade de habilitar fluxos do Neptune, operações contínuas de carregamento em massa e requisitos de compatibilidade de versões. Ao abordar esses possíveis problemas, você pode garantir uma implantação tranquila e bem-sucedida da solução Blue/Green Neptune.
**Erros gerados pela solução Neptune Blue/Green**
+ **`Cluster with id = (blue_green_deployment_id) already exists`**— Existe um cluster existente com identificador*(blue\$1green\$1deployment\$1id)*.
Forneça uma nova ID de implantação ou defina o modo de implantação como `resume` se o cluster tivesse sido criado em uma execução anterior do Blue/Green Neptune.
+ **`Streams should be enabled on the source Cluster for Blue Green Deployment`**: ative os [fluxos do Neptune](streams-using-enabling.md) no cluster azul (de origem).
+ **`No Bulkload should be in progress on source cluster: (cluster_id)`**— A solução Blue/Green Neptune termina se identificar uma carga em massa contínua.
O objetivo é garantir que o processo de sincronização seja capaz de acompanhar as gravações feitas. Evite ou cancele qualquer trabalho de carregamento em massa em andamento antes de iniciar a solução Blue/Green Neptune.
+ **`Blue Green deployment requires instances to be in sync with db cluster parameter group`**: qualquer alteração no grupo de parâmetros do cluster deve estar sincronizada em todo o cluster de banco de dados. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md).
+ **`Invalid target engine version for Blue Green Deployment`**: a versão do mecanismo de destino deve estar listada como ativa em [Versões do mecanismo do Amazon Neptune](engine-releases.md) e deve ser superior à versão atual do mecanismo do cluster de origem (azul).
# Criar um usuário do IAM com permissões para o Neptune
Para acessar o console do Neptune para criar e gerenciar um cluster de banco de dados do Neptune, você precisa criar um usuário do IAM com todas as permissões necessárias.
A primeira etapa é criar uma política de perfil vinculado ao serviço para o Neptune:
## Criar uma política de perfil vinculado ao serviço para o Amazon Neptune
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação à esquerda, escolha **Políticas**.
1. Na página **Políticas**, selecione **Criar política**.
1. Na página **Criar política**, selecione a guia **JSON** e copie a seguinte política de perfil vinculado ao serviço:
------
#### [ 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. Selecione **Avançar: Tags** e, na página **Adicionar tags**, selecione **Avançar: Revisão**.
1. Na página **Revisar política**, nomeie a nova política como "NeptuneServiceLinked”.
Para obter mais informações sobre funções vinculadas ao serviço, consulte [Usar perfis vinculados a serviço no Amazon Neptune](security-iam-service-linked-roles.md).
## Criar um usuário do IAM com todas as permissões necessárias
Depois, crie o usuário do IAM com as políticas gerenciadas apropriadas anexadas que concederão as permissões necessárias, junto com a política de perfil vinculado ao serviço que você criou (aqui denominada `NeptuneServiceLinked`):
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação à esquerda, escolha **Usuários** e, na página **Usuários**, selecione **Adicionar usuários**.
1. Na página **Adicionar usuário**, insira um nome para o novo usuário do IAM, escolha **Chave de acesso - Acesso programático** para o tipo de AWS credencial e escolha **Avançar:** Permissões.
1. Na página **Definir permissões**, na caixa **Filtrar políticas**, digite “Neptune”. Agora, selecione o seguinte nas políticas listadas:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**(supondo que seja assim que você chamou a política de função vinculada ao serviço que você criou anteriormente).
1. Depois, digite “VPC” na caixa **Filtrar políticas** no lugar de “Neptune”. Selecione **Amazon VPCFull Access** nas políticas listadas.
1. Selecione **Avançar: Tags** e, na página **Adicionar tags**, selecione **Avançar: Revisão**.
1. Na página de **Revisão**, confira se todas estas políticas estão agora anexadas ao novo usuário:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**
+ **Amazon VPCFull Access**
Depois, selecione **Criar usuário**.
1. Por fim, baixe e salve o ID da chave de acesso e a chave de acesso secreta do novo usuário.
Para interoperar em outros serviços, como o Amazon Simple Storage Service (Amazon S3), você precisará adicionar mais permissões e relações de confiança.
# Grupos de parâmetros do Amazon Neptune
Gerencia a configuração de banco de dados no Amazon Neptune usando [parâmetros](parameters.md) em um grupo de parâmetros. Grupos de parâmetros atuam como *contêineres* de valores de configuração do mecanismo que são aplicados a uma ou mais instâncias de bancos de dados.
Há dois tipos de grupo de parâmetros: de cluster de banco de dados e de banco de dados.
+ Os *grupos de parâmetros de banco de dados* aplicam-se à instância e geralmente estão associados às configurações do mecanismo de grafos do Neptune, como o parâmetro `neptune_query_timeout`.
+ *Os grupos de parâmetros de cluster de banco de dados* aplicam-se a todas as instâncias no cluster e geralmente têm configurações mais amplas. Cada cluster do Neptune é associado a um grupo de parâmetros de cluster de banco de dados. Cada instância de banco de dados dentro desse cluster herda os valores de configuração do mecanismo contidos no grupo de parâmetros de cluster de banco de dados.
Quaisquer valores de configuração que você modificar no grupo de parâmetros de cluster de banco de dados substituirão os valores padrão no grupo de parâmetros de banco de dados. Se você editar os valores correspondentes no grupo de parâmetros de banco de dados, eles substituirão as configurações do grupo de parâmetros de cluster de banco de dados.
Um parameter group de banco de dados padrão será usado se você criar uma instância de banco de dados sem especificar um parameter group de banco de dados personalizado. Não é possível modificar as configurações de parâmetros de um grupo de parâmetros de banco de dados padrão. Em vez disso, para alterar as configurações de parâmetros padrão, é necessário criar um grupo de parâmetros de banco de dados. Nem todos os parâmetros de mecanismo de banco de dados podem ser alterados em um grupo de parâmetros de banco de dados criado por você.
Os grupos de parâmetros são criados em famílias compatíveis com versões específicas do Neptune Engine. Ao atualizar para uma nova versão principal ou secundária do mecanismo, talvez seja necessário recriar seus grupos de parâmetros personalizados usando a família de grupos de parâmetros correspondente para essa versão.
A nomenclatura da família do grupo de parâmetros segue o padrão`neptuneX.Y`, onde `X.Y` corresponde à versão do mecanismo. Por exemplo:
+ `neptune1`— para versões de motor anteriores à 1.2.0.0
+ `neptune1.2`— para as versões 1.2.x do motor
+ `neptune1.3`— para as versões 1.3.x do motor
+ `neptune1.4`— para as versões 1.4.x do motor
Ao atualizar seu cluster Neptune, verifique as notas de [lançamento da versão do](engine-releases.md) mecanismo de destino para determinar se uma nova família de grupos de parâmetros é necessária. Nesse caso, você deve recriar todos os grupos de parâmetros personalizados na nova família antes de fazer o upgrade.
Alguns parâmetros do Neptune são estáticos e outros são dinâmicos. As diferenças são as seguintes:
**Parâmetros estáticos**
+ Parâmetro estático é aquele que tem efeito somente após a reinicialização de uma instância de banco de dados. Em outras palavras, ao alterar um parâmetro estático e salvar o grupo de parâmetros de banco de dados da instância, é necessário reinicializar manualmente a instância de banco de dados para a alteração de parâmetros ter efeito. No momento, todos os parâmetros em nível de instância do Neptune (em um grupo de parâmetros de banco de dados em vez de em um grupo de parâmetros de cluster de banco de dados) são estáticos.
+ Quando você altera um parâmetro estático no cluster e salva o grupo de parâmetros de cluster de banco de dados, a alteração do parâmetro tem efeito depois que você reinicia manualmente cada instância de banco de dados no cluster.
**Parâmetros dinâmicos**
+ Parâmetro dinâmico é aquele que tem efeito quase imediatamente após a atualização dele no grupo de parâmetros. Em outras palavras, não há necessidade de reinicializar uma instância de banco de dados depois de atualizar um parâmetro dinâmico para que a alteração tenha efeito.
+ Espere um pequeno atraso para que a alteração de um parâmetro de cluster dinâmica seja aplicada a todas as instâncias de banco de dados.
+ O valor de um parâmetro dinâmico atualizado não é aplicado às solicitações em execução no momento, mas somente às enviadas após a alteração.
+ Ao alterar um parâmetro dinâmico em nível de cluster, por padrão, a alteração do parâmetro é aplicada ao cluster de banco de dados imediatamente, sem a necessidade de reinicialização. Para adiar a alteração do parâmetro até que as instâncias de banco de dados no cluster sejam reinicializadas, você pode usar o AWS CLI para definir o `ApplyMethod` `pending-reboot` para a alteração do parâmetro.
No momento, todos os parâmetros são estáticos, exceto os seguintes novos parâmetros de cluster:
+ `neptune_enable_slow_query_log` (em nível de cluster)
+ `neptune_slow_query_log_threshold` (em nível de cluster)
Veja a seguir estão alguns pontos importantes que você deve saber sobre como trabalhar com parâmetros em um parameter group de banco de dados:
+ Definir incorretamente os parâmetros em um parameter group de banco de dados pode causar efeitos adversos não intencionais, inclusive diminuição da performance e instabilidade no sistema. Sempre tenha cuidado ao modificar parâmetros de bancos de dados e faça backup dos dados antes de modificar um parameter group de banco de dados. Teste as alterações da configuração do parameter group em uma instância de banco de dados de teste antes de aplicar essas alterações a uma instância de banco de dados de produção.
+ Ao alterar o parameter group de banco de dados associado a uma instância de banco de dados, você deve reinicializar manualmente a instância antes que o novo parameter group de banco de dados seja usado pela instância de banco de dados.
**nota**
Antes de [Versão: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), todas as instâncias de réplica de leitura em um cluster de banco de dados eram reinicializadas automaticamente quando a instância (de gravador) principal era reiniciada.
De [Versão: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md) em diante, reiniciar a instância principal não faz com que nenhuma das instâncias de réplica seja reiniciada. Isso significa que, se você estiver alterando um parâmetro em nível de cluster, deverá reiniciar cada instância separadamente para receber a alteração do parâmetro.
## Edição de um grupo de parâmetros de cluster de banco de dados ou de um grupo de parâmetros de banco de dados
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Selecione **Parameter groups** no painel de navegação.
1. Selecione o link **Name (Nome)** para o parameter group de banco de dados que você deseja editar.
(Opcional) Selecione **Create parameter group (Criar parameter group)** para criar um novo parameter group de cluster e crie o novo grupo. Em seguida, selecione o **Name (Nome)** do novo parameter group.
**Importante**
Essa etapa será *necessária* se você tiver apenas o parameter group padrão de cluster de banco de dados porque o parameter group padrão de cluster de banco de dados não pode ser modificado.
1. Pesquise o parâmetro e clique no campo **Valor** ao lado da coluna **Nome**.
1. Insira o valor permitido e marque a caixa ao lado do campo de valor.
1. Escolha **Salvar alterações**.
1. Reinicialize cada instância de banco de dados no cluster do Neptune se você estiver alterando um parâmetro de cluster de banco de dados, ou uma ou mais instâncias específicas se estiver alterando um parâmetro de instância de banco de dados.
## Criar um grupo de parâmetros de banco de dados ou um grupo de parâmetros de cluster de banco de dados
É possível usar com facilidade o console do Neptune para criar um grupo de parâmetros:
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Escolha **Parameter Groups** no painel de navegação à esquerda.
1. Escolha **Create parameter group de banco de dados (Criar parameter group de banco de dados)**.
A página **Create parameter group de banco de dados (Criar parameter group de banco de dados)** é exibida.
1. ****Na lista **Família de grupos de parâmetros, escolha a família** que corresponde à versão de destino do mecanismo Neptune (por exemplo**, neptune1.2,** neptune1.3 ou neptune1.4).****
1. Na lista **Type (Tipo)**, escolha **DB Parameter Group (Parameter group de banco de dados)** ou **DB Cluster Parameter Group (Parameter group de cluster de banco de dados)**.
1. Digite o nome do novo parameter group de banco de dados na caixa **Group name** (Nome do grupo).
1. Digite uma descrição para o novo parameter group de banco de dados na caixa **Description** (Descrição).
1. Escolha **Criar**.
Também é possível criar um grupo de parâmetros usando 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 do Amazon Neptune
Gerencia a configuração de banco de dados no Amazon Neptune usando parâmetros em [grupo de parâmetros](parameter-groups.md). Os seguintes parâmetros estão disponíveis para configurar o banco de dados do Neptune:
**Parâmetros no nível do cluster**
+ [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 no nível da instância**
+ [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 obsoletos**
+ [neptune\$1enforce\$1ssl](#parameters-db-cluster-parameters-neptune_enforce_ssl)
## `neptune_enable_audit_log` (parâmetro em nível de cluster)
Esse parâmetro alterna o registro em log de auditoria do Neptune.
Os valores permitidos são `0` (desabilitado) e `1` (habilitado). O valor padrão é `0`.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Você pode publicar registros de auditoria na Amazon CloudWatch, conforme descrito em[Usando a CLI para publicar registros de auditoria do Neptune no Logs CloudWatch](cloudwatch-logs.md#cloudwatch-logs-cli).
## `neptune_enable_slow_query_log` (parâmetro em nível de cluster)
Use esse parâmetro para habilitar ou desabilitar o atributo de [registro em log de consultas lentas](slow-query-logs.md) do Neptune.
Esse é um parâmetro dinâmico, o que significa que a alteração do valor não exige nem causa a reinicialização do cluster de banco de dados.
Os valores permitidos são:
+ **`info`**: permite o registro em log de consultas lentas e registra os atributos selecionados que podem estar contribuindo para o baixo desempenho.
+ **`debug`**: permite o registro em log de consultas lentas e registra todos os atributos disponíveis da execução da consulta.
+ **`disabled`**: desabilita o registro em log de consultas lentas.
O valor padrão é `disabled`.
Você pode publicar registros de consultas lentas na Amazon CloudWatch, conforme descrito em. [Usando a CLI para publicar registros de consulta lenta do Neptune no Logs CloudWatch](cloudwatch-logs.md#cloudwatch-slow-query-logs-cli)
## `neptune_slow_query_log_threshold` (parâmetro em nível de cluster)
Esse parâmetro especifica o limite de tempo de execução, em milissegundos, após o qual uma consulta é considerada lenta. Se o [registro em log de consultas lentas](slow-query-logs.md) estiver habilitado, as consultas executadas acima desse limite serão registradas junto com alguns dos atributos.
O valor padrão é cinco mil milissegundos (cinco segundos).
Esse é um parâmetro dinâmico, o que significa que a alteração do valor não exige nem causa a reinicialização do cluster de banco de dados.
## `neptune_lab_mode` (parâmetro em nível de cluster)
Quando definido, esse parâmetro habilita atributos experimentais específicos do Neptune. Consulte [Modo de laboratório do Neptune](features-lab-mode.md) para verificar os recursos experimentais disponíveis no momento.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Para ativar ou desativar um recurso experimental, inclua *(feature name)* `=enabled` ou *(feature name)* `=disabled` nesse parâmetro. Você pode habilitar ou desabilitar vários recursos separando-os com vírgulas, como este:
*(feature \$11 name)*`=enabled,` *(feature \$12 name)*`=enabled`
Os atributos do modo de laboratório geralmente são desabilitados por padrão. Uma exceção é o atributo `DFEQueryEngine`, que foi habilitado por padrão para uso com dicas de consulta (`DFEQueryEngine=viaQueryHint`) a partir da [versão 1.0.5.0 do mecanismo do Neptune](engine-releases-1.0.5.0.md). A partir da [versão 1.1.1.0 do mecanismo do Neptune](engine-releases-1.1.1.0.md), o mecanismo DFE não está mais no modo de laboratório e agora é controlado usando o parâmetro de instância [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) no grupo de parâmetros de banco de dados de uma instância.
## `neptune_query_timeout` (parâmetro em nível de cluster)
Especifica uma duração de tempo limite específica para consultas de grafo, em milissegundos.
Os valores permitidos variam de `10` a `2,147,483,647` (231 - 1). O valor padrão é `120,000` (2 minutos).
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Quando várias configurações de tempo limite são definidas (em nível de cluster, nível de instância e por consulta), a tabela a seguir mostra qual valor de tempo limite tem precedência:
| Cluster de PG | Instância PG | Dica de consulta | Outcome |
| --- | --- | --- | --- |
| Padrão | Padrão | nenhuma | Cluster |
| Personalizada | Padrão | nenhuma | Cluster |
| Personalizada | Personalizada | nenhuma | Instância |
| Padrão | Personalizada | nenhuma | Instância |
| Any | Any | lowest | Consulta |
| Padrão | Personalizada | não é o mais baixo | Instância |
| Personalizada | Padrão | não é o mais baixo | Cluster |
| Personalizada | Personalizada | não é o mais baixo | Instância |
**nota**
Você poderá gerar custos inesperados se definir um valor de tempo limite de consulta muito alto, especialmente em uma instância sem servidor. Sem uma configuração de tempo limite razoável, você poderá emitir acidentalmente uma consulta que continue sendo executada por muito mais tempo do que o esperado, gerando custos jamais previstos. Isso é particularmente o caso em uma instância sem servidor cuja escala pode ser aumentada verticalmente para um tipo de instância grande e caro durante a execução da consulta.
É possível evitar despesas inesperadas desse tipo usando um valor de tempo limite de consulta que acomode a maioria das consultas e ocasione apenas um tempo limite de execução excepcionalmente longo.
## `neptune_streams` (parâmetro em nível de cluster)
Habilita ou desabilita o [Fluxos do Neptune](streams.md).
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Os valores permitidos são `0` (desabilitado, que é o padrão), e `1` (habilitado).
## `neptune_streams_expiry_days` (parâmetro em nível de cluster)
Especifica quantos dias decorrem antes que o servidor exclua os registros de fluxo.
Os valores permitidos são de `1` a `90`. O padrão é `7`.
Esse parâmetro foi apresentado na [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md).
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
## `neptune_lookup_cache` (parâmetro em nível de cluster)
Desabilita ou reabilita o [cache de pesquisa do Neptune](feature-overview-lookup-cache.md) em instâncias `R5d`.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Os valores permitidos são `1` (habilitado) e `0` (desabilitado). O valor padrão é `0`, mas sempre que uma instância `R5d` é criada no cluster de banco de dados, o parâmetro `neptune_lookup_cache` é automaticamente definido como `1` e um cache de pesquisa é criado nessa instância.
## `neptune_autoscaling_config` (parâmetro em nível de cluster)
Define parâmetros de configuração para as instâncias de réplica de leitura que o [ajuste de escala automático do Neptune](manage-console-autoscaling.md) cria e gerencia.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Usando uma string JSON que você define como o valor do parâmetro `neptune_autoscaling_config`, é possível especificar:
+ O tipo de instância que o ajuste de escala automático do Neptune usa para todas as novas instâncias de réplica de leitura que ele cria.
+ As janelas de manutenção atribuídas a essas réplicas de leitura.
+ Tags a serem associadas a todas as novas réplicas de leitura.
A string JSON tem uma estrutura 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\"
}"
```
Observe que as aspas dentro da string devem ter todas um caractere de escape que é uma barra invertida (`\`).
Qualquer uma das três definições de configuração não especificadas no parâmetro `neptune_autoscaling_config` é copiada da configuração da instância de gravador principal do cluster de banco de dados.
## `neptune_ml_iam_role` (parâmetro em nível de cluster)
Especifica o ARN do perfil do IAM usado no Neptune ML. O valor pode ser qualquer ARN de perfil do IAM válido.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
É possível especificar o ARN do perfil do IAM padrão para machine learning em grafos.
## `neptune_ml_endpoint` (parâmetro em nível de cluster)
Especifica o endpoint usado para o Neptune ML. O valor pode ser qualquer [nome de endpoint de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateEndpoint.html#sagemaker-CreateEndpoint-request-EndpointName) válido.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Você pode especificar o endpoint de SageMaker IA padrão para aprendizado de máquina em gráficos.
## `neptune_enable_inline_server_generated_edge_id` (parâmetro em nível de cluster)
Habilite ou desabilite o recurso de ID de borda gerado pelo servidor em linha do Neptune.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Os valores permitidos são `1` (habilitado) e `0` (desabilitado). O valor padrão é `0`.
## `neptune_dfe_query_engine` (parâmetros em nível de instância)
A partir da [versão 1.1.1.0 do mecanismo do Neptune](engine-releases-1.1.1.0.md), esse parâmetro de instância de banco de dados é usado para controlar como o [mecanismo de consulta do DFE](neptune-dfe-engine.md) é usado. Os valores permitidos são os seguintes:
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
+ **`enabled`**: faz com que o mecanismo DFE seja usado sempre que possível, exceto quando a dica de consulta `useDFE` está presente e definida como `false`.
+ **`viaQueryHint`** (o padrão): faz com que o mecanismo DFE seja usado somente para consultas que incluam explicitamente a dica de consulta `useDFE` definida como `true`.
Se esse parâmetro não tiver sido definido explicitamente, o valor padrão, `viaQueryHint`, será usado quando a instância for iniciada.
**nota**
Todas as consultas do openCypher são executadas pelo mecanismo DFE, independentemente de como esse parâmetro é definido.
Antes da versão 1.1.1.0, era um parâmetro de modo de laboratório em vez de um parâmetro de instância de banco de dados.
## `neptune_query_timeout` (parâmetros em nível de instância)
Esse parâmetro de instância de banco de dados especifica uma duração de tempo limite para consultas de grafos, em milissegundos, para uma instância.
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Os valores permitidos variam de `10` a `2,147,483,647` (231 - 1). O valor padrão é `120,000` (2 minutos).
**nota**
Você poderá gerar custos inesperados se definir um valor de tempo limite de consulta muito alto, especialmente em uma instância sem servidor. Sem uma configuração de tempo limite razoável, você poderá emitir acidentalmente uma consulta que continue sendo executada por muito mais tempo do que o esperado, gerando custos jamais previstos. Isso é particularmente o caso em uma instância sem servidor cuja escala pode ser aumentada verticalmente para um tipo de instância grande e caro durante a execução da consulta.
É possível evitar despesas inesperadas desse tipo usando um valor de tempo limite de consulta que acomode a maioria das consultas e ocasione apenas um tempo limite de execução excepcionalmente longo.
## `neptune_result_cache` (parâmetros em nível de instância)
**`neptune_result_cache`**: esse parâmetro de instância de banco de dados habilita ou desabilita [Armazenar em cache os resultados da consulta](gremlin-results-cache.md).
Esse parâmetro é estático, o que significa que as alterações nele não têm efeito em nenhuma instância até que ela seja reinicializada.
Os valores permitidos são `0` (desabilitado, que é o padrão) e `1` (habilitado).
## `UndoLogPurgeConfig` (parâmetros em nível de instância)
**`UndoLogPurgeConfig`**— Use esse parâmetro para ativar ou desativar a UndoLog limpeza agressiva em Neptune.
Os valores permitidos são `default`, que utiliza o número padrão de threads para a limpeza de logs de desfazer e `aggressive`, que usa um número maior de threads para agilizar a limpeza dos logs de desfazer. Quando a opção `agressive` é selecionada, você pode esperar observar um valor maior para a métrica `NumUndoPagesPurged`.
## `neptune_enforce_ssl` (parâmetro em nível de cluster obsoleto)
(**Obsoleto**) Costumava haver regiões que permitiam conexões HTTP com o Neptune, e esse parâmetro era usado para forçar todas as conexões a usarem HTTPS quando definido como 1. No entanto, esse parâmetro não é mais relevante, pois o Neptune agora só aceita conexões HTTPS em todas as regiões.
# Iniciando um cluster de banco de dados Neptune usando o Console de gerenciamento da AWS
A maneira mais fácil de iniciar um novo cluster de banco de dados Neptune é usar CloudFormation um modelo que crie todos os recursos necessários para você, conforme explicado em. [Criar cluster do Neptune](get-started-create-cluster.md)
Se preferir, você também pode usar o console do Neptune para iniciar um novo cluster de banco de dados manualmente, conforme explicado aqui.
**nota**
Para poder acessar o console do Neptune e criar um cluster, você deve ter um usuário com permissões suficientes. Se o usuário atual não tiver essas permissões, você poderá criar e gerenciar um usuário do IAM com todas as permissões necessárias, conforme explicado em [Criar um usuário do IAM com permissões para o Neptune](manage-console-iam-user.md).
Depois de verificar se seu usuário tem as permissões corretas ou se você criou um usuário com as permissões corretas, faça login no Console de gerenciamento da AWS como esse usuário do IAM e siga as etapas abaixo para criar um novo cluster de banco de dados:
**Como iniciar um cluster de banco de dados do Neptune usando o console**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Navegue até a página **Clusters** em **Bancos de dados** e selecione **Criar banco de dados**, que abrirá a página **Criar banco de dados**.
1. Em **Configurações**, insira um nome para o novo cluster de banco de dados ou aceite o nome padrão fornecido. Esse nome é usado no endereço do endpoint da instância e deve atender às seguintes restrições:
+ Deve conter de 1 a 63 caracteres alfanuméricos ou hífens.
+ O primeiro caractere deve ser uma letra.
+ Não pode terminar com um hífen ou conter dois hifens consecutivos.
+ Ele deve ser exclusivo em todas as instâncias de banco de dados em sua AWS conta em uma determinada AWS região.
1. Em **Modelos**, escolha **Produção** ou **Desenvolvimento e teste**.
1. Em **Tamanho da instância de banco de dados**, escolha um tamanho de instância. Isso determinará o processamento e a capacidade da memória da instância de gravação principal do novo cluster de banco de dados.
Se você selecionou o modelo de **produção**, só poderá escolher entre as classes disponíveis com otimização de memória listadas, mas se tiver selecionado **Desenvolvimento e teste**, também poderá escolher entre as classes com capacidade de intermitência mais econômicas (consulte [Instâncias de intermitência T3](manage-console-instances-t3.md) para ver uma discussão sobre classes com capacidade de intermitência).
**nota**
O Neptune não é mais `R4` compatível com tipos de instância.
1. Em **Disponibilidade e durabilidade**, você pode escolher se deseja ou não habilitar a implantação multi-availability-zone (Multi-AZ). O modelo de produção permite a implantação multi-AZ por padrão, enquanto o modelo de desenvolvimento e teste não. Se a implantação Multi-AZ estiver habilitada, o Neptune localizará instâncias de réplica de leitura que você cria em diferentes zonas de disponibilidade () para melhorar a disponibilidade. AZs
1. Em **Conectividade**, selecione a nuvem privada virtual (VPC) que hospedará o novo cluster de banco de dados dentre as opções disponíveis. Aqui é possível escolher **Criar VPC** se quiser que o Neptune crie a VPC. Você deve criar uma instância do Amazon EC2 nessa mesma VPC para acessar a instância do Neptune (para obter mais informações, consulte [Proteger o banco de dados do Amazon Neptune com a Amazon VPC](security-vpc.md)). Observe que não é possível alterar a VPC após a criação do cluster de banco de dados.
Se precisar, você poderá configurar ainda mais a conectividade do cluster em **Configuração de conectividade adicional**:
1. Em **Grupo de sub-redes**, você pode escolher o grupo de sub-redes de banco de dados do Neptune a ser usado para o novo cluster de banco de dados. Se a VPC ainda não tiver grupos de sub-redes, o Neptune criará um grupo de sub-redes de banco de dados para você (consulte [Proteger o banco de dados do Amazon Neptune com a Amazon VPC](security-vpc.md)).
1. Em **Grupos de segurança da VPC**, selecione um ou mais grupos de segurança da VPC existentes para proteger o acesso à rede ao novo cluster de banco de dados ou escolha **Criar novo** se quiser que o Neptune crie um para você e, depois, forneça um nome para o novo grupo de segurança da VPC (consulte [Criar um grupo de segurança usando o console da VPC](get-started-vpc.md#security-vpc-security-group)).
1. Em **Porta do banco** de dados, insira a TCP/IP porta que o banco de dados usará para conexões de aplicativos. O Neptune usa o número da porta `8182` como padrão.
1. Em **Configuração do bloco de anotações**, escolha **Criar bloco de anotações** se quiser que o Neptune crie cadernos Jupyter para você na bancada de trabalho do Neptune (consulte [Usar o Amazon Neptune com cadernos de grafos](graph-notebooks.md) e [Usar a bancada de trabalho do Neptune para hospedar blocos de anotações Neptune](graph-notebooks.md#graph-notebooks-workbench)). Depois, você pode escolher como os novos blocos de anotações devem ser configurados:
1. Em **Tipo de instância de bloco de anotações**, escolha entre as classes de instância disponíveis para o bloco de anotações.
1. Em **Nome do bloco de anotações**, insira um nome para o bloco de anotações.
1. Se quiser, você também poderá inserir uma descrição do bloco de anotações em **Descrição: opcional**.
1. Em **Nome do perfil do IAM**, escolha fazer com que o Neptune crie um perfil do IAM para o bloco de anotações e insira um nome para o novo perfil, ou escolha selecionar um perfil do IAM existente dentre os perfis disponíveis.
1. Por fim, escolha se seu notebook se conecta à Internet diretamente ou por meio da Amazon SageMaker AI ou por meio de uma VPC com um gateway NAT. Consulte [Conectar uma instância do bloco de anotações aos recursos em uma VPC](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html) para obter mais informações.
1. Em **Tags**, é possível associar até cinquenta tags ao novo cluster de banco de dados.
1. Em **Configuração adicional**, há mais configurações que você pode definir para o novo cluster de banco de dados (em muitos casos, você pode ignorá-las e aceitar os valores padrão por enquanto):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/manage-console-launch-console.html)
1. Escolha **Criar banco de dados** para iniciar o novo cluster de banco de dados do Neptune e a instância principal.
No console do Amazon Neptune, o novo cluster de banco de dados é exibido na lista de banco de dados. O cluster de banco de dados tem o status **Creating (Criando)** até que esteja criado e pronto para uso. Quando o status for alterado para **Available (Disponível)**, você poderá se conectar à instância primária do seu cluster de banco de dados. Dependendo da classe da instância de banco de dados e do armazenamento alocado, pode levar alguns minutos até que novas instâncias fiquem disponíveis.
Para visualizar o cluster recém-criado, selecione a exibição de **Bancos de dados** no console do Neptune.
**nota**
Se você excluir todas as instâncias de banco de dados Neptune em um cluster de banco de dados usando Console de gerenciamento da AWS o, o console excluirá automaticamente o próprio cluster de banco de dados. Se você estiver usando o AWS CLI ou SDK, deverá excluir o cluster de banco de dados manualmente depois de excluir sua última instância.
Anote o valor do **Endpoint do cluster**. Você precisará dele para conectar-se ao cluster de banco de dados do Neptune.
# Interromper e iniciar um cluster de banco de dados do Amazon Neptune
Interromper e iniciar os clusters do Amazon Neptune ajuda a gerenciar os custos dos ambientes de teste e de desenvolvimento. Você pode interromper temporariamente todas as instâncias de banco de dados em seu cluster, em lugar de configurar e destruir todas as instâncias cada vez que você usa o cluster.
**Topics**
+ [Visão geral de como interromper e iniciar um cluster de banco de dados do Neptune](#manage-console-start-stop-overview)
+ [Interromper um cluster de banco de dados do Neptune](#manage-console-stopping)
+ [Iniciar um cluster de banco de dados do Neptune interrompido](#manage-console-start)
## Visão geral de como interromper e iniciar um cluster de banco de dados do Neptune
Durante os períodos em que você não precisa de um cluster do Neptune, é possível interromper todas as instâncias nesse cluster de uma só vez. Você pode iniciar o cluster novamente a qualquer momento, sempre que precisar usá-lo. Iniciar e interromper simplifica os processos de configuração e destruição dos clusters usados em desenvolvimento, teste ou atividades afins que não exijam disponibilidade contínua. Você pode fazer isso Console de gerenciamento da AWS com uma única ação, independentemente de quantas instâncias existem no cluster.
Durante a interrupção do cluster de banco de dados, serão cobrados somente o armazenamento do cluster, os snapshots manuais e o armazenamento do backup automático dentro da janela de retenção especificada. Não haverá cobrança por horas de instância de banco de dados.
Após sete dias, o Neptune iniciará automaticamente o cluster de banco de dados novamente para garantir que ele não perca nenhuma atualização de manutenção necessária.
Para minimizar as cobranças em um cluster do Neptune levemente carregado, é possível interromper o cluster em vez de excluir todas as réplicas de leitura dele. Para clusters com mais de uma ou duas instâncias, excluir e recriar frequentemente as instâncias de banco de dados só é prático usando a API ou AWS CLI Neptune, e as exclusões também podem ser difíceis de realizar na ordem correta. Por exemplo, você deve excluir todas as réplicas de leitura antes de excluir a instância principal para evitar que o mecanismo de failover seja ativado.
Não use a interrupção e a inicialização se precisar manter o cluster de banco de dados em execução, mas quiser reduzir a capacidade. Se o cluster for muito caro ou não estiver muito ocupado, você poderá excluir uma ou mais instâncias de banco de dados ou alterar suas instâncias de banco de dados para usar uma classe de instância menor, mas você não poderá interromper uma instância de banco de dados individual.
## Interromper um cluster de banco de dados do Neptune
Quando você não estiver usando um cluster de banco de dados do Neptune por algum tempo, é possível interromper sua execução e iniciá-lo novamente quando precisar dele. Enquanto o cluster estiver parado, serão cobrados o armazenamento do cluster, os snapshots manuais e o armazenamento de backup automático dentro da janela de retenção especificada. As horas de instância de banco de dados não serão cobradas.
A operação de interrupção interrompe todas as instâncias de réplica de leitura do cluster antes de interromper a instância primária para evitar a ativação do mecanismo de failover.
### Interrompendo um cluster de banco de dados usando o Console de gerenciamento da AWS
**Para usar o Console de gerenciamento da AWS para parar um cluster de Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados** e escolha um cluster. Você pode executar a operação de interrupção nesta página ou navegar até a página de detalhes do cluster de banco de dados que você deseja interromper.
1. Em **Actions (Ações)**, escolha **Stop (Interromper)**.
### Interrompendo um cluster de banco de dados usando o AWS CLI
Para interromper uma instância de banco de dados usando o AWS CLI, chame o [stop-db-cluster](api-clusters.md#StopDBCluster)comando, usando o `--db-cluster-identifier` parâmetro para identificar o cluster de banco de dados que você deseja interromper.
**Example**
```
aws neptune stop-db-cluster --db-cluster-identifier mydbcluster
```
### Interromper um cluster de banco de dados usando a API de gerenciamento do Neptune
Para interromper uma instância de banco de dados usando a API de gerenciamento Neptune, chame [a API DBCluster Stop e use o](api-clusters.md#StopDBCluster) parâmetro para identificar `DBClusterIdentifier` o cluster de banco de dados que você deseja interromper.
### O que pode acontecer enquanto um cluster de banco de dados está parado
+ **É possível** restaurá-lo a partir de um snapshot (consulte [Restaurar a partir de um snapshot de cluster de banco de dados](backup-restore-restore-snapshot.md)).
+ **Não é possível** modificar a configuração do cluster de banco de dados ou de qualquer uma de suas instâncias de banco de dados.
+ **Não é possível** adicionar ou remover instâncias de banco de dados do cluster.
+ **Não é possível** excluir o cluster se ele ainda tiver instâncias de banco de dados associadas.
+ Em geral, você deve reiniciar um cluster de banco de dados interrompido para executar a maioria das ações administrativas.
+ O Neptune aplicará as manutenções programadas no cluster interrompido assim que ele for reiniciado. Lembre-se de que, após sete dias, o Neptune reiniciará automaticamente um cluster interrompido para não atrasar demais o status de manutenção.
+ O Neptune não executa o backup automatizado de um cluster de banco de dados interrompido, pois os dados subjacentes não podem ser alterados enquanto o cluster está parado.
+ O Neptune não estende o período de retenção de backup para o cluster de banco de dados enquanto ele está parado.
## Iniciar um cluster de banco de dados do Neptune interrompido
Só é possível iniciar um cluster de banco de dados do Neptune que esteja no estado interrompido. Quando você inicia o cluster, todas as suas instâncias de banco de dados ficam disponíveis novamente. O cluster mantém suas configurações, como endpoints, grupos de parâmetros e grupos de segurança da VPC.
### Iniciando um cluster de banco de dados interrompido usando o Console de gerenciamento da AWS
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados** e escolha um cluster. É possível executar a operação de inicialização nesta página ou navegar até a página de detalhes do cluster de banco de dados e fazer a inicialização nela.
1. Em **Actions (Ações)**, escolha **Start (Iniciar)**.
### Iniciando um cluster de banco de dados interrompido usando o AWS CLI
Para iniciar um cluster de banco de dados interrompido usando o AWS CLI, chame o [start-db-cluster](api-clusters.md#StartDBCluster)comando usando o `--db-cluster-identifier` parâmetro para especificar o cluster de banco de dados interrompido que você deseja iniciar. Forneça o nome do cluster que você escolheu ao criar o cluster de banco de dados ou use um nome de instância de banco de dados que você escolheu, com `-cluster` anexado ao final dele.
**Example**
```
aws neptune start-db-cluster --db-cluster-identifier mydbcluster
```
### Iniciar um cluster de banco de dados interrompido usando a API de gerenciamento do Neptune
Para iniciar um cluster de banco de dados Neptune usando a API de gerenciamento Neptune, chame a API Start usando `DBCluster` o parâmetro para especificar [o](api-clusters.md#StartDBCluster) cluster de banco de dados interrompido que você deseja DBCluster iniciar. Forneça o nome do cluster que você escolheu ao criar o cluster de banco de dados ou use um nome de instância de banco de dados que você escolheu, com `-cluster` anexado ao final dele.
# Esvaziar um cluster de banco de dados do Amazon Neptune usando a API de redefinição rápida
A API REST de redefinição rápida do Neptune permite redefinir um grafo do Neptune com rapidez e facilidade, removendo todos seus dados.
É possível fazê-lo em um bloco de anotações Neptune usando a magia de linha [%db\$1reset](#manage-console-fast-reset-db-reset-magic).
+ Na maioria dos casos, uma operação de redefinição rápida é concluída em alguns minutos. A duração pode variar um pouco dependendo da carga no cluster quando a operação é iniciada.
+ Uma operação de redefinição rápida não gera E/S adicionais.
+ O tamanho do volume de armazenamento não diminui após uma redefinição rápida. Em vez disso, o armazenamento é reutilizado à medida que novos dados são inseridos. Isso significa que os tamanhos dos volumes dos snapshots criados antes e depois de uma operação de redefinição rápida serão os mesmos. Os tamanhos dos volumes dos clusters restaurados usando os snapshots criados antes e depois de uma operação de redefinição rápida também serão os mesmos
+ Como parte da operação de redefinição, todas as instâncias no cluster de banco de dados são reiniciadas.
**nota**
Em raras condições, essas redefinições do servidor também podem ocasionar failover do cluster.
**Importante**
Usar a redefinição rápida pode interromper a integração do cluster de banco de dados do Neptune com outros serviços. Por exemplo:
A redefinição rápida exclui todos os dados de fluxo do banco de dados e redefine completamente os fluxos. Isso significa que os consumidores de fluxos podem não funcionar mais sem uma nova configuração.
A reinicialização rápida remove todos os metadados sobre os recursos de SageMaker IA usados pelo Neptune ML, incluindo trabalhos e endpoints. Eles continuam existindo na SageMaker IA, e você pode continuar usando os endpoints de SageMaker IA existentes para consultas de inferência do Neptune ML, mas o gerenciamento do Neptune ML não funciona mais com eles. APIs
Integrações como a full-text-search integração com também ElasticSearch são eliminadas pela reinicialização rápida e devem ser restabelecidas manualmente antes de poderem ser usadas novamente.
**Como excluir todos os dados de um cluster de banco de dados do Neptune usando a API**
1. Primeiro, você gera um token que pode ser usado para realizar a redefinição do banco de dados. Essa etapa tem como objetivo ajudar a impedir que redefinam acidentalmente um banco de dados.
Você faz isso enviando uma solicitação `HTTP POST` ao endpoint `/system` na instância de gravador do cluster de banco de dados para especificar a ação `initiateDatabaseReset`.
O comando `curl` usando o tipo de conteúdo JSON seria:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{ "action" : "initiateDatabaseReset" }'
```
Ou, usando o tipo de conteúdo `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 '
```
A solicitação `initiateDatabaseReset` exibe o token de redefinição na resposta JSON, da seguinte forma:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
O token permanece válido por uma hora (sessenta minutos) após a emissão.
Se você enviar a solicitação a uma instância de leitor ou ao endpoint de status, o Neptune lançará um `ReadOnlyViolationException`.
Se você enviar várias solicitações `initiateDatabaseReset`, somente o token mais recente gerado será válido para a segunda etapa, na qual você realmente executará a redefinição.
Se o servidor for reiniciado logo após a solicitação `initiateDatabaseReset`, o token gerado se tornará inválido e você precisará enviar uma nova solicitação para obter um novo token.
1. Depois, você envia uma solicitação `performDatabaseReset` com o token recebido de volta de `initiateDatabaseReset` ao endpoint `/system` na instância de gravador do cluster de banco de dados. Isso exclui todos os dados do cluster de banco de dados.
O comando `curl` usando o tipo de conteúdo JSON é:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{
"action" : "performDatabaseReset",
"token" : "token_guid"
}'
```
Ou, usando o tipo de conteúdo `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'
```
A solicitação gera uma resposta JSON. Se a solicitação for aceita, a resposta será:
```
{
"status" : "200 OK"
}
```
Se o token que você enviou não corresponder ao que foi emitido, a resposta será a seguinte:
```
{
"code" : "InvalidParameterException",
"requestId":"token_guid",
"detailedMessage" : "System command parameter 'token' : 'token_guid' does not match database reset token"
}
```
Se a solicitação for aceita e a redefinição começar, o servidor será reiniciado e excluirá os dados. Você não pode enviar nenhuma outra solicitação ao cluster de banco de dados enquanto ele está sendo redefinido.
## Usar a API de redefinição rápida com IAM-Auth
Se você tiver a IAM-Auth habilitada no cluster de banco de dados, poderá usar o [awscurl](https://github.com/okigan/awscurl) para enviar comandos de redefinição rápida que são autenticados usando a IAM-Auth:
**Usar o awscurl para enviar solicitações de redefinição rápida com IAM-Auth**
1. Defina as variáveis de ambiente `AWS_ACCESS_KEY_ID` e `AWS_SECRET_ACCESS_KEY` corretamente (e também `AWS_SECURITY_TOKEN` se você estiver usando uma credencial temporária).
1. Uma solicitação `initiateDatabaseReset` tem a seguinte aparência:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "initiateDatabaseReset" }'
```
1. Uma solicitação `performDatabaseReset` tem a seguinte aparência:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "performDatabaseReset" }'
```
## Usar a magia de linha `%db_reset` da bancada de trabalho do Neptune para redefinir um cluster de banco de dados
A bancada de trabalho do Neptune é compatível com uma magia de linha `%db_reset` que permite realizar uma redefinição rápida do banco de dados em um bloco de anotações Neptune.
Se você invocar a magia sem nenhum parâmetro, verá uma tela perguntando se deseja excluir todos os dados do cluster, com uma caixa de seleção solicitando que você reconheça que os dados do cluster não estarão mais disponíveis após a exclusão. Nesse ponto, é possível optar por excluir os dados ou cancelar a operação.
Uma opção mais perigosa é invocar `%db_reset` com a opção `--yes` ou `-y`, o que faz com que a exclusão seja executada sem nenhuma solicitação adicional.
Você também pode realizar a redefinição em duas etapas, assim como com a API REST:
```
%db_reset --generate-token
```
A resposta é:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
Então faça:
```
%db_reset --token new_token_guid
```
A resposta é:
```
{
"status" : "200 OK"
}
```
## Códigos de erro comuns para operações de redefinição rápida
| Código de erro do Neptune | Status HTTP | Mensagem | Exemplo |
| --- | --- | --- | --- |
| `InvalidParameterException` | 400 | O parâmetro de comando do sistema *action* '' tem valor não suportado '' *XXX* | Parâmetro inválido |
| `InvalidParameterException` | 400 | Muitos valores fornecidos para: *action* | Uma solicitação de reinicialização rápida com mais de uma ação enviada com o cabeçalho x-www-form-urlencoded 'Content-Type:Application/ ' |
| `InvalidParameterException` | 400 | Campo duplicado “ação” | Uma solicitação de redefinição rápida com mais de uma ação enviada com o cabeçalho “Content-Type: application/json”. |
| `MethodNotAllowedException` | 400 | Rota ruim:/*bad\$1endpoint* | Solicitação enviada a um endpoint incorreto |
| `MissingParameterException` | 400 | Parâmetros obrigatórios ausentes: [ação] | Uma solicitação de redefinição rápida não contém o parâmetro “ação” necessário. |
| `ReadOnlyViolationException` | 400 | Não são permitidas gravações em uma instância de réplica de leitura. | Uma solicitação de redefinição rápida foi enviada a um endpoint de status ou de leitor |
| `AccessDeniedException` | 403 | Token de autenticação ausente | Uma solicitação de redefinição foi enviada sem assinaturas corretas a um endpoint de banco de dados com a IAM-Auth habilitada |
| `ServerShutdownException` | 500 | A redefinição do banco de dados está em andamento. Tente fazer a consulta novamente depois que o cluster estiver disponível. | Quando a redefinição rápida começa, ocorre uma falha nas consultas existentes e recebidas do Gremlin/Sparql. |
# Adicionar instâncias de leitor do Neptune a um cluster de banco de dados
Em clusters de banco de dados do Neptune, há uma instância de banco de dados principal e até 15 instâncias de leitor do Neptune. A instância de banco de dados principal oferece suporte a operações de leitura e gravação, além de realizar todas as modificações de dados no volume do cluster. Instâncias de réplica de leitor do Neptune se conectam ao mesmo volume de armazenamento da instância de banco de dados principal e só são compatíveis com operações de leitura.
Use instâncias de leitor para descarregar workloads de leitura da instância de banco de dados principal.
Recomendamos distribuir a instância principal e os leitores do Neptune no cluster de banco de dados em várias zonas de disponibilidade para melhorar a disponibilidade do cluster de banco de dados.
A [seção a seguir](manage-console-create-replica.md) descreve como criar uma instância de leitor no cluster de banco de dados.
# Criar uma instância de leitor do Neptune usando o console
Depois de criar a instância principal para o cluster de banco de dados do Neptune, é possível adicionar outras instâncias de leitor do Neptune usando o console do Neptune.
**Como criar uma instância de leitor do Neptune usando o Console de gerenciamento da AWS**
1. Faça login no Console de Gerenciamento da AWS e abra o console do Amazon Neptune em [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. No painel de navegação, escolha **Bancos de dados**.
1. Selecione o cluster de banco de dados em que deseja criar a instância de leitor.
1. Selecione **Ações** e, depois, **Adicionar leitor**.
1. Na página **Criar instância de banco de dados de réplica**, especifique as opções da réplica do Neptune. A tabela a seguir mostra configurações de uma réplica de leitura do Neptune.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/manage-console-create-replica.html)
1. Selecione **Criar réplica de leitura** para criar a instância de réplica do Neptune.
Para remover uma instância de leitor do Neptune de um cluster de banco de dados, siga as instruções em [Deleting a DB instance in Amazon Neptune](manage-console-instances-delete.md).
# Modificar um cluster de banco de dados do Neptune usando o console
Ao modificar uma instância de banco de dados usando o Console de gerenciamento da AWS, você pode optar por aplicar as alterações imediatamente selecionando **Aplicar imediatamente**. Se você optar por aplicar as alterações imediatamente, as novas alterações e todas as alterações na fila de modificações pendentes serão aplicadas de uma vez.
Se você não optar por aplicar as alterações imediatamente, elas serão colocadas na fila de modificações pendentes. Durante a próxima janela de manutenção, todas as alterações pendentes na fila serão aplicadas.
**Importante**
Se alguma das modificações pendentes exigir tempo de inatividade, escolher aplicar alterações imediatamente poderá causar um tempo de inatividade inesperado para a instância de banco de dados em questão. Não há tempo de inatividade para as outras instâncias de banco de dados no cluster de banco de dados.
**nota**
Ao modificar um cluster de banco de dados no Neptune, a configuração **Aplicar imediatamente** afeta somente as alterações feitas nas configurações **Identificador do cluster de banco de dados** e **Autenticação de banco de dados do IAM**. Todas as outras modificações são aplicadas imediatamente, independentemente do valor da configuração **Apply Immediately (Aplicar imediatamente)**.
**Para modificar um cluster de banco de dados usando o console**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Clusters** e, depois, selecione o cluster de banco de dados que deseja modificar.
1. Escolha **Actions (Ações)** e **Modify cluster (Modificar cluster)**. A página **Modify DB cluster (Modificar cluster de banco de dados)** é exibida.
1. Altere qualquer uma das configurações desejadas.
**nota**
No console, algumas alterações feitas no nível da instância só se aplicam à instância de banco de dados atual, enquanto outras se aplicam a todo o cluster de banco de dados. Para alterar uma configuração que modifica todo o cluster de banco de dados no nível de instância no console, siga as instruções em [Modificar uma instância de banco de dados em um cluster de banco de dados](#manage-console-modify-instance).
1. Quando todas as alterações estiverem conforme o desejado, escolha **Continue (Continuar)** e verifique o resumo.
1. Para aplicar as alterações imediatamente, selecione **Apply immediately (Aplicar imediatamente)**.
1. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha **Modify cluster (Modificar cluster)** para salvar as alterações.
Para editar as alterações, selecione **Back (Voltar)** ou, para cancelar as alterações, escolha **Cancel (Cancelar)**.
## Modificar uma instância de banco de dados em um cluster de banco de dados
**Para modificar uma instância de banco de dados em um cluster de banco de dados usando o console**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, selecione **Instances (Instâncias)** e, em seguida, selecione a instância de banco de dados a ser modificada.
1. Escolha **Instance actions** e, em seguida, escolha **Modify**. A página **Modify DB Instance (Modificar instância de banco de dados)** é exibida.
1. Altere qualquer uma das configurações desejadas.
**nota**
Algumas configurações se aplicam a todo o cluster de banco de dados e devem ser alteradas no nível do cluster. Para alterar essas configurações, siga as instruções em [Modificar um cluster de banco de dados do Neptune usando o console](#manage-console-modify).
No Console de gerenciamento da AWS, algumas alterações no nível da instância se aplicam somente à instância de banco de dados atual, enquanto outras se aplicam a todo o cluster de banco de dados.
1. Quando todas as alterações estiverem conforme o desejado, escolha **Continue (Continuar)** e verifique o resumo.
1. Para aplicar as alterações imediatamente, selecione **Apply immediately (Aplicar imediatamente)**.
1. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha **Modify DB Instance (Modificar instância de banco de dados)** para salvar suas alterações.
Para editar as alterações, selecione **Back (Voltar)** ou, para cancelar as alterações, escolha **Cancel (Cancelar)**.
# Desempenho e escalabilidade no Amazon Neptune
Instâncias e clusters de banco de dados do Neptune são escalados em três níveis diferentes:
+ [Escalar armazenamento](#manage-console-performance-scaling-storage)
+ [Escalabilidade de instâncias;](#manage-console-performance-scaling-instances)
+ [Escalar leitura](#manage-console-performance-scaling-reads)
## Escalabilidade de armazenamento no Neptune
O armazenamento do Neptune é escalado automaticamente com os dados no volume do cluster. À medida que os dados aumentam, o armazenamento do volume do cluster se expande até 128 TiB em todas as regiões compatíveis, exceto na China e na GovCloud, onde é limitado a 64 TiB.
O tamanho do volume do cluster é verificado de hora em hora para determinar os custos de armazenamento.
O armazenamento consumido pelo banco de dados do Neptune é cobrado em incrementos de GB/mês, e as E/S consumidas são cobradas em incrementos de solicitação por milhão. Você paga apenas pelo armazenamento e pelas operações de E/S que o banco de dados do Neptune consome e não é necessário provisionar com antecedência.
Para obter informações sobre preços, consulte a [página sobre o produto do Neptune](https://aws.amazon.com/neptune/pricing).
## Escalabilidade de instâncias no Neptune
É possível escalar o cluster de banco de dados do Neptune, conforme a necessidade, modificando a classe de instância de banco de dados para cada instância de banco de dados do cluster. O Neptune é compatível com várias classes de instâncias de banco de dados otimizadas.
## Escalabilidade de leitura no Neptune
É possível obter escalabilidade de leitura para o cluster de banco de dados do Neptune criando até 15 réplicas do Neptune no cluster de banco de dados. Cada réplica do Neptune exibe os mesmos dados do volume de cluster com atraso de réplica mínimo (geralmente bem inferior a cem milissegundos após a instância principal ter gravado uma atualização). Conforme o tráfego de leitura aumenta, é possível criar mais réplicas do Neptune e conectar-se diretamente a elas para distribuir a carga de leitura para o cluster de banco de dados. As réplicas do Neptune não precisam ser da mesma classe da instância de banco de dados que a instância principal.
Para obter informações sobre como adicionar réplicas do Neptune a um cluster de banco de dados, consulte [Adicionar instâncias de leitor](manage-console-create-replica.md).
# Ajuste de escala automático do número de réplicas em um cluster de banco de dados do Amazon Neptune
É possível usar o ajuste de escala automático do Neptune para ajustar automaticamente o número de réplicas do Neptune em um cluster de banco de dados para atender aos requisitos de conectividade e workload. O ajuste de escala automático permite que o cluster de banco de dados do Neptune processe aumentos na workload e, quando a workload diminui, o ajuste de escala automático remove réplicas desnecessárias para que você não pague pela capacidade não utilizada.
É possível usar o ajuste de escala automático apenas com um cluster de banco de dados do Neptune que já tenha uma instância de gravador principal e pelo menos uma instância de réplica de leitura (consulte [Clusters e instâncias de banco de dados do Amazon Neptune](feature-overview-db-clusters.md)). Além disso, todas as instâncias de réplica de leitura no cluster devem estar em um estado disponível. Se alguma réplica de leitura estiver em um estado diferente de disponível, o ajuste de escala automático do Neptune não fará nada até que todas as réplicas de leitura no cluster estejam disponíveis.
Consulte [Criar cluster do Neptune](get-started-create-cluster.md) se você precisar criar um cluster.
Usando a AWS CLI, defina e aplique uma [política de escalabilidade](#manage-console-autoscaling-define-policy) ao cluster de banco de dados. Você também pode usar a AWS CLI para editar ou excluir a política de ajuste de escala automático. A política especifica os seguintes parâmetros de ajuste de escala automático:
+ O número mínimo e máximo de réplicas a serem mantidas no cluster.
+ Um intervalo `ScaleOutCooldown` entre a atividade de escalabilidade de adição de réplicas e um intervalo `ScaleInCooldown` entre a atividade de escalabilidade de exclusão de réplicas.
+ A métrica do CloudWatch e o valor de gatilho da métrica para aumentar ou reduzir a escala verticalmente.
A frequência das ações de ajuste de escala automático do Neptune é reduzida de várias maneiras:
+ Inicialmente, para que o ajuste de escala automático adicione ou exclua um leitor, o alarme alto `CPUUtilization` deve ser violado por pelo menos três minutos ou o alarme baixo deve ser violado por pelo menos 15 minutos.
+ Após a primeira adição ou exclusão, a frequência das ações subsequentes de ajuste de escala automático do Neptune é limitada pelas configurações `ScaleOutCooldown` e `ScaleInCooldown` na política de ajuste de escala automático.
Se a métrica do CloudWatch que você está usando atingir o limite alto especificado na política e se o intervalo `ScaleOutCooldown` tiver decorrido desde a última ação de ajuste de escala automático e o cluster de banco de dados ainda não tiver o número máximo de réplicas definido, o ajuste de escala automático do Neptune criará uma réplica usando o mesmo tipo da instância principal do cluster de banco de dados.
Da mesma forma, se a métrica atingir o limite baixo especificado e se o intervalo `ScaleInCooldown` tiver decorrido desde a última ação de ajuste de escala automático, e se o cluster de banco de dados tiver mais do que o número mínimo de réplicas especificado, o ajuste de escala automático do Neptune excluirá uma das réplicas.
**nota**
O ajuste de escala automático do Neptune remove somente as réplicas criadas. Ele não remove réplicas preexistentes.
Usando o parâmetro de cluster de banco de dados [neptune\$1autoscaling\$1config](parameters.md#parameters-db-cluster-parameters-neptune_autoscaling_config), também é possível especificar o tipo de instância das novas réplicas de leitura criadas pelo ajuste de escala automático do Neptune, as janelas de manutenção dessas réplicas de leitura e as tags a serem associadas a cada uma das novas réplicas de leitura. Você fornece essas configurações em uma string JSON como o valor do parâmetro `neptune_autoscaling_config`, desta forma:
```
"{
\"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\"
}"
```
Observe que as aspas dentro da string JSON devem ter todas um caractere de escape que é uma barra invertida (`\`). Todos os espaços em branco na string são opcionais, como de costume.
Qualquer uma das três definições de configuração não especificadas no parâmetro `neptune_autoscaling_config` é copiada da configuração da instância de gravador principal do cluster de banco de dados.
Quando o [ajuste de escala automático](https://docs.aws.amazon.com/autoscaling/plans/userguide/) adiciona uma nova instância de réplica de leitura, ele inclui no ID da instância de banco de dados o prefixo `autoscaled-reader` (por exemplo, `autoscaled-reader-7r7t7z3lbd-20210828`). Ele também adiciona uma tag a cada réplica de leitura criada com a chave `autoscaled-reader` e um valor de `TRUE`. É possível visualizar essa tag na guia **Tags** da página de detalhes da instância de banco de dados no Console de gerenciamento da AWS.
```
"key" : "autoscaled-reader", "value" : "TRUE"
```
O nível de promoção de todas as instâncias de réplica de leitura criadas pelo ajuste de escala automático é o de menor prioridade, que é `15` por padrão. Isso significa que, durante um failover, qualquer réplica com uma prioridade maior, como uma criada manualmente, será promovida primeiro. Consulte [Tolerância a falhas para um cluster de banco de dados do Neptune](backup-restore-overview-fault-tolerance.md).
O ajuste de escala automático do Neptune é implementado usando o Application Auto Scaling com uma [política de escalabilidade de rastreamento de destino](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) que usa uma métrica do CloudWatch [`CPUUtilization`](cw-metrics.md#cw-metrics-available) do Neptune como métrica predefinida.
## Usar o ajuste de escala automático em um cluster de banco de dados sem servidor do Neptune
O Neptune Serverless responde com uma velocidade muito maior do que o ajuste de escala automático do Neptune quando a demanda excede a capacidade de uma instância e aumenta a escala da instância verticalmente em vez de adicionar outra instância. Enquanto o ajuste de escala automático é projetado para corresponder a aumentos ou diminuições relativamente estáveis na workload, a tecnologia sem servidor é excelente para lidar com picos rápidos e oscilações na demanda.
Compreendendo os pontos fortes, você pode combinar o ajuste de escala automático e a tecnologia sem servidor para criar uma infraestrutura flexível que lidará com as mudanças na workload com eficiência e atenderá à demanda minimizando os custos.
Para permitir que o ajuste de escala automático funcione com eficiência com a tecnologia sem servidor, é importante [definir a configuração do `maxNCU` do cluster sem servidor](neptune-serverless-capacity-scaling.md#neptune-serverless-capacity-range-max) alta o suficiente para acomodar picos e breves mudanças na demanda. Caso contrário, alterações transitórias não acionam a escalabilidade sem servidor, o que pode fazer com que o ajuste de escala automático gere muitas instâncias adicionais desnecessárias. Se o `maxNCU` estiver definido como alto o suficiente, o ajuste de escala automático sem servidor pode lidar com essas alterações de forma mais rápida e econômica.
## Como habilitar o ajuste de escala automático do Amazon Neptune
O ajuste de escala automático só pode ser habilitado para um cluster de banco de dados do Neptune usando a AWS CLI. Não é possível habilitar o ajuste de escala automático usando o. Console de gerenciamento da AWS.
Além disso, o ajuste de escala automático não é compatível com as seguintes regiões da Amazon:
+ África (Cidade do Cabo): `af-south-1`
+ Oriente Médio (Emirados Árabes Unidos): `me-central-1`
+ AWS GovCloud (Leste dos EUA): `us-gov-east-1`
+ AWS GovCloud (Oeste dos EUA): `us-gov-west-1`
Habilitar o ajuste de escala automático para um cluster de banco de dados do Neptune envolve três etapas:
### 1. Registrar o cluster de banco de dados com o Application Auto Scaling
A primeira etapa para habilitar o ajuste de escala automático para um cluster de banco de dados do Neptune é registrar o cluster no Application Auto Scaling usando a AWS CLI ou um dos SDKs do Application Auto Scaling. O cluster já deve ter uma instância principal e pelo menos uma instância de réplica de leitura:
Por exemplo, para registrar um cluster para ser escalado automaticamente com de uma a oito réplicas adicionais, é possível usar o 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) da AWS CLI da seguinte forma:
```
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
```
Isso equivale a usar a operação da API [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html) do Application Auto Scaling.
O comando `register-scalable-target` da AWS CLI usa os seguintes parâmetros:
+ **`service-namespace`** – defina como `neptune`.
Esse parâmetro equivale ao parâmetro `ServiceNamespace` na API do Application Auto Scaling.
+ **`resource-id`**: defina como o identificador de recurso do cluster de banco de dados do Neptune. O tipo de recurso é `cluster`, seguido por dois pontos (“`:`“) e, depois, pelo nome do cluster de banco de dados.
Esse parâmetro equivale ao parâmetro `ResourceID` na API do Application Auto Scaling.
+ **`scalable-dimension`**: a dimensão escalável nesse caso é o número de instâncias de réplica no cluster de banco de dados, então você define esse parâmetro como `neptune:cluster:ReadReplicaCount`.
Esse parâmetro equivale ao parâmetro `ScalableDimension` na API do Application Auto Scaling.
+ **`min-capacity`**: o número mínimo de instâncias de réplica de banco de dados de leitor a serem gerenciadas pelo Application Auto Scaling. Esse valor deve ser definido no intervalo de 0 a 15 e deve ser igual ou menor que o valor especificado para o número máximo de réplicas do Neptune em `max-capacity`. Deve haver pelo menos um leitor no cluster de banco de dados para que o ajuste de escala automático funcione.
Esse parâmetro equivale ao parâmetro `MinCapacity` na API do Application Auto Scaling.
+ **`max-capacity`**: o número máximo de instâncias de réplicas de banco de dados de leitor no cluster de banco de dados, incluindo instâncias preexistentes e novas instâncias gerenciadas pelo Application Auto Scaling. Esse valor deve ser definido entre 0 e 15 e deve ser igual ou maior que o valor especificado para o número mínimo de réplicas do Neptune em `min-capacity`.
O parâmetro `max-capacity` da AWS CLI equivale ao parâmetro `MaxCapacity` na API do Application Auto Scaling.
Quando você registra o cluster de banco de dados, o Application Auto Scaling cria um perfil vinculado ao serviço `AWSServiceRoleForApplicationAutoScaling_NeptuneCluster`. Para obter mais informações, consulte [Service-linked roles for Application auto-scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html), no *Guia do usuário do Application Auto Scaling*.
### 2. Definir uma política de ajuste de escala automático a ser usada com o cluster de banco de dados
Uma política de escalabilidade de rastreamento de destino é definida como um objeto de texto JSON que também pode ser salvo em um arquivo de texto. Para o Neptune, essa política atualmente só pode usar a métrica do CloudWatch [`CPUUtilization`](cw-metrics.md#cw-metrics-available) no Neptune como uma métrica predefinida chamada `NeptuneReaderAverageCPUUtilization`.
Veja um exemplo de política de configuração de escalabilidade de rastreamento de destino para o Neptune:
```
{
"PredefinedMetricSpecification": { "PredefinedMetricType": "NeptuneReaderAverageCPUUtilization" },
"TargetValue": 60.0,
"ScaleOutCooldown" : 600,
"ScaleInCooldown" : 600
}
```
O elemento **`TargetValue`** aqui contém a porcentagem de utilização da CPU acima da qual o ajuste de escala automático *se expande* (ou seja, adiciona mais réplicas) e abaixo da qual ele *é reduzido* (ou seja, exclui réplicas). Nesse caso, a porcentagem de destino que aciona a escalabilidade é `60.0`%.
O elemento **`ScaleInCooldown`** especifica a quantidade de tempo, em segundos, após a conclusão de redução da escala antes que outra redução possa ser iniciada. O padrão é trezentos segundos. Aqui, o valor de seiscentos especifica que devem decorrer pelo menos dez minutos entre a conclusão de uma exclusão de réplica e o início de outra.
O elemento **`ScaleOutCooldown`** especifica a quantidade de tempo, em segundos, após a conclusão de expansão da escala antes que outra expansão possa ser iniciada. O padrão é trezentos segundos. Aqui, o valor de seiscentos especifica que devem decorrer pelo menos dez minutos entre a conclusão de uma adição de réplica e o início de outra.
O elemento **`DisableScaleIn`** é um valor booliano que, se estiver presente e definido como `true` desabilitará totalmente a redução da escala, o que significa que o ajuste de escala automático poderá adicionar réplicas, mas nunca removerá nenhuma. Por padrão, a redução da escala está habilitada e `DisableScaleIn` é `false`.
###
Depois de registrar o cluster de banco de dados do Neptune com o Application Auto Scaling e definir uma política de escalabilidade JSON em um arquivo de texto, aplique a política de escalabilidade ao cluster de banco de dados registrado. É possível fazer isso usando o 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) da AWS CLI com parâmetros da seguinte forma:
```
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)
```
Quando você aplica a política de ajuste de escala automático, o ajuste de escala automático é habilitado no cluster de banco de dados.
Você também pode usar o 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) da AWS CLI para atualizar uma política de ajuste de escala automático existente.
Consulte também [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) na *Referência de API do Application Auto Scaling*.
## Remover o ajuste de escala automático de um cluster de banco de dados do Neptune
Para remover o ajuste de escala automático de um cluster de banco de dados do Neptune, use os comandos [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) e [deregister-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/deregister-scalable-target.html) da AWS CLI.
# Manter o cluster de banco de dados do Amazon Neptune
O Neptune realiza manutenção periódica em todos os recursos que usa, incluindo:
+ **Substituir o hardware subjacente conforme necessário.** Isso acontece em segundo plano, sem que você precise realizar nenhuma ação e geralmente não afeta as operações.
+ **Atualizar o sistema operacional subjacente.** As atualizações do sistema operacional das instâncias no cluster de banco de dados são realizadas para melhorar o desempenho e a segurança. Portanto, você deve concluí-las o mais rápido possível. Em geral, essas atualizações demoram cerca de dez minutos. As atualizações do sistema operacional não alteram a versão do mecanismo de banco de dados nem a classe de uma instância de banco de dados.
Em geral, é melhor atualizar primeiro as instâncias do leitor em um cluster de banco de dados e depois a instância do gravador. Atualizar os leitores e o gravador ao mesmo tempo pode causar um período de inatividade no caso de um failover. O backup das instâncias de banco de dados não é feito automaticamente antes de uma atualização do sistema operacional. Dessa forma, faça backups manuais antes de aplicar uma atualização do sistema operacional.
+ **Atualizar o mecanismo do banco de dados Neptune.** O Neptune lança regularmente uma variedade de atualizações do mecanismo para introduzir novos recursos e melhorias e corrigir bugs.
## Números das versões do mecanismo
### Numeração de versão antes da versão 1.3.0.0 do mecanismo
Antes de novembro de 2019, o Neptune era compatível apenas com uma versão do mecanismo por vez, e os números de versão do mecanismo tinham todos o mesmo formato, `1.0.1.0.200`, em que `xxx` era o número do patch. As novas versões do mecanismo foram todas lançadas como patches para versões anteriores.
Em novembro de 2019, o Neptune passou a ser compatível com várias versões, oferecendo aos clientes um melhor controle dos caminhos de atualização. Consequentemente, a numeração de versões do mecanismo foi alterada.
De novembro de 2019 até a [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md), os números de versão tinham cinco partes. Por exemplo, no número de versão `1.0.2.0.R2`:
+ A primeira parte sempre foi 1.
+ A segunda parte, (`0` em `1.0.2.0.R2`), era o número da versão principal do banco de dados.
+ A terceira e a quarta parte, (`2.0` em `1.0.2.0.R2`), eram números de versão secundária.
+ A quinta parte, (`R2` em `1.0.2.0.R2`), era o número do patch.
A maioria das atualizações era atualizações de patches, e a distinção entre patches e atualizações de versões secundárias nem sempre era clara.
### Numeração de versão a partir da versão 1.3.0.0 do mecanismo
A partir da [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md), o Neptune mudou a forma como as atualizações do mecanismo são numeradas e gerenciadas.
Os números de versão do mecanismo agora têm quatro partes, cada uma correspondendo a um tipo de versão, da seguinte forma:
*product-version***.***major-version***.***minor-version***.***patch-version*
Alterações ininterruptas do tipo que foram lançadas anteriormente como patches agora são lançadas como versões secundárias que você pode gerenciar usando a configuração da instância [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu).
Isso significa que, se você quiser, poderá receber uma notificação sempre que uma nova versão secundária for lançada, basta assinar o evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Assinar a notificação de eventos do Neptune](events-subscribing.md)).
As versões de patches agora estão reservadas para correções direcionadas urgentes e são numeradas usando a última parte do número da versão (`*.*.*.1`, `*.*.*.2` e assim por diante).
# Diferentes tipos de versões do mecanismo no Amazon Neptune
Os quatro tipos de versão do mecanismo que correspondem às quatro partes de um número de versão do mecanismo são os seguintes:
+ **Versão do produto**: é alterada somente se o produto passar por mudanças amplas e fundamentais na funcionalidade ou interface. A versão atual do produto Neptune é 1.
+ [**Versão principal**](#major-versions): a versões principais introduzem novos recursos importantes e mudanças significativas e geralmente têm uma vida útil de pelo menos dois anos.
+ [**Versão secundária**](#minor-versions): as versões secundárias podem conter novos recursos, melhorias e correções de erros, mas não contêm alterações significativas. Você pode escolher se deseja ou não que sejam aplicadas automaticamente durante a próxima janela de manutenção, além de optar por receber uma notificação sempre que for lançada.
+ [**Versão de patch**](#patch-version-updates): as versões de patch são lançadas somente para tratar de correções de erros urgentes ou atualizações críticas de segurança. Raramente contêm alterações significativas e são aplicadas automaticamente durante a próxima janela de manutenção após o lançamento.
## Atualizações da versão principal do Amazon Neptune
Uma atualização de versão principal geralmente introduz um ou mais recursos novos e importantes e geralmente contém alterações significativas. Normalmente, tem uma vida útil de suporte de cerca de dois anos. As versões principais do Neptune estão listadas nas [versões do mecanismo](engine-releases.md), junto com a data em que foram lançadas e o fim da vida útil estimado.
As atualizações da versão principal são totalmente opcionais até que a versão principal utilizada chegue ao fim da vida útil. Se você optar por atualizar para uma nova versão principal, você mesmo deverá instalar a nova versão usando o console do Neptune AWS CLI ou do Neptune, conforme descrito em. [Atualizações da versão principal](engine-updates-manually.md)
No entanto, se a versão principal utilizada chegar ao fim da vida útil, você receberá uma notificação de que é necessário atualizar para uma versão principal mais recente. Dessa forma, se você não fizer a atualização dentro de um período de carência após a notificação, uma atualização para a versão principal mais recente será programada automaticamente para ocorrer durante a próxima janela de manutenção. Consulte [Vida útil da versão do mecanismo](engine-updates-eol-planning.md) para obter mais informações.
## Atualizações da versão secundária do Amazon Neptune
A maioria das atualizações do mecanismo do Neptune são atualizações de versões secundárias. Elas acontecem com bastante frequência e não contêm alterações significativas.
Se o campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) estiver definido como `true` na instância (primária) do gravador do cluster de banco de dados, as atualizações da versão secundária serão aplicadas automaticamente a todas as instâncias no cluster de banco de dados durante a próxima janela de manutenção após o lançamento.
Se o campo [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) estiver definido como `false` na instância do gravador do cluster de banco de dados, elas serão aplicadas somente se você [instalá-las explicitamente](engine-updates-manually.md).
**nota**
As atualizações de versões secundárias são independentes (não dependem das atualizações anteriores da versão secundária para a mesma versão principal) e cumulativas (elas contêm todos os recursos e correções introduzidos nas atualizações de versões secundárias anteriores). Isso significa que você pode instalar qualquer atualização de versão secundária, independentemente de ter instalado ou não as anteriores.
É fácil acompanhar os lançamentos de versões secundárias assinando o evento [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consulte [Assinar a notificação de eventos do Neptune](events-subscribing.md)). Em seguida, você receberá notificações sempre que uma nova versão secundária for lançada.
Além disso, independentemente de você assinar ou não as notificações, sempre poderá [verificar quais atualizações estão pendentes](engine-maintenance-management.md#check-pending-updates).
## Atualizações de versão de patch do Amazon Neptune
No caso de problemas de segurança ou outros defeitos graves que afetam a confiabilidade da instância, o Neptune implanta patches obrigatórios. Eles são aplicados a todas as instâncias no cluster de banco de dados durante próxima janela de manutenção, sem qualquer intervenção de sua parte.
Uma versão de patch é implantada somente quando os riscos de não implantá-la superam os riscos e o tempo de inatividade associados à implantação. As versões de patch não ocorrem com frequência (geralmente uma vez a cada poucos meses) e raramente exigem mais do que uma fração de sua janela de manutenção para serem aplicadas.
# Planejar a vida útil da versão principal do mecanismo do Amazon Neptune
As versões do mecanismo do Neptune quase sempre chegam ao fim da vida útil no final de um trimestre civil. As exceções ocorrem somente quando surgem problemas importantes de segurança ou disponibilidade.
Quando uma versão do mecanismo chegar ao fim da vida útil, você precisará atualizar o banco de dados Neptune para uma versão mais recente.
Em geral, as versões do mecanismo do Neptune continuam disponíveis da seguinte forma:
+ **Versões secundárias do mecanismo:** as versões secundárias do mecanismo permanecem disponíveis por pelo menos seis meses após o lançamento.
+ **Versões principais do mecanismo:** as versões principais do mecanismo permanecem disponíveis por pelo menos 12 meses após o lançamento.
Pelo menos 3 meses antes de uma versão do motor chegar ao fim de sua vida útil, AWS enviará uma notificação automática por e-mail para o endereço de e-mail associado à sua AWS conta e publicará a mesma mensagem no seu [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html). Isso dará tempo para planejar e se preparar para a atualização.
Quando uma versão do mecanismo chegar ao fim da vida útil, você não poderá mais criar clusters ou instâncias usando essa versão, nem o ajuste de escala automático poderá criar instâncias usando essa versão.
Uma versão do mecanismo que realmente chegue ao fim da vida útil será atualizada automaticamente durante uma janela de manutenção. A mensagem enviada a você três meses antes do fim da vida útil da versão do mecanismo conterá detalhes sobre o que essa atualização automática envolverá, incluindo a versão para a qual o mecanismo será atualizado automaticamente, o impacto nos clusters de banco de dados e as ações que recomendamos.
**Importante**
Você é responsável por manter as versões do mecanismo de banco de dados atualizadas. A AWS incentiva todos os clientes a atualizar os bancos de dados para a versão mais recente do mecanismo, a fim de se beneficiarem das proteções de segurança, privacidade e disponibilidade mais atualizadas. Se você operar o banco de dados em um mecanismo ou um software não compatível após a data de defasagem (“Mecanismo herdado”), enfrentará uma maior probabilidade de riscos operacionais, segurança e privacidade, incluindo eventos de inatividade.
A operação do seu banco de dados em qualquer mecanismo está sujeita ao Contrato que rege o uso dos AWS Serviços. Os motores antigos não estão disponíveis ao público em geral. AWS não fornece mais suporte para o Legacy Engine e AWS pode limitar o acesso ou o uso de qualquer Legacy Engine a qualquer momento, se AWS determinar que o Legacy Engine representa um risco de segurança ou responsabilidade, ou um risco de danos, aos Serviços AWS, a suas Afiliadas ou a terceiros. Sua decisão de continuar executando Seu conteúdo em um Mecanismo herdado pode fazer com que Seu conteúdo fique indisponível, corrompido ou irrecuperável. Os bancos de dados executados em um Mecanismo herdado estão sujeitos às exceções do Acordo de Serviço (SLA).
BANCOS DE DADOS E SOFTWARES RELACIONADOS EXECUTADOS EM UM MECANISMO LEGADO CONTÊM BUGS, ERROS, DEFEITOS E COMPONENTES AND/OR NOCIVOS. CONSEQUENTEMENTE, E NÃO OBSTANTE QUALQUER DISPOSIÇÃO EM CONTRÁRIO NO CONTRATO OU NOS TERMOS DO SERVIÇO, AWS ESTÁ FORNECENDO O MECANISMO ANTIGO “NO ESTADO EM QUE SE ENCONTRA”.
# Gerenciar atualizações do mecanismo no cluster de banco de dados do Neptune
**nota**
As atualizações são simultaneamente aplicadas a todas as instâncias em um cluster de banco de dados. Como as atualizações exigem a reinicialização do banco de dados em todas essas instâncias, ocorrerá um tempo de inatividade de vinte ou trinta segundos a alguns minutos. Depois disso, você poderá retomar o uso do cluster de banco de dados. Em raras ocasiões, um failover Multi-AZ pode ser necessário para concluir uma atualização de manutenção em uma instância.
Para atualizações de versões principais que podem levar mais tempo para serem aplicadas, você pode usar uma [estratégia de implantação azul/verde](neptune-BG-deployments.md) para minimizar o tempo de inatividade.
## Determinar qual versão do mecanismo você está usando no momento
Você pode usar o AWS CLI [`get-engine-status`](access-graph-status.md)comando para verificar qual versão de lançamento do mecanismo seu cluster de banco de dados está usando atualmente:
```
aws neptunedata get-engine-status
```
A [saída JSON](access-graph-status.md#access-graph-status-sample-output) inclui um campo `"dbEngineVersion"` como este:
```
"dbEngineVersion": "1.3.0.0",
```
## Verifique quais atualizações estão pendentes e disponíveis
Você pode verificar as atualizações pendentes do cluster de banco de dados do usando o console do Neptune. Selecione **Bancos de dados** na coluna esquerda e, em seguida, o cluster de banco de dados no painel de bancos de dados. As atualizações pendentes estão listadas na coluna **Manutenção**. Se você selecionar **Ações** e, em seguida, **Manutenção**, você tem três opções:
+ Atualizar agora.
+ Atualizar na próxima janela.
+ Adiar atualização.
Você pode listar as atualizações pendentes do mecanismo usando o AWS CLI seguinte:
```
aws neptune describe-pending-maintenance-actions \
--resource-identifier (ARN of your DB cluster)
--region (your region) \
--engine neptune
```
Você também pode listar as atualizações de mecanismo disponíveis usando o AWS CLI seguinte:
```
aws neptune describe-db-engine-versions \
--region (your region) \
--engine neptune
```
A lista de versões disponíveis do mecanismo inclui somente as versões com um número maior do que a atual e para as quais há um caminho de atualização definido.
## Sempre teste antes de fazer a atualização
Quando uma nova versão principal ou secundária do mecanismo do Neptune for lançada, sempre teste as aplicações do Neptune antes de atualizá-la. Uma atualização secundária pode introduzir novos recursos ou comportamentos que afetam o código mesmo sem nenhuma alteração significativa.
Comece comparando as páginas de notas da versão atual com as da versão de destino para ver se haverá alterações nas versões da linguagem de consulta ou outras alterações importantes.
A melhor maneira de testar uma nova versão antes de atualizar o cluster de banco de dados de produção é usar a [solução de implantação azul/verde do Neptune](neptune-BG-deployments.md). Dessa forma, você pode executar aplicações e consultas na nova versão sem afetar o cluster de banco de dados de produção.
## Sempre crie um snapshot manual antes de fazer a atualização
Antes de fazer uma atualização, é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados. Ter um snapshot automático só oferece proteção de curto prazo, enquanto um snapshot manual permanece disponível até que você o exclua explicitamente.
Em determinados casos, o Neptune cria um snapshot manual para você como parte do processo de atualização, mas não confie nisso e, em qualquer caso, crie o próprio snapshot manual.
Quando você tiver certeza de que não precisará reverter o cluster de banco de dados para o estado de pré-atualização, poderá excluir explicitamente o snapshot manual criado, bem como o snapshot manual que o Neptune tenha criado. Se o Neptune criar um snapshot manual, ele terá um nome que começa com `preupgrade`, seguido pelo nome do cluster de banco de dados, a versão do mecanismo de origem, a versão do mecanismo de destino e a data.
## Janela de manutenção do Neptune
A janela de manutenção semanal é um período de 30 minutos durante o qual as atualizações programadas do mecanismo e outras alterações do sistema são aplicadas. A maioria dos eventos de manutenção é concluída durante a janela de 30 minutos, embora os eventos de manutenção mais longos possam levar mais tempo para serem concluídos.
Cada cluster de banco de dados tem uma janela de manutenção semanal de 30 minutos. Se você não especificar um horário de preferência ao criar o cluster de banco de dados, o Neptune selecionará aleatoriamente um dia da semana e também atribuirá aleatoriamente um período de 30 minutos a partir de um bloco de 8 horas que varia de acordo com a região.
Aqui, por exemplo, estão os blocos de tempo de 8 horas para janelas de manutenção usadas em várias regiões da AWS :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/engine-maintenance-management.html)
A janela de manutenção determina quando as operações pendentes começam, e a maioria das operações de manutenção é concluída dentro da janela, mas tarefas de manutenção maiores podem continuar além do horário de término da janela.
### Mover a janela de manutenção do cluster de banco de dados
O ideal é que sua janela de manutenção caia no momento em que o cluster estiver em menor uso. Se isso não se aplica à sua janela atual, você pode movê-la para um horário melhor, da seguinte forma:
**Para alterar a janela de manutenção do cluster de banco de dados**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha o cluster de banco de dados para o qual deseja alterar a janela de manutenção.
1. Selecione **Modify**.
1. Escolha **Mostrar mais** na parte inferior da página **Modificar cluster**.
1. Na seção **Janela de manutenção preferencial**, defina o dia, a hora e a duração da janela de manutenção conforme sua preferência.
1. Escolha **Próximo**.
Na página de confirmação, revise suas alterações.
1. Para aplicar as alterações à janela de manutenção imediatamente, selecione **Apply immediately (Aplicar imediatamente)**.
1. Escolha **Enviar** para aplicar as alterações.
Para editar as alterações, selecione **Anterior** ou, para cancelar as alterações, escolha **Cancelar**.
## Usando AutoMinorVersionUpgrade para controlar atualizações automáticas de versões secundárias
**Importante**
`AutoMinorVersionUpgrade` só é eficaz para atualizações de versões secundárias posterior à [versão 1.3.0.0 do mecanismo](engine-releases-1.3.0.0.md).
Se o campo `AutoMinorVersionUpgrade` estiver definido como `true` na instância (primária) do gravador do cluster de banco de dados, as atualizações da versão secundária serão aplicadas automaticamente a todas as instâncias no cluster de banco de dados durante a próxima janela de manutenção após o lançamento.
Se o campo `AutoMinorVersionUpgrade` estiver definido como `false` na instância do gravador do cluster de banco de dados, elas serão aplicadas somente se você [instalá-las explicitamente](engine-updates-manually.md#engine-minor-updates-using-console).
**nota**
As versões de patch (`*.*.*.1`, `*.*.*.2` etc.) são sempre instaladas automaticamente durante a próxima janela de manutenção, independentemente de como o parâmetro `AutoMinorVersionUpgrade` está definido.
Você pode definir `AutoMinorVersionUpgrade` usando o Console de gerenciamento da AWS seguinte:
**Para definir `AutoMinorVersionUpgrade` usando o console do Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha a instância primária (gravador) do cluster de banco de dados para o qual você deseja definir `AutoMinorVersionUpgrade`.
1. Escolha **Modificar**.
1. Escolha **Mostrar mais** na parte inferior da página **Modificar cluster**.
1. Na parte inferior da página expandida, escolha **Ativar atualização automática de versão secundária** ou **Desabilitar o upgrade automático da versão secundária**.
1. Escolha **Próximo**.
Na página de confirmação, revise suas alterações.
1. Para aplicar as alterações na atualização automática de versões secundárias, selecione **Aplicar imediatamente**.
1. Escolha **Enviar** para aplicar as alterações.
Para editar as alterações, selecione **Anterior** ou, para cancelar as alterações, escolha **Cancelar**.
Você também pode usar o AWS CLI para definir o `AutoMinorVersionUpgrade` campo. Por exemplo, para defini-lo como `true`, você pode usar um 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
```
Da mesma forma, para defini-lo como `false`, use um 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
```
# Instalar atualizações no mecanismo do Neptune manualmente
## Como instalar uma atualização da versão principal do mecanismo
As versões principais do mecanismo sempre devem ser instaladas manualmente. Para minimizar o tempo de inatividade e fornecer bastante tempo para testes e validação, a melhor maneira de instalar uma nova versão principal geralmente é usar a [solução de implantação azul/verde do Neptune](neptune-BG-deployments.md).
Em alguns casos, você também pode usar o CloudFormation modelo com o qual criou seu cluster de banco de dados para instalar uma atualização de versão principal (consulte[Usando um CloudFormation modelo para atualizar a versão do mecanismo do seu Neptune DB Cluster](cfn-engine-update.md)).
Se você quiser instalar uma atualização da versão principal imediatamente, você pode usar um comando da CLI como o seguinte:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (identifier for your neptune cluster) \
--engine neptune \
--engine-version (the new engine version) \
--apply-immediately
```
Especifique a versão do mecanismo para a qual você deseja atualizar. Caso contrário, o mecanismo poderá ser atualizado para uma versão que não seja a mais recente nem a esperada.
Em vez de `--apply-immediately`, é possível especificar `--no-apply-immediately`.
Se o cluster usar um grupo de parâmetros de cluster personalizado, use este parâmetro para especificá-lo:
```
--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)
```
Da mesma forma, se alguma instância no cluster usar um grupo de parâmetros de banco de dados personalizado, use este parâmetro para especificá-lo:
```
---db-instance-parameter-group-name (name of the custom instance parameter group)
```
## Instalando uma atualização secundária do mecanismo de versão usando o Console de gerenciamento da AWS
**Para fazer uma atualização da versão secundária usando o console Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados** e selecione o cluster de banco de dados que você deseja modificar.
1. Escolha **Modificar**.
1. Em **Especificações da instância**, escolha a nova versão para a qual você deseja atualizar.
1. Escolha **Próximo**.
1. Para aplicar alterações imediatamente, escolha **Aplicar imediatamente**.
1. Escolha **Enviar** para atualizar o cluster de banco de dados.
## Instalando uma atualização secundária do mecanismo de versão usando o AWS CLI
Você pode usar um comando como o seguinte para realizar uma atualização da versão secundária sem esperar pela próxima janela de manutenção:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your-neptune-cluster) \
--engine-version (new-engine-version) \
--apply-immediately
```
Se você estiver atualizando manualmente usando o AWS CLI, não se esqueça de incluir a versão do mecanismo para a qual você deseja atualizar. Caso contrário, o mecanismo poderá ser atualizado para uma versão que não seja a mais recente nem a esperada.
# Realizar a atualização para a versão 1.2.0.0 ou posterior do mecanismo a partir de uma versão anterior à 1.2.0.0
A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu algumas alterações significativas que podem tornar a atualização de uma versão anterior mais complicada do que o normal:
+ A [versão 1.2.0.0 do mecanismo](engine-releases-1.2.0.0.md) introduziu um novo formato para grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados. Como resultado, se você estiver atualizando de uma versão de mecanismo anterior à 1.2.0.0 para a versão 1.2.0.0 ou posterior, deverá recriar todos os grupos de parâmetros personalizados e grupos de parâmetros de cluster personalizados existentes usando a família de grupos de parâmetros `neptune1.2`. As versões anteriores usavam a família de grupos de parâmetros `neptune1`, e esses grupos de parâmetros não funcionarão com a versão 1.2.0.0 e posterior. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
+ A versão 1.2.0.0 do Engine introduziu um novo formato para desfazer registros. Consequentemente, se você estiver atualizando para a versão 1.2.0.0 ou superior de uma versão anterior à 1.2.0.0, a [`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)métrica deverá estar abaixo de um determinado limite. Caso contrário, o patch será revertido e falhará. Os limites são baseados no tipo de instância: o limite padrão é 40k para instâncias 4xlarge ou maiores e 10k para instâncias menores que 4xlarge. Se `UndoLogListSize` exceder o limite ao tentar fazer o upgrade, o processo de patch será revertido, a atualização será cancelada e um evento com o motivo ficará visível na página de eventos do cluster. Esses limites podem mudar por motivos operacionais sem aviso prévio.
É possível acelerar a taxa de limpeza atualizando a instância de gravador do cluster, que é onde a limpeza ocorre. Fazer isso antes de tentar fazer o upgrade pode ajudar a reduzir o limite `UndoLogListSize` abaixo do limite aplicável. Aumentar o tamanho do gravador para um tipo de instância 24XL pode aumentar a taxa de limpeza para mais de um milhão de registros por hora.
Se a `UndoLogListSize` CloudWatch métrica for extremamente grande, abrir um caso de suporte pode ajudá-lo a explorar estratégias adicionais para reduzi-la abaixo do limite exigido.
+ Por fim, houve uma alteração significativa na versão 1.2.0.0. Ela afeta o código anterior que usava o protocolo Bolt com autenticação do IAM. A partir da versão 1.2.0.0, o Bolt precisa de um caminho de recursos para a assinatura do IAM. Em Java, a definição do caminho de recursos pode ser assim: `request.setResourcePath("/openCypher"));`. Em outras linguagens, o `/openCypher` pode ser anexado ao URI do endpoint. Consulte [Usar o protocolo Bolt](access-graph-opencypher-bolt.md) para ver exemplos.
# Usando um CloudFormation modelo para atualizar a versão do mecanismo do seu Neptune DB Cluster
Você pode reutilizar o modelo CloudFormation Neptune que você usou para criar seu Neptune DB Cluster para atualizar sua versão do mecanismo.
As atualizações da versão do mecanismo do Neptune podem ser secundárias ou principais. Usar um CloudFormation modelo pode ajudar nas principais atualizações de versões, que geralmente contêm alterações significativas. Como as atualizações de versões principais podem conter as alterações de banco de dados incompatíveis com as aplicações existentes, talvez você também precise fazer as alterações nas aplicações durante a atualização. Sempre [teste antes de realizar a atualização](engine-maintenance-management.md#always-test-before-upgrading) e é altamente recomendável sempre criar um snapshot manual do cluster de banco de dados.
Observe que você precisa fazer uma atualização de mecanismo separada para cada versão principal. Você não pode ignorar uma versão principal e realizar a atualização diretamente para a versão principal a seguir.
Antes de 17 de maio de 2023, se você usava a pilha CloudFormation Neptune para atualizar sua versão do mecanismo, ela simplesmente criava um novo cluster de banco de dados vazio no lugar do seu atual. A partir de 17 de maio de 2023, no entanto, a pilha CloudFormation Neptune agora oferece suporte a atualizações de mecanismos locais que preservam seus dados existentes.
**nota**
Se você estiver usando o AWS Cloud Development Kit (AWS CDK), verifique se a AWS CDK versão que está sendo usada é 2.82.0 ou posterior. As versões anteriores à 2.82.0 não oferecem suporte às atualizações do mecanismo do Neptune no local.
Para uma atualização de versão principal, o modelo deve definir as seguintes propriedades em `DBCluster`:
+ `DBClusterParameterGroup` (personalizado ou padrão)
+ `DBInstanceParameterGroupName`
+ `EngineVersion`
Da mesma forma, para DBInstances anexar a DBCluster você deve definir:
+ `DBParameterGroup` (personalizado/padrão)
Garanta que todos os grupos de parâmetros estejam definidos no modelo, sejam eles padrão ou personalizados.
No caso de um grupo de parâmetros personalizado, garanta que a família do grupo de parâmetros personalizado existente seja compatível com a nova versão do mecanismo. As versões do mecanismo anteriores à [1.2.0.0](engine-releases-1.2.0.0.md) usavam a família de grupos de parâmetros `neptune1`, enquanto as versões do mecanismo a partir da 1.2.0.0 exigem a família de grupos de parâmetros `neptune1.2`. Consulte [Grupos de parâmetros do Amazon Neptune](parameter-groups.md) para obter mais informações.
Para atualizações de versões principais do mecanismo, especifique um grupo de parâmetros com a família apropriada no campo `DBInstanceParameterGroupName` do `DBCluster`.
Um grupo de parâmetros padrão deve ser atualizado para um que seja compatível com a nova versão do mecanismo.
Observe que o Neptune reinicia automaticamente as instâncias de banco de dados após uma atualização do mecanismo.
**Topics**
+ [Exemplo: atualização secundária do mecanismo de 1.2.0.1 para 1.2.0.2](cfn-engine-update-1201-1202.md)
+ [Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com grupos de parâmetros padrão](cfn-engine-update-1110-1202-default.md)
+ [Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com grupos de parâmetros personalizados](cfn-engine-update-1110-1202-custom.md)
+ [Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com uma mistura de grupos de parâmetros padrão e personalizados](cfn-engine-update-1110-1202-mixed.md)
# Exemplo: atualização secundária do mecanismo de 1.2.0.1 para 1.2.0.2
Encontre o cluster de banco de dados que você deseja atualizar e o modelo usado para criá-lo. Por exemplo:
```
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
```
Atualize a propriedade `EngineVersion` de `1.2.0.1` para `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
```
Agora use CloudFormation para executar o modelo revisado.
# Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com grupos de parâmetros padrão
Encontre o `DBCluster` que você deseja atualizar e o modelo usado para criá-lo. Por exemplo:
```
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
```
+ Atualize o `DBClusterParameterGroup` padrão para aquele na família de grupos de parâmetros usado pela nova versão do mecanismo (aqui `default.neptune1.2`).
+ Para cada `DBInstance` anexado ao `DBCluster`, atualize o `DBParameterGroup` padrão para aquele na família usado pela nova versão do mecanismo (aqui `default.neptune1.2`).
+ Defina a propriedade `DBInstanceParameterGroupName` como o grupo de parâmetros padrão nessa família (aqui `default.neptune1.2`).
+ Atualize a propriedade `EngineVersion` de `1.1.0.0` para `1.2.0.2`.
O modelo deve ser semelhante ao seguinte:
```
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:
```
Agora use CloudFormation para executar o modelo revisado.
# Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com grupos de parâmetros personalizados
Encontre o `DBCluster` que você deseja atualizar e o modelo usado para criá-lo. Por exemplo:
```
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
```
+ Atualize a família `DBClusterParameterGroup` personalizada para a usada pela nova versão do mecanismo (neste exemplo, `default.neptune1.2`).
+ Para cada `DBInstance` anexada ao `DBCluster`, atualize a família `DBParameterGroup` personalizada para a usada pela nova versão do mecanismo (neste exemplo, `default.neptune1.2`).
+ Defina a propriedade `DBInstanceParameterGroupName` como o grupo de parâmetros nessa família (aqui `default.neptune1.2`).
+ Atualize a propriedade `EngineVersion` de `1.1.0.0` para `1.2.0.2`.
O modelo deve ser semelhante ao seguinte:
```
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
```
Agora use CloudFormation para executar o modelo revisado.
# Exemplo: atualização da versão principal de 1.1.1.0 para 1.2.0.2 com uma mistura de grupos de parâmetros padrão e personalizados
Encontre o `DBCluster` que você deseja atualizar e o modelo usado para criá-lo. Por exemplo:
```
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 um grupo de parâmetros de cluster personalizados, atualize a família `DBClusterParameterGroup` para aquela correspondente à nova versão do mecanismo, ou seja, `neptune1.2`.
+ Para um grupo de parâmetros de cluster padrão, atualize o `DBClusterParameterGroup` para o padrão correspondente à nova versão do mecanismo, ou seja, `default.neptune1.2`.
+ Para cada `DBInstance` anexada ao `DBCluster`, atualize um `DBParameterGroup` padrão para o da família usado pela nova versão do mecanismo (aqui `default.neptune1.2`) e um grupo de parâmetros personalizado para um que use a família compatível com a nova versão do mecanismo (aqui `neptune1.2`).
+ Defina a propriedade `DBInstanceParameterGroupName` como o grupo de parâmetros na família compatível com a nova versão do mecanismo.
O modelo deve ser semelhante ao seguinte:
```
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
```
Agora use CloudFormation para executar o modelo revisado.
# Clonagem de banco de dados no Neptune
Com a clonagem de banco de dados, é possível criar clones de todos os bancos de dados de forma rápida e econômica no Amazon Neptune. Os bancos de dados clonados exigem apenas o espaço adicional mínimo quando criados pela primeira vez. A clonagem de banco de dados usa um *protocolo copy-on-write*. Os dados são copiados no momento em que são alterados, seja nos bancos de dados de origem ou nos bancos de dados clonados. Você pode fazer vários clones do mesmo cluster de banco de dados. Você também pode criar clones adicionais a partir de outros clones. Para obter mais informações sobre como o protocolo copy-on-write funciona no contexto de armazenamento do Neptune, consulte [Protocolo copy-on-write](#manage-console-cloning-protocol).
Você pode usar a clonagem de banco de dados em uma série de casos de uso, especialmente quando deseja evitar um impacto no seu ambiente de produção, como este:
+ Experimente e avalie o impacto das alterações, como alterações de esquema ou no grupo de parâmetros.
+ Realize operações com cargas de trabalho intensivas, como exportar dados ou executar consultas analíticas.
+ Crie uma cópia de um cluster de banco de dados de produção em um ambiente de não produção para desenvolvimento ou teste.
**Para criar um clone de um cluster de banco de dados usando o Console de gerenciamento da AWS**
1. Faça login no Console de Gerenciamento da AWS e abra o console do Amazon Neptune em [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. No painel de navegação, escolha **Instâncias**. Escolha a instância primária do cluster de banco de dados do qual deseja criar um clone.
1. Selecione **Instance actions (Ações de instância)** e, em seguida, selecione **Create clone (Criar clone)**.
1. Na página **Create Clone (Criar clone)**, digite um nome para a instância primária do cluster de banco de dados clonado, como o **DB instance identifier (Identificador de instância de banco de dados)**.
Se desejar, defina quaisquer outras configurações para o cluster de banco de dados clonado. Para obter mais informações sobre as diferentes configurações do cluster de banco de dados, consulte [Iniciar usando o console](manage-console-launch-console.md).
1. Escolha **Create Clone** para iniciar o cluster de banco de dados clonado.
**Para criar um clone de um cluster de banco de dados usando o AWS CLI**
+ Chame o comando [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) da AWS CLI e forneça os seguintes valores:
+ `--source-db-cluster-identifier`: o nome do cluster de banco de dados de origem do qual será criado um clone.
+ `--db-cluster-identifier`: o nome do cluster de banco de dados clonado.
+ `--restore-type copy-on-write`: o valor `copy-on-write` indica que um cluster de banco de dados clonado deve ser criado.
+ `--use-latest-restorable-time`: especifica que o tempo de backup restaurável mais recente deve ser usado.
**nota**
O comando [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) da AWS CLI clona apenas o cluster de banco de dados, e não as instâncias de banco de dados para esse cluster de banco de dados.
O exemplo de Linux/UNIX a seguir cria um clone do cluster do banco de dados `source-db-cluster-id` e nomeia o clone `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
```
O mesmo exemplo funcionará no Windows se o caractere de escape de fim de linha `\` for substituído pelo `^` equivalente do 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
```
## Limitações
A clonagem de banco de dados no Neptune tem as seguintes limitações:
+ Não é possível criar clones de bancos de dados em regiões da AWS. Os bancos de dados de clones devem ser criados na mesma região dos bancos de dados de origem.
+ Um banco de dados clonado sempre usa o patch mais recente da versão do mecanismo do Neptune que está sendo usada pelo banco de dados do qual foi clonado. Isso ocorre mesmo que o banco de dados de origem ainda não tenha sido atualizado para essa versão de patch. No entanto, a versão do mecanismo em si não muda.
+ No momento, o limite é de no máximo 15 clones por cópia do cluster de banco de dados do Neptune, incluindo clones baseados em outros clones. Depois de atingir esse limite, é necessário fazer outra cópia do banco de dados em vez de cloná-lo. No entanto, se você fizer uma nova cópia, ela também poderá ter até 15 clones.
+ No momento, a clonagem do banco de dados entre contas não é compatível.
+ Você pode fornecer uma nuvem privada virtual (VPC) diferente para seu clone. No entanto, as sub-redes dessas VPCs devem ser mapeadas no mesmo conjunto de Zonas de disponibilidade.
## Protocolo copy-on-write para clonagem de banco de dados
Os seguintes cenários ilustram o funcionamento do protocolo copy-on-write.
+ [Banco de dados do Neptune antes da clonagem](#manage-console-cloning-protocol-before)
+ [Banco de dados do Neptune após a clonagem](#manage-console-cloning-protocol-after)
+ [Quando uma alteração é feita no banco de dados de origem](#manage-console-cloning-protocol-source-write)
+ [Quando uma alteração é feita no banco de dados clonado](#manage-console-cloning-protocol-clone-write)
### Banco de dados do Neptune antes da clonagem
Os dados em um banco de dados de origem são armazenados em páginas. No diagrama a seguir, o banco de dados de origem apresenta quatro páginas.
![\[Banco de dados de origem do Neptune antes da clonagem do banco de dados com quatro páginas.\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/neptune-clone-1.png)
### Banco de dados do Neptune após a clonagem
Conforme mostrado no diagrama a seguir, não ocorrem alterações no banco de dados de origem após a clonagem do banco de dados. Tanto o banco de dados de origem quanto o banco de dados clonado apontam para as mesmas quatro páginas. Nenhuma página foi copiada fisicamente, portanto, nenhum armazenamento adicional é necessário.
![\[Banco de dados de origem do Neptune e banco de dados clonado apontando para as mesmas páginas após a clonagem do banco de dados.\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/neptune-clone-2.png)
### Quando uma alteração é feita no banco de dados de origem
No exemplo a seguir, o banco de dados de origem faz uma alteração nos dados em `Page 1`. Em vez de gravar na `Page 1` original, ele usa um armazenamento adicional para criar uma nova página, chamada `Page 1'`. O banco de dados de origem agora aponta para o novo `Page 1'`, e também para `Page 2`, `Page 3` e `Page 4`. O banco de dados clonado continua a apontar para `Page 1` através da `Page 4`.
![\[Banco de dados de origem do Neptune e banco de dados clonado após a alteração do banco de dados de origem.\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/neptune-clone-3.png)
### Quando uma alteração é feita no banco de dados clonado
No diagrama a seguir, o banco de dados clonado também foi alterado, desta vez em `Page 4`. Em vez de gravar no `Page 4` original, é usado um armazenamento adicional para criar a nova página, chamada `Page 4'`. O banco de dados de origem continua a apontar para `Page 1'`, e também para `Page 2` por meio da `Page 4`, mas o banco de dados clonado agora aponta para `Page 1` por meio da `Page 3` e também para `Page 4'`.
![\[Banco de dados de origem do Neptune e banco de dados clonado, após a alteração do banco de dados clonado.\]](http://docs.aws.amazon.com/pt_br/neptune/latest/userguide/images/neptune-clone-4.png)
Conforme mostrado no segundo cenário, após a clonagem do banco de dados, não há armazenamento adicional necessário no ponto de criação do clone. No entanto, à medida que ocorrerem mudanças no banco de dados de origem e no banco de dados clonado, somente as páginas alteradas serão criadas, conforme mostrado nos terceiro e quarto cenários. À medida que ocorrerem mais alterações ao longo do tempo no banco de dados de origem e no banco de dados clonado, você precisará de mais armazenamento incremental para captar e armazenar as alterações.
## Excluir um banco de dados de origem
A exclusão de um banco de dados de origem não afeta os bancos de dados clonados a ele associados. Os bancos de dados clonados continuam a apontar para as páginas que pertenciam anteriormente ao banco de dados de origem.
# Gerenciar instâncias do Amazon Neptune
As seções a seguir têm informações sobre operações no nível da instância.
**Topics**
+ [Classe de instância de intermitência T3 do Neptune.](manage-console-instances-t3.md)
+ [Modificar uma instância de banco de dados do Neptune (e aplicar imediatamente)](manage-console-instances-modify.md)
+ [Renomear uma instância de banco de dados do Neptune](manage-console-instances-rename.md)
+ [Reinicializar uma instância de banco de dados no Amazon Neptune](manage-console-instances-reboot.md)
+ [Excluir uma instância de banco de dados no Amazon Neptune](manage-console-instances-delete.md)
# Classe de instância de intermitência T3 do Neptune.
Além das classes de instância de desempenho fixo, como `R5` e `R6`, o Amazon Neptune oferece a opção de usar uma instância `T3` de desempenho de intermitência. Ao desenvolver a aplicação de grafos, convém que o banco de dados seja rápido e responsivo, mas não precisa usá-lo o tempo todo. A classe de instância `db.t3.medium` do Neptune é exatamente o que você deve usar nessa situação, por um custo significativamente menor do que a classe de instância de desempenho fixo mais barata.
Uma instância de intermitência é executada no nível da linha de base do desempenho da CPU até que uma carga de trabalho precise de mais e gera picos acima da linha de base pelo tempo necessário para a carga de trabalho. O preço por hora cobre os picos, desde que o uso médio da CPU não ultrapasse a linha de base por um período de 24 horas. Para a maioria das situações de desenvolvimento e teste, isso significa bom desempenho a um baixo custo.
Se você começar com uma classe de instância `T3`, poderá alternar facilmente para uma instância de desempenho fixo posteriormente quando estiver tudo pronto para entrar em produção, usando o Console de gerenciamento da AWS, a AWS CLI ou um dos AWS SDKs.
## A intermitência T3 é governada por créditos da CPU
Um crédito da CPU representa o uso total de um núcleo de CPU virtual (vCPU) por um minuto. Isso também significa 50% de uso de uma vCPU por dois minutos, ou 25% de uso de duas vCPUs por dois minutos, e assim por diante.
Uma instância `T3` acumula créditos da CPU quando está ociosa e os usa quando está ativa, ambos medidos em resolução de milissegundos. A classe de instância `db.t3.medium` tem duas vCPUs, e cada uma recebe 12 créditos da CPU por hora quando ociosa. Isso significa que 20% do uso de cada vCPU resulta em um saldo de crédito da CPU igual a zero. Os 12 créditos da CPU recebidos são gastos em 20% do uso da vCPU (pois 20% de 60 minutos também é 12). Desta forma, esse uso de 20% é a taxa de utilização da *linha de base* que gera um saldo de crédito da CPU nem positivo nem negativo.
O tempo ocioso (utilização da CPU abaixo de 20% do total disponível) faz com que os créditos da CPU sejam armazenados em um bucket de saldo de crédito, até o limite para uma classe de instância `db.t3.medium` de 576 (o número máximo de créditos da CPU que podem ser acumulados em 24 horas, ou seja 2 x 12 x 24). Acima desse limite, os créditos da CPU são simplesmente descartados.
Quando necessário, a utilização da CPU pode ter picos de até 100% pelo tempo necessário para a carga de trabalho, mesmo após o saldo de crédito da CPU ficar abaixo de zero. Se a instância manter um saldo negativo continuamente por 24 horas, ela incorrerá uma cobrança adicional de 0,05 USD para cada -60 créditos da CPU acumulados nesse período. No entanto, para a maioria das cargas de trabalho de desenvolvimento e teste, a intermitência é geralmente coberta pelo tempo ocioso antes ou após o pico.
**nota**
A classe de instância `T3` do Neptune é configurada como o [modo ilimitado](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) do Amazon EC2.
## Usar o Console de gerenciamento da AWS para criar uma instância de intermitência T3
No Console de gerenciamento da AWS, é possível criar uma instância primária de cluster de banco de dados, ou uma instância de réplica de leitura que usa a classe da instância `db.t3.medium`, ou você pode modificar uma instância existente para usar a classe de instância `db.t3.medium`.
Por exemplo, para criar uma instância principal do cluster de banco de dados no console do Neptune:
+ Escolha **Create Database (Criar banco de dados)**.
+ Escolha uma **DB engine version (Versão do mecanismo de banco de dados)** igual ou posterior a `1.0.2.2`.
+ Em **Purpose (Finalidade)**, escolha **Development and Testing (Desenvolvimento e teste)**.
+ Para a **DB instance class (Classe da instância de banco de dados)**, aceite o padrão: `db.t3.medium — 2 vCPU, 4 GiB RAM`.
## Usar o AWS CLI para criar uma instância de intermitência T3
Também é possível usar a AWS CLI para fazer a mesma coisa:
```
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
```
# Modificar uma instância de banco de dados do Neptune (e aplicar imediatamente)
É possível aplicar a maioria das alterações em uma instância de banco de dados do Amazon Neptune imediatamente ou adiá-las até a próxima janela de manutenção. Algumas modificações, como alterações em grupos de parâmetros, exigem que você reinicie manualmente sua instância de banco de dados para que a alteração entre em vigor.
**Importante**
Modificações geram uma interrupção, pois o Neptune deve reiniciar a instância de banco de dados para que a alteração seja aplicada. Analise o impacto sobre o banco de dados e as aplicações antes de modificar as configurações da instância de banco de dados.
## Configurações comuns e implicações do tempo de inatividade
A tabela a seguir contém detalhes sobre quais configurações você pode modificar, quando as alterações podem ser aplicadas e se as alterações causam tempo de inatividade para a instância de banco de dados.
****
| Configuração da instância de banco de dados | Observações sobre tempo de inatividade |
| --- | --- |
| **Classe de instância de banco de dados** | Ocorre uma interrupção durante essa alteração, seja ela aplicada imediatamente ou durante a próxima janela de manutenção. |
| **DB instance identifier** | A instância de banco de dados é reinicializada e ocorre uma interrupção durante essa alteração, seja ela aplicada imediatamente ou durante a próxima janela de manutenção. |
| **Grupo de sub-redes** | A instância de banco de dados é reinicializada e ocorre uma interrupção durante essa alteração, seja ela aplicada imediatamente ou durante a próxima janela de manutenção. |
| **Grupo de segurança** | A alteração é aplicada de forma assíncrona o mais rápido possível, independentemente de quando você especifica que as alterações devem ocorrer, sem resultados de interrupção. | – |
| **Certificate Authority (Autoridade certificadora)** | Por padrão, a instância de banco de dados é reiniciada quando você atribui uma nova autoridade certificadora. |
| **Database Port** | A alteração sempre ocorre imediatamente, fazendo com que a instância de banco de dados seja reinicializada e ocorra uma interrupção. |
| **Grupo de parâmetros de banco de dados** | Alterar essa configuração não resultará em uma interrupção. O nome do parameter group propriamente dito é alterado imediatamente, mas as alterações de parâmetros reais não serão aplicadas até que você reinicialize a instância sem failover. Nesse caso, a instância de banco de dados não será reinicializada automaticamente, e as alterações de parâmetro não serão aplicadas durante a próxima janela de manutenção. No entanto, se você modificar parâmetros dinâmicos no grupo de parâmetros de banco de dados recém-associado, essas alterações serão aplicadas imediatamente sem uma reinicialização. Para obter mais informações, consulte [Reinicializar uma instância de banco de dados no Amazon Neptune](manage-console-instances-reboot.md). |
| **Grupo de parâmetros do cluster de banco de dados** | O grupo de parâmetros de banco de dados é alterado imediatamente. |
| **Período de retenção de backup** | Se você especificar que as alterações devem ocorrer imediatamente, essa alteração ocorrerá imediatamente. Caso contrário, se você alterar a configuração de um valor diferente de zero para outro valor diferente de zero, a alteração será aplicada de forma assíncrona o mais rápido possível. Qualquer outra alteração ocorrerá durante a próxima janela de manutenção. Uma falha ocorrerá se você alterar de zero para um valor diferente de zero ou de um valor diferente de zero para zero. |
| **Log de auditoria** | Selecione **Registro de auditoria** se quiser usar o registro de auditoria por meio de CloudWatch registros. Você também deve definir o parâmetro `neptune_enable_audit_log` no grupo de parâmetros de cluster de banco de dados como `enable` (1) para que o registro em log de auditoria seja habilitado. |
| **Atualização da versão secundária automática** | Selecione **Habilitar a atualização automática da versão secundária** se quiser permitir que o cluster de banco de dados do Neptune receba atualizações de versão secundária do mecanismo quando disponíveis. A opção *Atualização automática de versão secundária* só se aplica a atualizações para versões secundárias do mecanismo do cluster de banco de dados do Amazon Neptune. Ela não se aplica a patches regulares aplicados para manter a estabilidade do sistema. |
# Renomear uma instância de banco de dados do Neptune
É possível renomear uma instância de banco de dados do Amazon Neptune usando o Console de gerenciamento da AWS. Renomear uma instância de banco de dados pode ter efeitos de longo alcance. Veja a seguir uma lista de coisas que você deve saber antes de renomear uma instância de banco de dados.
+ Quando você renomeia uma instância de banco de dados, o endpoint dessa instância é alterado, pois a URL inclui o nome atribuído a ela. Você sempre deve redirecionar o tráfego da URL antiga para a nova.
+ Ao renomear uma instância de banco de dados, o nome DNS antigo que era usado pelo cluster de banco de dados é excluído imediatamente, mas pode permanecer armazenado em cache por alguns minutos. O novo nome DNS da instância de banco de dados renomeada torna-se efetivo em cerca de 10 minutos. A instância de banco de dados renomeada não ficará disponível até que o novo nome entre em vigor.
+ Você não pode usar um nome de instância de banco de dados existente ao renomear uma instância.
+ Todas as réplicas de leitura associadas a uma instância de banco de dados permanecem associadas a essa instância depois que ela é renomeada. Por exemplo, suponha que você tem uma instância de banco de dados que atende seu banco de dados de produção, e que essa instância tem várias réplicas de leitura associadas. Se você renomear a instância de banco de dados e a substituir no ambiente de produção por um DB snapshot, a instância de banco de dados que você renomeou ainda terá as réplicas de leitura associadas a ela.
+ As métricas e os eventos associados ao nome de uma instância de banco de dados serão mantidos se você reutilizar um nome de instância de banco de dados. Por exemplo, se você promover uma réplica de leitura e a renomear para que ela tenha o nome da instância principal anterior, os eventos e as métricas associados à instância principal serão associados à instância renomeada.
+ Tags de instâncias de bancos de dados permanecem com a instância de banco de dados, independentemente de renomeação.
+ snapshot de banco de dadoss são mantidos para uma instância de banco de dados renomeada.
**Como renomear uma instância de banco de dados usando o console do Neptune**
1. Faça login no Console de Gerenciamento da AWS e abra o console do Amazon Neptune em [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. No painel de navegação, escolha **Bancos de dados**.
1. Selecione o botão de opção ao lado da instância de banco de dados que deseja renomear.
1. No menu **Instance actions (Ações da instância)**, escolha **Modify (Modificar)**.
1. Insira um novo nome na caixa de texto **DB Instance Identifier (Identificador da instância de banco de dados)**. Selecione **Apply immediately (Aplicar imediatamente)** e, em seguida, selecione **Continue (Continuar)**.
1. Selecione **Modify DB Instance (Modificar instância de banco de dados)** para concluir a alteração.
# Reinicializar uma instância de banco de dados no Amazon Neptune
Em alguns casos, se você modificar uma instância de banco de dados do Amazon Neptune, alterar o grupo de parâmetros de banco de dados associado à instância ou alterar um parâmetro de banco de dados estático em um grupo de parâmetros usado pela instância, será necessário reinicializar a instância para que as alterações sejam aplicadas.
Reiniciar uma instância de banco de dados reinicia o serviço de mecanismo de banco de dados. Uma reinicialização também aplica à instância de banco de dados todas as alterações do parameter group de banco de dados associado que estavam pendentes. Reinicializar uma instância de banco de dados resulta em uma interrupção momentânea da instância, durante a qual o status da instância de banco de dados é definido como *rebooting*. Se a instância do Neptune estiver configurada para multi-AZ, a reinicialização poderá ser realizada por meio de failover. Um evento do Neptune é criado quando a reinicialização é concluída.
Se a instância de banco de dados for uma implantação Multi-AZ, você poderá forçar um failover de uma zona de disponibilidade para outra ao selecionar a opção **Reboot (Reinicializar)**. Ao forçar um failover da instância de banco de dados, o Neptune automaticamente alterna para uma réplica em espera em outra zona de disponibilidade. Em seguida, atualiza o registro DNS da instância de banco de dados para apontar para a instância de banco de dados em espera. Como resultado, você deve limpar e restabelecer todas as conexões existentes com a instância de banco de dados.
A opção **Reboot with failover (Reinicialização com failover)** é benéfica quando você deseja simular uma falha de uma instância de banco de dados para testes ou restaurar as operações na zona de disponibilidade original após a ocorrência de um failover. Para obter mais informações, consulte [High Availability (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) no *Guia do usuário do Amazon RDS*. Quando você reinicializa um cluster de banco de dados, ele executa failover na réplica em espera. A reinicialização de uma réplica do Neptune não inicia um failover.
O tempo necessário para reinicializar depende do processo de recuperação de falhas. Para melhorar o tempo de reinicialização, recomendamos reduzir as atividades do banco de dados o máximo possível durante o processo de reinicialização para reduzir a atividade de reversão para transações em trânsito.
No console, a opção **Reboot (Reiniciar)** poderá estar desabilitada se a instância de banco de dados não estiver no estado **Available (Disponível)**. Isso pode ser devido a vários motivos, como um backup em andamento, uma modificação solicitada pelo cliente ou uma ação da janela de manutenção.
**nota**
Antes de [Versão: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), todas as réplicas de leitura em um cluster de banco de dados eram reinicializadas automaticamente quando a instância (de gravador) principal era reiniciada.
A partir de [Versão: 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), reiniciar a instância principal não faz com que as réplicas sejam reiniciadas. Isso significa que, se você estiver alterando um parâmetro de cluster, deverá reiniciar cada instância separadamente para receber a alteração do parâmetro (consulte [Grupos de parâmetros](parameter-groups.md)).
**Como reinicializar uma instância de banco de dados usando o console do Neptune**
1. Faça login no Console de Gerenciamento da AWS e abra o console do Amazon Neptune em [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. No painel de navegação, escolha **Bancos de dados**.
1. Selecione a instância de banco de dados que você deseja reinicializar.
1. Escolha **Instance actions** e depois **Reboot**.
1. Para forçar um failover de uma zona de disponibilidade para outra, selecione **Reboot with failover? (Reinicializar com failover?)** na caixa de diálogo **Reboot DB Instance (Reinicializar instância de banco de dados)**.
1. Escolha **Reboot**. Para cancelar a reinicialização, selecione **Cancel (Cancelar)**.
# Excluir uma instância de banco de dados no Amazon Neptune
É possível excluir uma instância de banco de dados do Amazon Neptune em qualquer estado e a qualquer momento, desde que a instância tenha sido iniciada.
**Atenção**
Se você excluir a última instância restante em um cluster usando o **console da web**, ela também excluirá o volume de armazenamento do cluster subjacente.
## Criar um snapshot final de sua instância de banco de dados antes de excluí-la
Para excluir uma instância de banco de dados, você deve especificar o nome da instância e se deseja obter um DB snapshot final da instância. Se a instância de banco de dados que está sendo excluída tiver um status de **Creating (Criando)**, você não poderá obter um DB snapshot final. Se a instância de banco de dados estiver em estado de falha com um status **failed (com falha)**, **incompatible-restore (restauração incompatível)** ou **incompatible-network (rede incompatível)**, você só poderá excluir a instância quando o parâmetro `SkipFinalSnapshot` estiver definido como `true`.
Se você excluir todas as instâncias de banco de dados Neptune em um cluster de banco de dados usando Console de gerenciamento da AWS o, todo o cluster de banco de dados será excluído automaticamente. Se você estiver usando o AWS CLI ou SDK, deverá excluir o cluster de banco de dados manualmente depois de excluir a última instância.
**Importante**
Se você excluir todo um cluster de banco de dados, todos os seus backups automatizados serão excluídos ao mesmo tempo e não poderão ser recuperados. Isso significa que, a menos que você opte por criar um snapshot de banco de dados final manualmente, não poderá restaurar a instância de banco de dados para seu estado final posteriormente. Os snapshots manuais de uma instância não são excluídos quando o cluster é excluído.
Se a instância de banco de dados que deseja excluir tiver uma réplica de leitura, você deverá promover a réplica de leitura ou excluí-la.
Nos exemplos a seguir, você exclui uma instância de banco de dados com e sem um DB snapshot final.
## Excluir uma instância de banco de dados sem um snapshot final
Se desejar excluir a instância de banco de dados rapidamente, você poderá ignorar a criação de um DB snapshot final. Quando você exclui uma instância de banco de dados, todos os backups automatizados são excluídos e não podem ser recuperados. Os snapshots manuais não são excluídos.
**Como excluir uma instância de banco de dados sem um snapshot de banco de dados final usando o console do Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Na lista **Instances (Instâncias)**, selecione o botão de opção ao lado da instância de banco de dados que você deseja excluir.
1. Escolha **Instance actions** e, em seguida, escolha **Delete**.
1. Escolha **No (Não)** na caixa **Create final snapshot? (Criar snapshot final?)**.
1. Escolha **Excluir**.
## Excluir uma instância de banco de dados com um snapshot final
Se desejar poder restaurar a instância de banco de dados excluída posteriormente, você poderá criar um DB snapshot final. Todos os backups automáticos também serão excluídos e não poderão ser recuperados. Os snapshots manuais não são excluídos.
**Como excluir uma instância de banco de dados com um snapshot de banco de dados final usando o console do Neptune**
1. [Faça login no AWS Management Console e abra o console do Amazon Neptune em casa. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. No painel de navegação, escolha **Bancos de dados**.
1. Na lista **Instances (Instâncias)**, selecione o botão de opção ao lado da instância de banco de dados que você deseja excluir.
1. Escolha **Instance actions** e, em seguida, escolha **Delete**.
1. Escolha **Yes (Sim)** na caixa **Create final snapshot? (Criar snapshot final?)**.
1. Na caixa **Final Snapshot name (Nome do snapshot final)**, digite o nome de seu DB snapshot final.
1. Escolha **Excluir**.
Você pode verificar a integridade de uma instância, determinar o seu tipo, descobrir qual versão de mecanismo você tem instalada no momento e obter outras informações sobre uma instância usando a [API de status da instância](access-graph-status.md).