ApsaraDB RDS:Gerenciar failover primário/secundário

Pré-requisitos

• Se a instância for padrão, ela deve pertencer a uma das seguintes edições:

  • Série de Alta Disponibilidade

  • RDS Enterprise Edition

  • Cluster Edition

  Nota

  Instâncias da Basic Series não possuem nó secundário e, portanto, não suportam failover primário/secundário.

• Se a instância for somente leitura, ela deve pertencer à Série de Alta Disponibilidade e utilizar a classe de armazenamento em disco na nuvem.

Informações gerais

• Failover automático: este recurso vem ativado por padrão. Se o nó primário falhar, o RDS transfere automaticamente as cargas de trabalho para o nó secundário. Para mais informações sobre os gatilhos de failover primário/secundário, consulte Motivos para failover primário/secundário.

• Failover manual: mesmo com o failover automático ativado, você pode executar manualmente um failover primário/secundário. O failover manual é útil para simulações de recuperação de desastres ou para cenários como conexão a partir da zona mais próxima em uma implantação multizona.

Para obter informações sobre failover primário/secundário em outros mecanismos de banco de dados, consulte os seguintes tópicos:

• Failover primário/secundário do SQL Server

• Failover primário/secundário automático ou manual do PostgreSQL

• Failover primário/secundário do MariaDB

Impacto

• Um failover primário/secundário causa uma interrupção de serviço que geralmente dura 15 segundos ou menos. Certifique-se de que sua aplicação possua um mecanismo de reconexão automática.

  Se sua aplicação utilizar uma versão antiga do componente Druid para gerenciamento de conexões de banco de dados, ela poderá falhar ao tentar reconectar automaticamente após uma desconexão. Para evitar esse problema, atualize o componente Druid para a versão 1.1.16 ou posterior.

• Se a instância primária tiver instâncias somente leitura anexadas, essas instâncias podem apresentar atraso de dados de vários minutos após o failover. Isso ocorre porque o RDS precisa recriar a tarefa de replicação e sincronizar os dados incrementais.

• O failover primário/secundário não altera o endpoint da instância, mas o endereço IP subjacente pode mudar. Recomendamos usar o endpoint para garantir que sua aplicação continue funcionando conforme o esperado durante o failover.

• Em casos de falha grave na instância, o failover pode levar mais tempo que o habitual.

Alternar manualmente os nós primário e secundário

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde reside a instância RDS. Em seguida, localize a instância RDS e clique em ID da instância.

2. No painel de navegação à esquerda, clique em Service Availability.

3. Na seção Availability Information, clique em Switch Primary/Secondary Instance.

4. Selecione um horário para o failover e clique em Confirm.

   Importante

   Durante um failover primário/secundário, não é possível realizar operações como gerenciar bancos de dados e contas ou alterar o tipo de rede. Recomendamos selecionar Switch immediately using current settings.

   Para instâncias da Cluster Edition, você também pode executar um failover primário/secundário pelo diagrama de topologia da instância na página Basic Information.

Desativar temporariamente o failover automático primário/secundário

O failover automático vem ativado por padrão. Quando o nó primário falha, o RDS alterna automaticamente para o nó secundário. Você pode desativar temporariamente o failover automático nos seguintes cenários:

• Para evitar impactos na disponibilidade do sistema durante grandes promoções de vendas.

• Para impedir que um failover introduza variáveis inesperadas durante atualizações críticas da aplicação.

• Durante eventos importantes ou períodos de garantia de estabilidade, para evitar que um failover primário/secundário afete a estabilidade do sistema.

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde reside a instância RDS. Em seguida, localize a instância RDS e clique em ID da instância.

2. No painel de navegação à esquerda, clique em Service Availability.

3. Na seção Availability Information, clique em Automatic Primary/Secondary Switchover.

   Nota

   Se o botão Automatic Primary/Secondary Switchover não estiver visível, verifique se sua instância atende aos pré-requisitos descritos neste tópico.

4. Selecione Temporarily Disable, defina o horário em Disable Until e clique em Confirm.

   Nota

   • O failover automático primário/secundário é reativado automaticamente após o horário especificado em Disable Until.

   • O período de desativação padrão é de um dia. É possível definir um período de até sete dias. O período termina às 23:59:59 do último dia.

Após concluir a configuração, visualize o horário de expiração da desativação temporária na página Service Availability.

Visualizar logs de failover primário/secundário

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde reside a instância RDS. Em seguida, localize a instância RDS e clique em ID da instância.

2. No painel de navegação à esquerda, clique em Service Availability.

3. Na seção Primary/Secondary Switchover Logs, especifique um intervalo de tempo para consultar os logs.

   

Perguntas frequentes

• P: Posso acessar o nó secundário?

  R: O acesso aos nós secundários é permitido apenas em instâncias da Cluster Edition. Os nós secundários de outras edições não estão acessíveis.

• P: Após um failover primário/secundário, preciso alternar manualmente de volta para o nó primário original?

  R: Não. Os dados nos nós primário e secundário são totalmente sincronizados. Após o failover, o antigo nó secundário torna-se o novo nó primário. Nenhuma ação adicional é necessária.

• P: Após um failover primário/secundário, o status da instância não retornou para Running há mais de 10 minutos. Quais são as possíveis causas e como resolver o problema?

  Quando um evento anormal aciona um failover de alta disponibilidade (HA) no RDS, as conexões persistentes da aplicação podem não detectar alterações no status da conexão. Se você não configurar um valor de tempo limite de socket, a aplicação aguardará indefinidamente por um resultado do banco de dados, geralmente atingindo o tempo limite após várias centenas de segundos. Durante esse período, algumas conexões de banco de dados ficam indisponíveis e instruções SQL falham frequentemente. Para evitar conexões inválidas, recomendamos configurar connectTimeout e socketTimeout para prevenir esperas indefinidas durante erros de rede, reduzindo assim o tempo de inatividade.

  Defina os valores de tempo limite com base na sua carga de trabalho e padrões de uso. Para cenários de processamento de transações online (OLTP), recomendamos definir connectTimeout entre 1 e 2 segundos e socketTimeout entre 60 e 90 segundos. Esses valores servem apenas como referência.

APIs relacionadas