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á.
Clusters e instâncias de banco de dados do Amazon Neptune
Um cluster de banco de dados do Amazon Neptune gerencia o acesso aos dados por meio de consultas. Um cluster consiste em:
Uma instância de banco de dados primária.
Até 15 instâncias de banco de dados de réplica de leitura.
Todas as instâncias em um cluster compartilham o mesmo volume de armazenamento gerenciado subjacente, projetado para oferecer confiabilidade e alta disponibilidade.
Você se conecta às instâncias de banco de dados em seu cluster de banco de dados por meio dos endpoints do Neptune.
A instância de banco de dados primária em um cluster de banco de dados do Neptune
A instância de banco de dados principal coordena todas as operações de gravação no volume de armazenamento subjacente do cluster de banco de dados. Ela também é compatível com operações de leitura.
Só pode haver uma instância de banco de dados primária em um cluster de banco de dados do Neptune. Se a instância primária ficar indisponível, o Neptune automaticamente fará o failover para uma das instâncias de réplica de leitura com uma prioridade que você pode especificar.
Instâncias de banco de dados de réplica de leitura em um cluster de banco de dados do Neptune
Depois de criar a instância principal de um cluster de banco de dados, você poderá criar até 15 réplicas de leitura no cluster de banco de dados para oferecer compatibilidade com consultas somente leitura.
As instâncias de banco de dados de réplicas de leitura do Neptune funcionam bem para a escalabilidade de leitura porque são totalmente dedicadas a operações de leitura no volume de cluster. Todas as operações de gravação são gerenciadas pela instância principal. Cada instância de banco de dados de réplica de leitura tem o próprio endpoint.
Como o volume de armazenamento do cluster é compartilhado entre todas as instâncias em um cluster, todas as instâncias de réplica de leitura geram os mesmos dados para os resultados da consulta com muito pouco atraso na replicação. Esse atraso é geralmente muito inferior a 100 milissegundos, depois que a instância primária grava uma atualização, embora ele possa ser um pouco maior quando o volume de operações de gravação é muito grande.
Ter uma ou mais instâncias de réplica de leitura disponíveis em diferentes zonas de disponibilidade pode aumentar a disponibilidade, pois as réplicas de leitura servem como destinos de failover para a instância primária. Ou seja, se a instância principal falhar, o Neptune promoverá uma instância de réplica de leitura para se tornar a instância principal. Quando isso acontece, há uma breve interrupção enquanto a instância promovida é reinicializada, durante a qual as solicitações de leitura e gravação feitas na instância principal falham com uma exceção.
Por outro lado, se o cluster de banco de dados não incluir nenhuma instância de réplica de leitura, o cluster de banco de dados permanecerá indisponível quando a instância primária falhar até que seja recriada. Recriar a instância primária leva muito mais tempo do que promover uma réplica de leitura.
Para garantir a alta disponibilidade, recomendamos criar uma ou mais instâncias de réplica de leitura que tenham a mesma classe de instância de banco de dados da instância primária e estejam localizadas em zonas de disponibilidade diferentes da instância primária. Consulte Tolerância a falhas para um cluster de banco de dados do Neptune.
Usando o console, você pode criar uma implantação Multi-AZ. Basta especificar Multi-AZ ao criar um cluster de banco de dados. Caso um cluster de banco de dados esteja em uma única zona de disponibilidade, você poderá torná-lo um cluster de banco de dados Multi-AZ adicionando uma réplica do Neptune a uma zona de disponibilidade diferente.
nota
Não é possível criar uma instância de réplica de leitura criptografada para um cluster de banco de dados do Neptune não criptografado ou uma instância de réplica de leitura não criptografada para um cluster de banco de dados do Neptune criptografado.
Para obter detalhes sobre como criar uma instância de banco de dados de réplica de leitura do Neptune, consulte Criar uma instância de leitor do Neptune usando o console.
Dimensionar instâncias de banco de dados em um cluster de banco de dados do Neptune
Dimensione as instâncias em seu cluster de banco de dados Neptune com base em CPU seus requisitos e de memória. O número de vCPUs em uma instância determina o número de segmentos de consulta que lidam com as consultas recebidas. A quantidade de memória em uma instância determina o tamanho do cache do buffer, usado para armazenar cópias de páginas de dados obtidas do volume de armazenamento subjacente.
Cada instância de banco de dados Neptune tem um número de threads de consulta igual a 2 x o número vCPUs de threads nessa instância. Umr5.4xlarge, por exemplo, com 16vCPUs, tem 32 segmentos de consulta e, portanto, pode processar 32 consultas simultaneamente.
Consultas adicionais que chegam enquanto todos os encadeamentos de consulta estão ocupados são colocadas em uma fila do lado do servidor e processadas de FIFO forma que os encadeamentos de consulta se tornem disponíveis. Essa fila do lado do servidor pode conter cerca de 8 mil solicitações pendentes. Quando estiver cheio, o Neptune responderá a solicitações adicionais com uma ThrottlingException. Você pode monitorar o número de solicitações pendentes com a MainRequestQueuePendingRequests CloudWatch métrica ou usando o endpoint de status da consulta Gremlin com o parâmetro. includeWaiting
Do ponto de vista do cliente, o tempo de execução da consulta inclui qualquer tempo gasto na fila, além do tempo gasto para realmente executar a consulta.
Uma carga de gravação simultânea sustentada que utiliza todos os encadeamentos de consulta na instância de banco de dados primária mostra idealmente 90% ou mais de CPU utilização, o que indica que todos os encadeamentos de consulta no servidor estão ativamente engajados em realizar um trabalho útil. No entanto, a CPU utilização real geralmente é um pouco menor, mesmo sob uma carga de gravação simultânea sustentada. Isso geralmente ocorre porque os threads de consulta aguardam a conclusão das operações de E/S no volume de armazenamento subjacente. O Neptune usa gravações de quórum que fazem seis cópias de seus dados em três zonas de disponibilidade, e quatro desses seis nós de armazenamento devem reconhecer uma gravação para que ela seja considerada durável. Enquanto um thread de consulta aguarda esse quórum do volume de armazenamento, ele fica paralisado, o que reduz a utilização. CPU
Se você tem uma carga de gravação serial em que está executando uma gravação após a outra e aguardando a conclusão da primeira antes de começar a próxima, você pode esperar que a CPU utilização seja ainda menor. A quantidade exata será uma função do número vCPUs e dos encadeamentos de consulta (quanto mais encadeamentos de consulta, menor será o total CPU por consulta), com alguma redução causada pela espera pela E/S.
Para obter mais informações sobre como dimensionar melhor as instâncias de banco de dados, consulte Escolher o tipo certo de instância de banco de dados do Neptune. Para conhecer os preços de cada tipo de instância, consulte a página Preços do Neptune
Monitorar o desempenho da instâncias de banco de dados no Neptune
Você pode usar CloudWatch métricas no Neptune para monitorar o desempenho de suas instâncias de banco de dados e acompanhar a latência da consulta conforme observada pelo cliente. Consulte Usando CloudWatch para monitorar o desempenho da instância de banco de dados no Neptune.
