Todos os produtos
Search
Central de documentação

Tair (Redis® OSS-Compatible):Visão geral da alta disponibilidade

Última atualização: Jul 03, 2026

Quando o Tair (Redis OSS-compatible) detecta a indisponibilidade do nó mestre de uma instância, aciona automaticamente um failover mestre-réplica. Um nó réplica é promovido a mestre para garantir a alta disponibilidade da instância. Caso receba uma notificação sobre a ocorrência de um failover mestre-réplica, consulte este tópico para entender as causas, os impactos e as ações recomendadas.

Causas

  • Falhas nos hosts da instância

    Se a Alibaba Cloud detectar falha no host subjacente de uma instância, como término anormal de processos ou anomalias de memória devido à alta carga, o sistema aciona imediatamente um failover mestre-réplica. Essa ação rápida garante a restauração oportuna da instância e minimiza a duração de qualquer interrupção causada pela falha.

    Você recebe notificações sobre esses eventos por meio de mensagens internas ou e-mails no seguinte formato:

    [Alibaba Cloud] Prezado****: Foi detectada uma anomalia em sua instância Tair r-bp1zxszhcgatnx** (nome: **). Um failover foi acionado para garantir a operação estável da instância. Recomendamos verificar se sua aplicação ainda está conectada à instância e configure a reconexão automática da aplicação à instância.

  • Riscos ocultos nos hosts da instância

    Caso a Alibaba Cloud identifique riscos no host subjacente de uma instância, como oscilações de rede ou anomalias de disco, isso indica potencial impacto futuro na operação normal da instância. Nessas situações, o sistema inicia automaticamente tarefas proativas de O&M para tratar os riscos e aciona um failover mestre-réplica durante a janela de manutenção para substituir os nós do host em risco.

    No entanto, para eventos que exigem correção urgente de riscos, o sistema age rapidamente para resolver os problemas e iniciar um failover mestre-réplica. Por exemplo, se um bug crítico for identificado na comunidade Redis, a instância relevante passa proativamente por uma atualização de versão secundária. É possível consultar os registros dessas ações no histórico de eventos. Para mais informações, consulte Consultar eventos históricos. Você também pode gerencie eventos pendentes de failover mestre-réplica. Para mais informações, consulte Visualize e gerencie eventos agendados.

Impactos

A instância conclui automaticamente todo o processo de failover. Após a conclusão, a instância opera conforme o esperado.

Contudo, durante o processo de failover, podem ocorrer as seguintes situações:

  • Os nós de dados onde o failover é executado ficam desconectados por alguns segundos e podem permanecer somente leitura por até 30 segundos.

  • Depois que a instância entra no estado Switching, não é possível gerenciá-la. Por exemplo, você não pode modifique as configurações da instância nem migrá-la para outra zona. Quando o failover mestre-réplica é concluído, o estado da instância muda para Running.

Ações recomendadas

  • Certifique-se de que sua aplicação esteja configurada para se reconectar automaticamente à instância ou tratar exceções. Caso contrário, uma das seguintes mensagens de erro poderá ser retornada durante um failover: READONLY You can't write against a read only instance ou DISABLE You can't write or read against a disable instance.

  • Quando um failover mestre-réplica é acionado para uma instância, ela conclui automaticamente todo o processo promovendo o nó réplica a novo nó mestre e criando outro nó réplica para sincronização de dados entre os nós mestre e réplica. Nenhuma operação manual é necessária durante esse processo.

    Nota

    Após a conclusão do failover mestre-réplica em uma instância de zona dupla, o nó mestre reside na zona secundária e o nó réplica reside na zona primária. Isso pode causar acesso entre zonas entre a instância e outros serviços. Para resolver esse problema, alterne manualmente as zonas na página Service availability no console.

Tópicos relacionados

O Tair (Redis OSS-compatible) também suporta failovers mestre-réplica manuais. Esse recurso pode ser utilizado para simulações de recuperação de desastres ou para conexão ao nó mais próximo em implantações com múltiplas zonas de disponibilidade. Para mais informações, consulte Executar manualmente um failover mestre-réplica.

Perguntas frequentes

  • Qual é o princípio por trás do failover mestre-réplica acionado por falha na instância?

    O sistema de alta disponibilidade depende de seu mecanismo de detecção de atividade para identificar falhas. A tabela a seguir descreve esse mecanismo.

    Evento principal

    Descrição

    Verificação de integridade

    O sistema de alta disponibilidade verifica se os nós mestre e réplica estão íntegros.

    Falha no nó mestre

    1. Quando um nó mestre é considerado indisponível, um nó réplica assume a função de mestre. Simultaneamente, o endereço IP virtual (VIP) do nó réplica é utilizado, mas o endpoint da instância permanece inalterado.

    2. Outro nó réplica é criado para garantir a sincronização de dados.

    Falha no nó réplica

    Quando um nó réplica é considerado indisponível, outro nó réplica é criado automaticamente para assegurar a sincronização de dados e manter a persistência de dados da arquitetura mestre-réplica.

    Nota

    Dados específicos gravados recentemente em um nó mestre podem ser perdidos, pois a sincronização entre os nós mestre e réplica é implementada de forma assíncrona.

  • P: Como visualize meu histórico de failover mestre-réplica (HA)?

    R:

    1. Acesse a Central de Eventos no console e selecione uma região na parte superior da página.

    2. Clique em Abnormal Events.

    3. Selecione o intervalo de tempo desejado.

    4. Defina Archive Status como All para visualize os registros de instance failover e suas causas, como Master unavailable.

  • P: Se ocorrer um failover mestre-réplica em uma instância com divisão de leitura e gravação, as réplicas de leitura serão afetadas?

    R: Durante o failover, as réplicas de leitura disponíveis diminuem temporariamente em uma unidade e retornam ao normal após a conclusão.

  • P: Em uma instância com arquitetura de cluster, o failover de um shard de dados afeta toda a instância?

    R: Não. Apenas o shard de dados afetado sofre impacto.