Recuperar um banco de dados global Aurora de uma interrupção não planejada Realizar transições para bancos de dados globais do Aurora Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–

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:

Objetivo de tempo de recuperação (RTO): o tempo que um sistema leva para retornar a um estado funcional após um desastre. Em outras palavras, o RTO mede o tempo de inatividade. Para um banco de dados globalAurora, o RTO pode estar na ordem dos minutos.
Objetivo de ponto de recuperação (RPO): a quantidade de dados que podem ser perdidos (medidos no tempo) após um desastre ou interrupção de serviço. Essa perda de dados costuma decorrer de um atraso na replicação assíncrona. Para um banco de dados globalAurora, o RPO é normalmente medido em segundos. Com um banco de dados global Aurora PostgreSQL–baseado, você pode usar o parâmetro rds.global_db_rpo para definir e rastrear o limite superior no RPO, mas isso pode afetar o processamento de transações no nó do gravador do cluster primário. Para ter mais informações, consulte Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–.

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:

Failover: use essa abordagem para se recuperar de uma interrupção não planejada. Com ela, você executa um failover entre regiões para um dos clusters de banco de dados secundários no banco de dados global do Aurora. O RPO para essa abordagem geralmente é um valor diferente de zero medido em segundos. A quantidade de perda de dados depende do atraso de replicação do banco de dados global do Aurora em todas as Regiões da AWS no momento da falha. Para saber mais, consulte Recuperar um banco de dados global Amazon Aurora de uma interrupção não planejada.
Transição: essa operação era anteriormente chamada de “failover planejado gerenciado”. Use essa abordagem para ambientes controlados, como manutenção operacional e outros procedimentos operacionais planejados. Como esse recurso sincroniza clusters de banco de dados secundários com o primário antes de fazer outras alterações, o RPO é 0 (sem perda de dados). Para saber mais, consulte Realizar transições para o Amazon Aurora Global Database.

nota

Se você quiser fazer transição ou failover para um cluster de banco de dados secundário do Aurora sem cabeçalho, primeiro precisará adicionar uma instância de banco de dados a ele. Para obter mais informações sobre clusters de banco de dados sem cabeçalho, consulte Criando um cluster de banco de dados Aurora dedicado em uma região secundária.

Tópicos

Recuperar um banco de dados global Amazon Aurora de uma interrupção não planejada
Realizar transições para o Amazon Aurora Global Database
Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–

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:

Failover gerenciado: esse método é recomendado para recuperação de desastres. Ao usá-lo, o Aurora adiciona automaticamente a antiga região primária ao banco de dados global como uma região secundária quando ela se torna disponível novamente. Assim, a topologia original do cluster global é mantida. Para saber como usar esse método, consulte Failovers planejados gerenciados para o Aurora Global Database.
Failover manual: esse método alternativo pode ser usado quando o failover gerenciado não for uma opção; por exemplo, quando as regiões primária e secundária estiverem executando versões de mecanismo incompatíveis. Para saber como usar esse método, consulte Realizar failovers manuais para bancos de dados globais do Aurora.

Importante

Ambos os métodos de failover podem resultar na perda dos dados da transação de gravação que não foram replicados para o secundário escolhido antes da ocorrência do evento de failover. No entanto, o processo de recuperação que promove uma instância de banco de dados no cluster de banco de dados secundário escolhido para ser a instância de banco de dados principal do gravador garante que os dados estejam em um estado transacionalmente consistente.

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.

nota

Você só poderá realizar um failover gerenciado de banco de dados entre regiões em um banco de dados global do Aurora se os clusters de banco de dados primário e secundário tiverem as mesmas versões principal, secundária e nível de patch do mecanismo. No entanto, os níveis de patch podem ser diferentes, dependendo da versão secundária do mecanismo. Para ter mais informações, consulte Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões. Se as versões do mecanismo forem incompatíveis, você poderá executar o failover manualmente seguindo as etapas em Realizar failovers manuais para bancos de dados globais do Aurora.

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

Deixe os aplicativos offline para evitar que as gravações sejam enviadas para o cluster primário do banco de dados global Aurora.
Verifique os tempos de atraso para ver se há todos os clusters de banco de dados Aurora secundários no banco de dados global Aurora. Escolher a região secundária com o menor atraso de replicação pode minimizar a perda de dados na atual região primária com falha. Para todos os bancos de dados globais baseados no Aurora PostgreSQL e para bancos de dados globais baseados no Aurora MySQL a partir das versões 3.04.0 e posteriores do mecanismo, ou 2.12.0 e posteriores, use o Amazon CloudWatch para visualizar a métrica AuroraGlobalDBRPOLag para todos os clusters de banco de dados secundários. Para versões secundárias anteriores dos bancos de dados globais baseados no Aurora MySQL, veja a métrica AuroraGlobalDBReplicationLag. Essa métrica informa a distância (em milissegundos) de um secundário em relação ao cluster de banco de dados primário.

Para ter mais informações sobre métricas CloudWatch de Aurora, consulte Métricas no nível do cluster do Amazon Aurora.

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:

Configurar o parameter group do cluster de banco de dados Aurora para o novo primário, se necessário – Você pode configurar seus parameter groups de cluster de banco de dados Aurora independentemente de cada cluster Aurora em seu banco de dados global Aurora. Por isso, quando você promove um cluster de banco de dados secundário para assumir a função primária, o grupo de parâmetros do secundário pode ser configurado diferentemente do grupo do primário. Em caso afirmativo, modifique o parameter group do cluster de banco de dados secundário promovido para estar em conformidade com as configurações do cluster principal. Para saber como, consulte Modificando parâmetros para um banco de dados do Aurora global.
Configurar ferramentas e opções de monitoramento, como Amazon CloudWatch Events e alarmes – Configurar o cluster de banco de dados promovido com a mesma capacidade de registro, alarmes e assim por diante, conforme necessário para o banco de dados global. Tal como acontece com os parameter groups, a configuração desses recursos não é herdada do primário no processo de failover. Algumas métricas do CloudWatch, como atraso na replicação, só estão disponíveis para regiões secundárias. Assim, um failover altera a forma de visualizar essas métricas e definir alarmes para elas, e pode exigir alterações em qualquer painel predefinido. Para ter mais informações sobre clusters de banco de dados Aurora e monitoramento, consulte Overview of monitoring (Visão geral do monitoramento) Amazon Aurora.
Configurar integrações com outros produtos da AWS: se seu banco de dados global Aurora se integrar a produtos da AWS, como o AWS Secrets Manager, o AWS Identity and Access Management, o Amazon S3 e o AWS Lambda, será necessário verificar se eles estão configurados conforme necessário. Para ter mais informações sobre como integrar Aurora Global Databases com IAM, Amazon S3 e Lambda, consulte Usar bancos de dados globais do Amazon Aurora com outros produtos da AWS. Para saber mais sobre o Secrets Manager, consulte Como automizar a replicação de segredos no AWS Secrets Manager entre Regiões da AWS.

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.

nota

O snapshot do volume de armazenamento antigo é um snapshot do sistema sujeito ao período de retenção de backup configurado no antigo cluster primário. Para preservar esse instantâneo fora do período de retenção, você pode copiá-lo para salvá-lo como um snapshot manual. Para saber mais sobre como copiar snapshots, incluindo os preços, consulte Copiar um snapshot de cluster de banco de dados.

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

Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
Escolha Bancos de dados e localize o banco de dados global Aurora que você deseja fazer failover.
Selecione Fazer troca ou failover do banco de dados global no menu Ações.
Escolha Fazer failover (permitir perda de dados).
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.
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.

Exibição da lista de bancos de dados com o banco de dados global selecionado. Agora, o cluster secundário selecionado aparece como tendo a função de cluster principal e o antigo principal com a função de um cluster secundário.

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.

dica

Recomendamos que você entenda esse processo antes de usá-lo. Tenha um plano pronto para prosseguir rapidamente ao primeiro sinal de uma questão em toda a região. Você pode se preparar para identificar a região secundária com o menor atraso de replicação usando o Amazon CloudWatch regularmente para rastrear os tempos de atraso dos clusters secundários. Procure testar seu plano para verificar se os procedimentos estão completos e precisos, bem como se a equipe está treinada para executar um failover de recuperação de desastres antes que isso realmente aconteça.

Como realizar um failover manual para um cluster secundário após uma interrupção não planejada na região principal

Interrompa a emissão de instruções de DML e outras operações de gravação para o cluster do banco de dados Aurora principal na Região da AWS com a interrupção.
Identifique um cluster de banco de dados Aurora de uma Região da AWS secundária para usar como um novo cluster de banco de dados primário. Se você tiver duas (ou mais) Regiões da AWS secundárias no banco de dados global do Aurora, escolha o cluster secundário que tem o menor atraso de replicação.
Desanexe o cluster de banco de dados secundário escolhido do banco de dados global Aurora.

A remoção de um cluster de banco de dados secundário de um banco de dados global Aurora interrompe imediatamente a replicação do primário para este secundário e promove-o ao cluster de banco de dados Aurora provisionado autônomo com recursos completos de leitura/gravação. Quaisquer outros clusters de banco de dados Aurora secundários associados ao cluster primário na região com a interrupção ainda estão disponíveis e podem aceitar chamadas de seu aplicativo. Eles também consomem recursos. Como você está recriando o Aurora Global Database, remova os outros clusters de banco de dados secundários antes de criar o Aurora Global Database nas etapas a seguir. Isso evita inconsistências de dados entre os clusters de banco de dados no Aurora Global Database (problemas de cérebro dividido).

Para obter as etapas detalhadas para desanexar, consulte Remover um cluster de um banco de dados global do Amazon Aurora.
Reconfigure seu aplicativo para enviar todas as operações de gravação para esse cluster de banco de dados Aurora autônomo agora usando seu novo endpoint. Se você aceitou os nomes fornecidos ao criar o banco de dados global Aurora, poderá alterar o endpoint removendo a -ro string do endpoint do cluster em seu aplicativo.

Por exemplo, o endpoint do cluster secundário my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com se torna my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com quando esse cluster é separado do banco de dados global Aurora.

Esse cluster de banco de dados Aurora se torna o cluster principal de um novo Aurora Global Database quando você começa a adicionar regiões a ele, na próxima etapa.

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.
Adicione uma Região da AWS ao cluster de banco de dados. Quando você faz isso, o processo de replicação de primário para secundário começa. Para obter as etapas detalhadas para adicionar uma região, consulte Adicionar uma Região da AWS a um Amazon Aurora Global Database.
Adicione mais Regiões da AWS conforme necessário para recriar a topologia necessária para oferecer suporte à aplicação.

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

nota

Anteriormente, as transições eram chamadas de “failovers planejados gerenciados”.

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.

Para requisitos de “alternância regional” impostos a setores específicos. Por exemplo, os regulamentos de serviços financeiros podem querer que os sistemas de nível 0 mudem para uma região diferente por vários meses a fim de garantir que os procedimentos de recuperação de desastres sejam executados regularmente.
Para aplicações multirregionais ininterruptas (dia e noite). Por exemplo, uma empresa pode querer fornecer gravações de menor latência em diferentes regiões com base no horário comercial em diferentes fusos horários.
Como um método sem perda de dados para fazer failback para a região primária original após um failover.

nota

As transições foram projetadas para serem usadas em um banco de dados global do Aurora íntegro. Para se recuperar de uma interrupção não planejada, siga o procedimento apropriado em Recuperar um banco de dados global Amazon Aurora de uma interrupção não planejada.

Para realizar uma transição, o cluster de banco de dados secundários de destino deve estar executando exatamente a mesma versão do mecanismo primário, inclusive o nível do patch, dependendo da versão do mecanismo. Para ter mais informações, consulte Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões. Antes de iniciar a transição, verifique as versões do mecanismo no cluster global para garantir que elas sejam compatíveis com a transição gerenciada entre regiões e atualize-as se necessário.

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:

Execute essa operação em períodos de pouca demanda ou em outro momento quando as gravações no cluster de banco de dados primário forem mínimas.
Deixe os aplicativos offline para evitar que as gravações sejam enviadas para o cluster primário do banco de dados global Aurora.
Verifique os tempos de atraso para ver se há todos os clusters de banco de dados Aurora secundários no banco de dados global Aurora. Para todos os bancos de dados globais baseados no Aurora PostgreSQL e para bancos de dados globais baseados no Aurora MySQL a partir das versões 3.04.0 e posteriores do mecanismo, ou 2.12.0 e posteriores, use o Amazon CloudWatch para visualizar a métrica AuroraGlobalDBRPOLag para todos os clusters de banco de dados secundários. Para versões secundárias anteriores dos bancos de dados globais baseados no Aurora MySQL, veja a métrica AuroraGlobalDBReplicationLag. Essa métrica informa a distância (em milissegundos) de um secundário em relação ao cluster de banco de dados primário. Esse valor é diretamente proporcional ao tempo que o Aurora levará para concluir a transição. Portanto, quanto maior o valor do atraso, mais tempo a transição levará.

Para ter mais informações sobre métricas CloudWatch de Aurora, consulte Métricas no nível do cluster do Amazon Aurora.

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:

Configurar o parameter group do cluster de banco de dados Aurora para o novo primário, se necessário – Você pode configurar seus parameter groups de cluster de banco de dados Aurora independentemente de cada cluster Aurora em seu banco de dados global Aurora. Isso significa que quando você promove um cluster de banco de dados secundário para assumir a função primária, o parameter group do secundário pode ser configurado de forma diferente do que para o primário. Em caso afirmativo, modifique o parameter group do cluster de banco de dados secundário promovido para estar em conformidade com as configurações do cluster principal. Para saber como, consulte Modificando parâmetros para um banco de dados do Aurora global.
Configurar ferramentas e opções de monitoramento, como Amazon CloudWatch Events e alarmes – Configurar o cluster de banco de dados promovido com a mesma capacidade de registro, alarmes e assim por diante, conforme necessário para o banco de dados global. Tal como ocorre com os grupos de parâmetros, a configuração desses recursos não é herdada do primário no processo de transição. Algumas métricas do CloudWatch, como atraso na replicação, só estão disponíveis para regiões secundárias. Assim, uma transição altera a forma de visualizar essas métricas e definir alarmes para elas, e pode exigir alterações em qualquer painel predefinido. Para ter mais informações sobre clusters de banco de dados Aurora e monitoramento, consulte Overview of monitoring (Visão geral do monitoramento) Amazon Aurora.
Configurar integrações com outros serviços da AWS: se o banco de dados global do Aurora se integrar a serviços da AWS, como o AWS Secrets Manager, o AWS Identity and Access Management, o Amazon S3 e o AWS Lambda, configure as integrações com esses serviços conforme necessário. Para ter mais informações sobre como integrar Aurora Global Databases com IAM, Amazon S3 e Lambda, consulte Usar bancos de dados globais do Amazon Aurora com outros produtos da AWS. Para saber mais sobre o Secrets Manager, consulte Como automizar a replicação de segredos no AWS Secrets Manager entre Regiões da AWS.

nota

Normalmente, a transição de função pode levar alguns minutos. No entanto, a criação de clusters secundários adicionais pode levar de alguns minutos a várias horas, dependendo do tamanho do banco de dados e da distância física entre as regiões.

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.

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

Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
Escolha Bancos de dados e localize o banco de dados global do Aurora no qual você deseja realizar a transição.
Selecione Fazer troca ou failover do banco de dados global no menu Ações.
Escolha Troca.
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.
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:

Compromete a transação se pelo menos um cluster de banco de dados secundário tiver um tempo de atraso de RPO menor que o RPO.
Bloqueia a transação se todos os clusters de banco de dados secundários tiverem tempos de atraso de RPO maiores que o RPO. Ele também registra o evento no arquivo de log PostgreSQL e emite eventos de “espera” que mostram as sessões bloqueadas.

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.

Importante

Em um banco de dados global com apenas duas regiões, recomendamos manter o valor padrão do parâmetro rds.global_db_rpo no grupo de parâmetros da região secundária. Caso contrário, o failover para essa região devido à perda da região principal pode fazer com que o Aurora pause as transações. Em vez disso, antes de alterar esse parâmetro para impor um RPO máximo, espere até que o Aurora conclua a reconstrução do cluster na antiga região com falha.

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.

Tópicos

Configurar o objetivo de ponto de recuperação
Visualizar o objetivo de ponto de recuperação
Desabilitar o objetivo de ponto de recuperação

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.

Como definir o RPO

Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
Escolha o cluster principal do seu banco de dados global Aurora e abra a guia Configuration (Configuração) para localizar seu parameter group de cluster de banco de dados. Por exemplo, o parameter group padrão para um cluster de banco de dados primário executando Aurora PostgreSQL 11.7 é default.aurora-postgresql11.

Os grupos de parâmetros não podem ser editados diretamente. Em vez disso, você pode fazer o seguinte:
- Crie um parameter group de cluster de banco de dados personalizado usando o parameter group padrão apropriado como o ponto de partida. Por exemplo, crie um parameter group de cluster de banco de dados personalizado com base no default.aurora-postgresql11.
- Em seu parameter group de banco de dados personalizado, defina o valor do parâmetro rds.global_db_rpo para atender ao seu caso de uso. Os valores válidos são de 20 segundos até o valor inteiro máximo de 2.147.483.647 (68 anos).
- Aplique o parameter group de cluster de banco de dados modificado ao cluster de Aurora banco de dados.

Para ter mais informações, consulte Modificar parâmetros em um grupo de parâmetros de cluster de banco de dados.

Para definir o parâmetro rds.global_db_rpo, use o comando CLI modify-db-cluster-parameter-group. No comando, especifique o nome do grupo de parâmetros do cluster primário e os valores para o parâmetro RPO.

O exemplo a seguir define o RPO como 600 segundos (10 minutos) para o grupo de parâmetros de cluster de banco de dados primário chamado my_custom_global_parameter_group.

Para Linux, macOS ou Unix:


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"

Para Windows:


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"

Para modificar o parâmetro rds.global_db_rpo, use a operação de API ModifyDBClusterParameterGroup do Amazon RDS.

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.

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.

Como desabilitar o RPO

Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
No painel de navegação, selecione Parameter groups.
Na lista, escolha o grupo de parâmetros de cluster do banco de dados primário.
Escolha Edit parameters.
Escolha a caixa ao lado do parâmetro rds.global_db_rpo.
Escolha Redefinir.
Quando a tela mostrar Redefinir parâmetros no grupo de parâmetros do banco de dados, escolha Redefinir parâmetros.

Para ter mais informações sobre como redefinir um parâmetro com o console, consulte Modificar parâmetros em um grupo de parâmetros de cluster de banco de dados.

Para redefinir o parâmetro rds.global_db_rpo, use o comando reset-db-cluster-parameter-group .

Para Linux, macOS ou Unix:


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"

Para Windows:


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"

Para redefinir o parâmetro rds.global_db_rpo, use a operação ResetDBClusterParameterGroup da API do Amazon RDS.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Usar o encaminhamento de gravação no Aurora PostgreSQL

Monitorar um banco de dados global Aurora