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á.
# Usar a replicação entre regiões de fluxos do Neptune para recuperação de desastres
O Neptune oferece duas maneiras de implementar recursos de failover entre regiões:
+ Cópia e restauração de snapshots entre regiões
+ Usar fluxos do Neptune para replicar dados entre dois clusters em duas regiões diferentes.
A cópia e a restauração de snapshots entre regiões têm a menor sobrecarga operacional para recuperar um cluster do Neptune em uma região diferente. No entanto, copiar um snapshot entre regiões pode exigir um tempo significativo de transferência de dados, já que um snapshot é um backup completo do cluster do Neptune. Como resultado, a cópia e a restauração de snapshots entre regiões podem ser usadas para situações que exigem apenas um objetivo de ponto de recuperação (RPO) de horas e um objetivo de tempo de recuperação (RTO) de horas.
Um objetivo de ponto de recuperação (RPO) é medido pelo tempo entre os backups. Ele define quantos dados podem ser perdidos entre o momento em que o último backup foi feito e o momento em que o banco de dados foi recuperado.
Um objetivo de tempo de recuperação (RTO) é medido pelo tempo necessário para realizar uma operação de recuperação. Esse é o tempo necessário para que o cluster de banco de dados realize o failover em um banco de dados recuperado após a ocorrência de uma falha.
Os fluxos do Neptune oferecem uma maneira de manter um cluster de backup do Neptune sempre sincronizado com o cluster de produção principal. Se ocorrer uma falha, o banco de dados fará o failover para o cluster de backup. Isso reduz o RPO e o RTO para minutos, já que os dados são constantemente copiados no cluster de backup, que está imediatamente disponível como destino de failover a qualquer momento.
A desvantagem de usar os fluxos do Neptune dessa forma é que tanto a sobrecarga operacional necessária para manter os componentes de replicação quanto o custo de ter um segundo cluster de banco de dados do Neptune on-line o tempo todo podem ser significativos.
# Configurando a Neptune-to-Neptune replicação
O cluster de banco de dados de produção principal reside em uma VPC em uma região de origem específica. Há três itens principais que você precisa replicar ou emular em uma região de recuperação diferente para fins de recuperação de desastres:
+ Os dados armazenados no cluster.
+ A configuração do cluster principal. Isso incluiria se ele usa a autenticação do IAM, se é criptografado, os parâmetros de cluster de banco de dados, os parâmetros de instância, os tamanhos de instância, etc.).
+ A topologia de rede que ele usa, incluindo a VPC de destino, os grupos de segurança, etc.
Você pode usar o APIs gerenciamento do Neptune, como o seguinte, para coletar essas informações:
+ [`DescribeDBClusters`](api-clusters.md#DescribeDBClusters)
+ [`DescribeDBInstances`](api-instances.md#DescribeDBInstances)
+ [`DescribeDBClusterParameters`](api-parameters.md#DescribeDBClusterParameters)
+ [`DescribeDBParameters`](api-parameters.md#DescribeDBParameters)
+ [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
Com as informações coletadas, é possível usar o procedimento a seguir para configurar um cluster de backup em uma região diferente, para a qual o cluster de produção pode fazer failover em caso de falha.
## Habilitar fluxos do Neptune
É possível usar o [ModifyDBClusterParameterGroup](api-parameters.md#ModifyDBClusterParameterGroup) para definir o parâmetro `neptune_streams` como 1. Assim, reinicialize todas as instâncias no cluster de banco de dados para que a alteração tenha efeito.
É uma boa ideia realizar pelo menos uma operação de adição ou atualização no cluster de banco de dados de origem após a ativação dos fluxos do Neptune. Isso preenche o fluxo de alterações com pontos de dados que podem ser referenciados posteriormente ao ressincronizar o cluster de produção com o cluster de backup.
## Criar uma VPC na região em que você deseja configurar o cluster de backup
Antes de criar um cluster de banco de dados do Neptune em uma região diferente do cluster principal, você precisa estabelecer uma nova VPC na região de destino para hospedar o cluster. A conectividade entre os clusters primário e de backup é estabelecida por meio do emparelhamento de VPC, que usa o tráfego entre sub-redes privadas de forma diferente. VPCs No entanto, para estabelecer o emparelhamento de VPC entre duas VPCs, elas não devem ter blocos CIDR ou espaços de endereço IP sobrepostos. Isso significa que você não pode simplesmente usar a VPC padrão nas duas regiões, porque o bloco CIDR para uma VPC padrão é sempre o mesmo (`172.31.0.0/16`).
Você pode usar uma VPC existente na região de destino, desde que ela atenda às seguintes condições:
+ Ela não tem um bloco CIDR que se sobreponha ao bloco CIDR da VPC na qual o cluster principal está localizado.
+ Ela ainda não está emparelhado com outra VPC que tenha o mesmo bloco CIDR da VPC em que seu cluster principal está localizado.
Se não houver uma VPC adequada disponível na região de destino, crie uma usando a API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html) do Amazon EC2.
## Criar um snapshot do cluster principal e restaurá-lo na região de backup de destino
Agora você cria um cluster do Neptune em uma VPC apropriada na região de backup de destino que é uma cópia do cluster de produção:
**Fazer uma cópia do cluster de produção na região de backup**
1. Na sua região de backup de destino, recrie os parâmetros e grupos de parâmetros usados pelo cluster de banco de dados de produção. Você pode fazer isso usando [`CreateDBClusterParameterGroup`](api-parameters.md#CreateDBClusterParameterGroup), [`CreateDBParameterGroup`](api-parameters.md#CreateDBParameterGroup), [`ModifyDBClusterParameterGroup`](api-parameters.md#ModifyDBClusterParameterGroup) e [`ModifyDBParameterGroup`](api-parameters.md#ModifyDBParameterGroup).
Observe que, atualmente, o [`CopyDBClusterParameterGroup`](api-parameters.md#CopyDBClusterParameterGroup)e [`CopyDBParameterGroup`](api-parameters.md#CopyDBParameterGroup) APIs não oferece suporte à cópia entre regiões.
1. Use [`CreateDBClusterSnapshot`](api-snapshots.md#CreateDBClusterSnapshot) para criar um snapshot do cluster de produção na VPC na região de produção.
1. Use [`CopyDBClusterSnapshot`](api-snapshots.md#CopyDBClusterSnapshot) para copiar o snapshot na VPC na região de backup de destino.
1. Use [`RestoreDBClusterFromSnapshot`](api-snapshots.md#RestoreDBClusterFromSnapshot) para criar um cluster de banco de dados na VPC na região de backup de destino usando o snapshot copiado. Use as configurações e os parâmetros que você copiou do cluster de produção principal.
1. O novo cluster do Neptune agora existe, mas não contém nenhuma instância. Use [`CreateDBInstance`](api-instances.md#CreateDBInstance)para criar uma nova primary/writer instância que tenha o mesmo tipo e tamanho da instância de gravação do seu cluster de produção. Não há necessidade de criar réplicas de leitura adicionais neste momento, a menos que sua instância de backup seja usada para atender a leitura I/O na região de destino antes de um failover.
## Estabelecer o emparelhamento da VPC entre a VPC do cluster principal e a VPC do novo cluster de backup
Ao configurar o emparelhamento da VPC, você permite que a VPC do cluster principal se comunique com a VPC do cluster de backup como se fosse uma única rede privada. Para fazer isso, siga as seguintes etapas:
1. Na VPC do cluster de produção, chame a API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html) para estabelecer a conexão de emparelhamento.
1. Na VPC do cluster de backup de destino, chame a API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html) para aceitar a conexão de emparelhamento.
1. Na VPC do cluster de produção, use a API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) para adicionar uma rota à tabela de rotas da VPC que redireciona todo o tráfego para o bloco CIDR da VPC de destino para que ela use a lista de prefixos de emparelhamento da VPC.
1. Da mesma forma, a partir da VPC do cluster de backup de destino, use a API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) para adicionar uma rota à tabela de rotas da VPC que direciona o tráfego para a VPC do cluster principal.
## Configurar a infraestrutura de replicação de fluxos do Neptune
Agora que os dois clusters foram implantados e a comunicação de rede entre as duas regiões foi estabelecida, use o [CloudFormation modelo Neptune-to-Neptune para implantar a função Lambda do consumidor do Neptune](streams-consumer-setup.md) Streams com a infraestrutura adicional que suporta a replicação de dados. Faça isso na VPC do cluster de produção principal.
Os parâmetros que você precisará fornecer para essa CloudFormation pilha são:
+ **`NeptuneStreamEndpoint`**: o endpoint de fluxos para o cluster principal, em formato de URL. Por exemplo: `https://(cluster name):8182/pg/stream`.
+ **`QueryEngine`**: deve ser `gremlin`, `sparql` ou `openCypher`.
+ **`RouteTableIds`**: permite adicionar rotas para um endpoint da VPC do DynamoDB e um endpoint da VPC de monitoramento.
Dois parâmetros adicionais, ou seja, `CreateMonitoringEndpoint` e `CreateDynamoDBEndpoint`, também deverão ser definidos como verdadeiros se ainda não existirem na VPC do cluster principal. Se eles já existirem, verifique se estão definidos como falsos ou a CloudFormation criação falhará.
+ **`SecurityGroupIds`**: especifica o grupo de segurança usado pelo consumidor do Lambda para se comunicar com o endpoint de fluxos do Neptune do cluster principal.
No cluster de backup de destino, anexe um grupo de segurança que viabilize o tráfego proveniente desse grupo de segurança.
+ **`SubnetIds`**: uma lista de IDs de sub-rede na VPC do cluster principal que pode ser usada pelo consumidor do Lambda para se comunicar com o cluster principal.
+ **`TargetNeptuneClusterEndpoint`**: o endpoint do cluster (somente nome do host) do cluster de backup de destino.
+ **`TargetAWSRegion`**— A AWS região do cluster de backup de destino, como`us-east-1`). Você deve fornecer esse parâmetro somente quando a AWS região do cluster de backup de destino for diferente da região do cluster de origem do Neptune, como no caso da replicação entre regiões. Se as regiões de origem e de destino forem iguais, esse parâmetro será opcional.
Observe que, se o `TargetAWSRegion` valor não for uma [AWS região válida compatível com o Neptune](limits.md#limits-regions), o processo falhará.
+ **`VPC`**: o ID da VPC do cluster principal.
Todos os outros parâmetros podem ser deixados com seus valores padrão.
Depois que o CloudFormation modelo for implantado, o Neptune começará a replicar todas as alterações do cluster primário para o cluster de backup. Você pode monitorar essa replicação nos CloudWatch registros gerados pela função de consumidor do Lambda.
# Outras considerações
+ Se precisar usar a autenticação do IAM entre os clusters primário e de backup, você também pode configurá-la ao invocar o CloudFormation modelo.
+ Se a criptografia em repouso estiver habilitada no cluster principal, pense em como gerenciar as chaves do KMS associadas ao copiar o snapshot na região de destino e associar uma nova chave do KMS na região de destino.
+ Uma prática recomendada é usar o DNS CNAMEs na frente dos endpoints do Neptune usados em seus aplicativos. Então, se você precisar fazer o failover manual para o cluster de backup de destino, eles CNAMEs podem ser alterados para apontar para os endpoints da and/or instância do cluster de destino.