Usar a transição ou o failover em um Amazon Aurora Global Database

Um banco de dados global do Aurora fornece maior proteção à continuidade dos negócios e recuperação de desastres (BCDR) do que a alta disponibilidade padrão fornecida por um cluster de banco de dados do Aurora em uma única Região da AWS. Ao usar um banco de dados global do Aurora, você pode planejar e se recuperar de desastres regionais reais ou concluir as interrupções de serviço com rapidez. A recuperação de desastres geralmente é motivada pelos dois objetivos de negócios a seguir:

A troca ou o failover de um banco de dados global do Aurora envolve a promoção de um cluster de banco de dados em uma das regiões secundárias do banco de dados global para que seja o cluster de banco de dados principal. O termo “interrupção regional” é frequentemente usado para descrever uma variedade de cenários de falha. O pior cenário pode ser uma interrupção generalizada causada por um evento catastrófico que afeta centenas de quilômetros quadrados. No entanto, a maioria das interrupções é muito mais localizada, afetando apenas um pequeno subconjunto de serviços de nuvem ou sistemas de clientes. Considere o escopo completo da interrupção para garantir que o failover entre regiões seja a solução adequada e para escolher o método de failover apropriado para a situação. A opção pela abordagem de failover ou de transição depende do cenário específico de interrupção:

Recuperar um banco de dados global Amazon Aurora de uma interrupção não planejada

Em ocasiões muito raras, seu Aurora Global Database pode sofrer uma interrupção inesperada em sua Região da AWS principal. Se isso acontecer, o cluster de banco de dados primário do Aurora e o respectivo nó de gravador não estarão disponíveis, e a replicação entre o cluster primário e os secundários cessará. Para minimizar o tempo de inatividade (RTO) e a perda de dados (RPO), você pode trabalhar rapidamente para executar um failover entre regiões.

Há dois métodos de falha em uma situação de recuperação de desastres:

Failovers planejados gerenciados para o Aurora Global Database

Essa abordagem destina-se à continuidade dos negócios no caso de um desastre regional real ou de uma interrupção completa do nível de serviço.

Durante um failover gerenciado, o cluster principal sofre failover para que você escolha a região secundária, enquanto a topologia de replicação existente do banco de dados global do Aurora é mantida. O cluster secundário escolhido promove um dos nós somente leitura ao status de gravador completo. Essa etapa permite que o cluster assuma a função de cluster primário. O banco de dados ficará indisponível por um curto período enquanto o cluster estiver assumindo a nova função. Os dados que não foram replicados do cluster primário antigo para o cluster secundário escolhido são perdidos quando esse secundário se torna o novo principal.

Para minimizar a perda de dados, recomendamos que você faça o seguinte antes de usar esse recurso:

Durante um failover gerenciado, o cluster de banco de dados secundário escolhido é promovido à sua nova função como primário. No entanto, ele não herda as várias opções de configuração do cluster de banco de dados primário. Uma incompatibilidade na configuração pode levar a problemas de performance, incompatibilidades de workload e outros comportamentos anômalos. Para evitar esses problemas, recomendamos que você resolva as diferenças entre os clusters de banco de dados globais Aurora para o seguinte:

Normalmente, o cluster secundário escolhido assume a função principal em alguns minutos. Assim que o nó de gravação da nova região principal estiver disponível, você poderá conectar suas aplicações a ele e retomar suas workloads. Depois que o Aurora promove o novo cluster primário, ele reconstrói automaticamente todos os clusters adicionais da região secundária.

Como os bancos de dados globais do Aurora usam replicação assíncrona, o atraso na replicação em cada região secundária pode variar. O Aurora reconstrói essas regiões secundárias para ter exatamente os mesmos dados de um ponto no tempo que o novo cluster da região primária. A duração da tarefa de reconstrução completa pode levar de alguns minutos a várias horas, dependendo do tamanho do volume de armazenamento e da distância entre as regiões. Quando os clusters da região secundária terminam de ser reconstruídos com base na nova região primária, eles ficam disponíveis para acesso de leitura.

Assim que o novo gravador principal for promovido e disponibilizado, o cluster da nova região primária poderá lidar com operações de leitura e gravação no banco de dados global do Aurora. Certifique-se de alterar o endpoint de sua aplicação para usar o novo endpoint. Se você aceitou os nomes fornecidos ao criar o banco de dados global Aurora, poderá alterar o endpoint removendo -ro da string de endpoint do cluster promovido em seu aplicativo.

Por exemplo, o endpoint do cluster secundário my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com torna-se my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com quando esse cluster é promovido para primário.

Se você estiver usando o RDS Proxy, redirecione as operações de gravação de sua aplicação para o endpoint de leitura/gravação apropriado do proxy associado ao novo cluster primário. Esse endpoint do proxy pode ser o endpoint padrão ou um endpoint de leitura/gravação personalizado. Para ter mais informações, consulte Como os endpoints do RDS Proxy funcionam com bancos de dados globais.

Para restaurar a topologia original do cluster de banco de dados global, o Aurora monitora a disponibilidade da antiga região primária. Assim que essa região estiver íntegra e disponível novamente, o Aurora a adicionará automaticamente ao cluster global como uma região secundária. Antes de criar o novo volume de armazenamento na antiga região primária, o Aurora tenta capturar um snapshot do volume de armazenamento antigo no ponto da falha. Ele faz isso para que você possa usá-lo para recuperar os dados perdidos. Se essa operação for bem-sucedida, o Aurora colocará esse snapshot chamado “rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp” na seção de snapshots do AWS Management Console. Você também pode ver esse snapshot listado nas informações retornadas pela operação de API DescribeDBClusterSnapshots.

Depois que a topologia original for restaurada, você poderá fazer failback do banco de dados global para a região primária original executando uma operação de transição quando fizer mais sentido para seus negócios e sua workload. Para isso, siga as etapas em Realizar transições para o Amazon Aurora Global Database.

Você pode fazer failover de seu banco de dados global Aurora usando o AWS Management Console, a AWS CLI ou a API do RDS.

Como iniciar o processo de failover no banco de dados global do Aurora

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. Escolha Bancos de dados e localize o banco de dados global Aurora que você deseja fazer failover.

3. Selecione Fazer troca ou failover do banco de dados global no menu Ações.

   

4. Escolha Fazer failover (permitir perda de dados).

   

5. Em Novo cluster primário, escolha um cluster ativo em uma das Regiões da AWS secundárias para ser o novo cluster primário.

6. Se solicitado, insira confirm e escolha Confirmar.

Quando o failover for concluído, você verá os clusters de banco de dados do Aurora e o estado atual deles na lista Bancos de dados, como mostrado na imagem a seguir.

Como iniciar o processo de failover no banco de dados global do Aurora

Use o failover-global-cluster comando CLI falhar sobre seu Aurora banco de dados global. Com o comando, passe valores para os seguintes parâmetros.

• --region: especifique a Região da AWS onde está sendo executado o cluster de banco de dados secundário que você quer que seja o novo primário para o banco de dados global do Aurora.

• --global-cluster-identifier – Especifique o nome do banco de dados globalAurora.

• --target-db-cluster-identifier: especifique o nome do recurso da Amazon (ARN) do cluster de banco de dados do Aurora que você deseja promover para que seja o novo principal para o banco de dados global do Aurora.

• --allow-data-loss: torne isso explicitamente uma operação de failover em vez de uma operação de transição. Uma operação de failover pode resultar em alguma perda de dados se os componentes de replicação assíncrona não tiverem concluído o envio de todos os dados replicados para a região secundária.

Para Linux, macOS ou Unix:

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Para Windows:

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

Para fazer failover de um banco de dados global Aurora, execute a operação de API FailOverGlobalCluster.

Realizar failovers manuais para bancos de dados globais do Aurora

Em alguns ambientes, você pode não conseguir usar o processo de failover gerenciado. Um exemplo é se os clusters de banco de dados primários e secundários não estiverem executando versões de mecanismo compatíveis. Nesse caso, você pode seguir esse processo manual para transferir o banco de dados global para a região secundária de destino.

Certifique-se de que as gravações de aplicações sejam enviadas para o cluster de banco de dados Aurora correto antes, durante e depois de fazer essas alterações. Isso evita inconsistências de dados entre os clusters de banco de dados no Aurora Global Database (problemas de cérebro dividido).

Se você executou essa reconfiguração em resposta a uma interrupção em uma Região da AWS, você pode tornar a Região da AWS a principal novamente após a interrupção ser resolvida. Para isso, adicione a antiga Região da AWS ao novo banco de dados global e, depois, use o processo de transição para trocar a respectiva função. O banco de dados global do Aurora deve usar uma versão do Aurora PostgreSQL ou Aurora MySQL que comporte transições. Para ter mais informações, consulte Realizar transições para o Amazon Aurora Global Database.

Realizar transições para o Amazon Aurora Global Database

Ao usar transições, é possível alterar a região do cluster primário rotineiramente. Essa abordagem destina-se a ambientes controlados, como manutenção operacional e outros procedimentos operacionais planejados.

Há três casos de uso comuns para o uso de transições.

Durante uma transição, o Aurora muda o cluster principal para a região secundária escolhida e mantém a topologia de replicação existente do banco de dados global. Antes de iniciar o processo de transição, o Aurora espera que todos os clusters da região secundária estejam totalmente sincronizados com o cluster da região primária. Em seguida, o cluster de banco de dados na região primária torna-se somente leitura e o cluster secundário escolhido promove um dos respectivos nós somente leitura ao status de gravador completo. A promoção desse nó a um gravador permite que esse cluster secundário assuma a função de cluster primário. Como todos os clusters secundários foram sincronizados com o primário no início do processo, o novo primário continua as operações para o banco de dados global Aurora sem perder dados. Seu banco de dados fica indisponível por um curto período enquanto os clusters primários e secundários selecionados estão assumindo suas novas funções.

Para otimizar a disponibilidade do aplicativo, recomendamos que você faça o seguinte antes de usar esse recurso:

Durante uma transição, o cluster de banco de dados secundário escolhido é promovido à nova função como primário. No entanto, ele não herda as várias opções de configuração do cluster de banco de dados primário. Uma incompatibilidade na configuração pode levar a problemas de performance, incompatibilidades de workload e outros comportamentos anômalos. Para evitar esses problemas, recomendamos que você resolva as diferenças entre os clusters de banco de dados globais Aurora para o seguinte:

Quando o processo de transição for concluído, o cluster de banco de dados do Aurora promovido poderá lidar com operações de gravação para o banco de dados global do Aurora. Certifique-se de alterar o endpoint de sua aplicação para usar o novo endpoint. Se você aceitou os nomes fornecidos ao criar o banco de dados global Aurora, poderá alterar o endpoint removendo -ro da string de endpoint do cluster promovido em seu aplicativo.

Por exemplo, o endpoint do cluster secundário my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com torna-se my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com quando esse cluster é promovido para primário.

Se você estiver usando o RDS Proxy, redirecione as operações de gravação de sua aplicação para o endpoint de leitura/gravação apropriado do proxy associado ao novo cluster primário. Esse endpoint do proxy pode ser o endpoint padrão ou um endpoint de leitura/gravação personalizado. Para ter mais informações, consulte Como os endpoints do RDS Proxy funcionam com bancos de dados globais.

Você pode fazer a transição do banco de dados global do Aurora usando o AWS Management Console, a AWS CLI ou a API do RDS.

Como realizar a transição no banco de dados global do Aurora

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. Escolha Bancos de dados e localize o banco de dados global do Aurora no qual você deseja realizar a transição.

3. Selecione Fazer troca ou failover do banco de dados global no menu Ações.

   

4. Escolha Troca.

   

5. Em Novo cluster primário, escolha um cluster ativo em uma das Regiões da AWS secundárias para ser o novo cluster primário.

6. Selecione a opção Confirmar.

Quando a transição for concluída, você verá os clusters de banco de dados do Aurora e as funções atuais deles na lista Bancos de dados, como mostrado na imagem a seguir.

Como realizar a transição em um banco de dados global do Aurora

Use o comando switchover-global-cluster da CLI para realizar a transição do banco de dados global do Aurora. Com o comando, passe valores para os seguintes parâmetros.

• --region: especifique a Região da AWS em que o cluster de banco de dados primário do Aurora Global Database está sendo executado.

• --global-cluster-identifier – Especifique o nome do banco de dados globalAurora.

• --target-db-cluster-identifier – Especifique o Nome do recursos da Amazon (ARN) do cluster de banco de dados Aurora que você deseja promover para ser o principal para o banco de dados global Aurora.

Para Linux, macOS ou Unix:

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Para Windows:

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

Para realizar a transição em um banco de dados global do Aurora, execute a operação de API SwitchoverGlobalCluster.

Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–

Com um banco de dados global baseado em Aurora PostgreSQL, você pode gerenciar o objetivo de ponto de recuperação (RPO) para o banco de dados global do Aurora usando o parâmetro rds.global_db_rpo. O RPO representa a quantidade máxima de dados que podem ser perdidos em caso de interrupção.

Quando você define um RPO para seu banco de dados global baseado emAurora PostgreSQL–, Aurora monitora o tempo de atraso de RPO de todos os clusters secundários para garantir que pelo menos um cluster secundário permaneça dentro da janela RPO de destino. O tempo de atraso do RPO é outra métrica baseada no tempo.

O RPO é usado quando o banco de dados retoma as operações em uma nova Região da AWS após um failover. O Aurora avalia os tempos de atraso de RPO e RPO para confirmar (ou bloquear) transações no primário da seguinte forma:

Em outras palavras, se todos os clusters secundários estiverem atrás do RPO de destino, Aurora pausará as transações no cluster primário até que pelo menos um dos clusters secundários seja atingidos. As transações pausadas são retomadas e confirmadas assim que o tempo de atraso de pelo menos um cluster de banco de dados secundário se torna menor que o RPO. O resultado é que nenhuma transação pode confirmar até que o RPO seja atendido.

O parâmetro rds.global_db_rpo é dinâmico. Se você decidir que não quer que todas as transações de gravação sejam proteladas até que o atraso diminua o suficiente, você pode redefini-lo rapidamente. Nesse caso, a Aurora reconhece e implementa a alteração após um pequeno atraso.

Se você definir esse parâmetro como descrito a seguir, também poderá monitorar as métricas geradas. Você pode fazer isso usando psql ou outra ferramenta para consultar o cluster do banco de dados primário do banco de dados global Aurora e obter informações detalhadas sobre as operações do banco de dados global baseado em Aurora PostgreSQL–. Para saber como, consulte Monitorar banco de dados globais baseados no Aurora PostgreSQL.

Configurar o objetivo de ponto de recuperação

O parâmetro rds.global_db_rpo controla a configuração de RPO para um banco de dados PostgreSQL. Este parâmetro é tem suporte de Aurora PostgreSQL. Valores válidos de intervalo rds.global_db_rpo de 20 segundos a 2.147.483.647 segundos (68 anos). Escolha um valor realista para atender às suas necessidades de negócios e caso de uso. Por exemplo, você pode querer permitir até 10 minutos para o seu RPO, caso em que você define o valor para 600.

Você pode definir esse valor para seu banco de dados global baseado no Aurora PostgreSQL usando o AWS Management Console, a AWS CLI ou a API do RDS.

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Visualizar o objetivo de ponto de recuperação

O objetivo de ponto de recuperação (RPO) de um banco de dados global é armazenado no parâmetro rds.global_db_rpo de cada cluster de banco de dados. Você pode se conectar ao endpoint do cluster secundário que deseja visualizar e usar psql para consultar a instância para esse valor.

db-name=>show rds.global_db_rpo;

Se este parâmetro não estiver definido, a consulta retornará o seguinte:

rds.global_db_rpo
-------------------
 -1
(1 row)

Esta próxima resposta é de um cluster de banco de dados secundário que tenha uma configuração de RPO de 1 minuto.

rds.global_db_rpo
-------------------
 60
(1 row)

Você pode igualmente usar a CLI para obter valores para descobrir se rds.global_db_rpo é ativo em alguns dos conjuntos de Aurora banco de dados usando a CLI para obter valores de todos os user parâmetros para o cluster.

Para Linux, macOS ou Unix:

aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Para Windows:

aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

O comando retorna uma saída semelhante à seguinte para todos os parâmetros user que não são default-engine ou parâmetros de cluster de banco de dados system.

{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

Para saber mais sobre a visualização de parâmetros do grupo de parâmetros do cluster, consulte Visualizar valores de parâmetros de um grupo de parâmetros do cluster de banco de dados no Amazon Aurora.

Desabilitar o objetivo de ponto de recuperação

Para desabilitar o RPO, redefina o parâmetro rds.global_db_rpo. É possível redefinir parâmetros usando o AWS Management Console, a AWS CLI ou a API do RDS.

aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"