Todos os produtos
Search
Central de documentação

ApsaraDB RDS:Primary/secondary switchover

Última atualização: Aug 21, 2026

Este tópico descreve como alternar cargas de trabalho entre instâncias primárias e secundárias do ApsaraDB RDS for MariaDB. Você pode ativar o failover automático primário/secundário para o sistema de banco de dados. Assim, se a instância RDS primária falhar, o sistema transfere automaticamente as cargas de trabalho para a instância RDS secundária. Após o failover, a instância RDS secundária é promovida a nova instância RDS primária, e o endpoint usado para conectar-se ao sistema de banco de dados permanece inalterado. Sua aplicação pode usar esse endpoint para se conectar à nova instância RDS primária. O failover automático primário/secundário garante alta disponibilidade. Também é possível alternar manualmente as cargas de trabalho entre as instâncias RDS primária e secundária.

Na Edição de Alta Disponibilidade do RDS, uma instância RDS secundária funciona como standby para a instância RDS primária do sistema de banco de dados. Os dados da instância RDS primária são sincronizados em tempo real com a instância RDS secundária. Apenas a instância RDS primária está acessível; não é possível acessar a instância RDS secundária diretamente.

Se a instância RDS primária falhar, o sistema transferirá automaticamente as cargas de trabalho para a instância RDS secundária.

Observações de uso

Durante um failover, o service pode sofrer interrupções. Certifique-se de que sua aplicação esteja configurada para reconectar-se automaticamente à instância.

Procedimento

  1. Faça login no console do ApsaraDB RDS.

  2. Na barra de navegação superior, selecione a região onde a instância RDS está localizada.

  3. Localize a instância RDS e clique em ID da instância.

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

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

  6. Selecione um horário para o failover e clique em Ok.

    Durante o failover primário/secundário, diversas operações ficam indisponíveis. Por exemplo, não é possível gerencie bancos de dados e contas ou alterar o tipo de rede. Recomendamos execute o failover primário/secundário durante a janela de manutenção planejada.

    Nota

    Para alterar a janela de manutenção, execute as seguintes etapas:

    1. Clique em modify.

    2. Na seção Configuration Information, modifique a janela de manutenção e clique em Save.

    3. Acesse a página Service Availability, atualize a página e continue o procedimento.

Perguntas frequentes

  • É necessário transferir manualmente as cargas de trabalho da instância RDS secundária de volta para a primária após um failover?

    Não. Após o failover primário/secundário, a transferência manual das cargas de trabalho da instância secundária para a primária não é necessária. Os dados na instância RDS primária são idênticos aos da instância RDS secundária. Depois do failover, a instância RDS secundária passa a funcionar como a nova instância RDS primária, sem necessidade de operações adicionais.

  • Sempre que ocorre um failover primário/secundário, minha instância RDS não funciona conforme o esperado nos 10 minutos seguintes à conclusão do processo. Quais são as possíveis causas? Como resolver esse problema?

    R: Quando uma exceção aciona um failover de alta disponibilidade, conexões persistentes da sua aplicação podem não detectar a alteração no status da conexão. Se nenhum timeout de socket estiver defina, a aplicação aguardará indefinidamente por uma resposta do banco de dados, desconectando-se muitas vezes apenas após centenas de segundos. Nesse período, algumas conexões ao banco de dados não funcionam corretamente, causando falhas em diversas consultas SQL. Para evitar essas conexões inválidas e reduzir o tempo de recuperação, recomendamos configurar os parâmetros connectTimeout e socketTimeout. Isso impede que a aplicação fique aguardando indefinidamente durante um erro de rede.

    Defina os valores de timeout com base na sua carga de trabalho e nos seus padrões de uso específicos. Para cenários de processamento de transações online (OLTP), um ponto de partida recomendado é defina connectTimeout entre 1 e 2 segundos e socketTimeout entre 60 e 90 segundos. Esses valores servem apenas como referência.