Todos os produtos
Search
Central de documentação

Tair (Redis® OSS-Compatible):Alterar a zona de uma instância

Última atualização: Jun 26, 2026

Transfira uma instância Tair (Redis OSS-Compatible) para outra zona na mesma região pelo console ou pela API MigrateToOtherZone. Essa operação é comum para reduzir a latência de rede ao colocar a instância na mesma zona das instâncias ECS, habilitar recuperação de desastres entre zonas ou acessar recursos de zona necessários para atualizar o tipo da instância.

Após a migração, os dados da instância, as contas de banco de dados, os endpoints e as configurações de lista de permissões permanecem inalterados.

Pré-requisitos

Antes de começar, verifique se você:

Tipos de migração compatíveis

Tipo de migração

Caso de uso

Zona única para zona única

Posicione a instância na mesma zona da sua instância ECS para obter menor latência na rede interna

Multizona para multizona

Ajuste a distribuição de zonas mantendo a recuperação de desastres entre zonas

Zona única para multizona

Habilite a recuperação de desastres entre zonas. Uma instância de zona única resiste a falhas no nível do servidor e do rack. Já uma instância multizona é implantada em vários data centers e suporta interrupções completas de um data center

Multizona para zona única

Consolide em uma única zona quando recursos específicos exigirem essa configuração

Impactos

Desconexão transitória

Instâncias cloud-native

A ocorrência de desconexão transitória depende da zona alterada:

Cenário

Desconexão transitória

Adição de uma zona secundária a uma instância de zona única (a zona primária permanece a mesma)

Não

Alteração apenas da zona secundária, desde que ela não contenha um nó primário

Não

Alteração da zona que hospeda o nó primário, inclusive quando um failover de alta disponibilidade (HA) transferiu o nó primário para a zona secundária

Sim

Alteração da zona secundária de uma instância com divisão de leitura/escrita enquanto conectada pelo endpoint da zona secundária

Sim

Instâncias clássicas

A migração de zona pode causar desconexão transitória em instâncias clássicas.

Estado somente leitura

A instância pode entrar em estado somente leitura por até 60 segundos para sincronizar dados incrementais e evitar gravações duplicadas causadas pelo cache DNS. Em cenários com alta taxa de escrita, esse período somente leitura pode ser mais longo.

Nota

O estado somente leitura não ocorre se o nó primário não for migrado. Isso se aplica apenas a instâncias cloud-native.

Alterações no mapeamento DNS

A migração de zona altera o endereço IP virtual (VIP) subjacente e o mapeamento DNS. Sempre se conecte à instância usando seu endpoint, como r-bp10b3fa3500****.redis.rds.aliyuncs.com, e nunca diretamente pelo VIP.

Versões antigas do Jedis podem falhar ao resolver o endpoint corretamente após a migração. Se você utiliza o Jedis, garanta que a versão seja 3.10.0 ou superior. Para mais detalhes, consulte Recomendações de atualização do cliente Jedis.

Atualização automática de versão secundária

Se a instância estiver executando uma versão secundária desatualizada, o sistema a atualiza automaticamente para a versão secundária mais recente durante a migração. Como as versões secundárias mantêm compatibilidade futura, não ocorrem problemas de compatibilidade.

Redefinição de largura de banda

Após a migração, a largura de banda retorna ao valor padrão. Caso você tenha ajustado manualmente a largura de banda anteriormente, reconfigure-a depois da migração. O Auto Scaling restaura as configurações personalizadas de largura de banda quando a próxima regra de dimensionamento for acionada.

Nota

Se o nó primário não for migrado, o plano de largura de banda permanece inalterado. Isso se aplica apenas a instâncias cloud-native.

Recomendações

  • Implemente um mecanismo de reconexão na sua aplicação.

  • Execute a migração fora dos horários de pico para minimizar o impacto aos usuários.

  • Agende a migração durante a janela de manutenção para garantir um failover controlado.

Migrar uma instância para outra zona

Aviso

Esta operação pode causar desconexões transitórias. Recomendamos executá-la fora dos horários de pico e garantir que sua aplicação consiga se reconectar automaticamente à instância.

  1. Faça login no console e acesse a página Instances. Na barra de navegação superior, selecione a região da instância. Localize a instância desejada e clique em seu ID.

  2. Na seção Basic Information, clique em Migrate ao lado de Zone.

  3. Configure os seguintes parâmetros no painel exibido.

    Parâmetro

    Descrição

    Primary zone change

    Selecione a zona de destino.

    Secondary zone change (opcional)

    Escolha uma zona secundária para habilitar a recuperação de desastres entre zonas. O nó secundário será migrado para a zona especificada. Se nenhuma zona secundária for definida, os nós primário e secundário serão migrados para a zona primária.

    Virtual Switch:

    Selecione o vSwitch de destino. Caso não exista nenhum vSwitch na zona de destino, crie um antes de prosseguir. Este parâmetro aparece apenas para instâncias VPC.

    Executed At

    Update Now: A migração inicia imediatamente após você clicar em OK. O processo é concluído quando o status da instância muda para Running. Update During Maintenance (recomendado): O sistema executa tarefas preliminares e altera o status da instância para Migrating to Another Zone. A instância continua disponível durante essa fase. O failover efetivo ocorre dentro da janela de manutenção configurada.

    Primary zone nodes per shard / Secondary zone nodes per shard

    Para instâncias cloud-native do tipo cluster ou com divisão de leitura/escrita, ajuste a distribuição dos nós de réplica entre as zonas primária e secundária. Essa configuração não altera o número total de nós. Em instâncias com arquitetura de cluster, esses valores representam a quantidade de nós de réplica por shard em cada zona.

  4. Leia a mensagem de aviso, marque a caixa de seleção e clique em OK.

Verificar a migração

Acompanhe o progresso da migração no Task Center do console. A migração estará concluída quando o status da instância retornar para Running.

Referência da API

API

Descrição

MigrateToOtherZone

Migra uma instância para outra zona dentro da mesma região.

Perguntas frequentes

O endpoint muda após uma migração de zona?

Não. O endpoint da instância, como r-bp10b3fa3500****.redis.rds.aliyuncs.com, permanece o mesmo. No entanto, o VIP e o mapeamento DNS são alterados. Sempre se conecte usando o endpoint, e não o VIP.

Se você utiliza o Jedis, garanta que a versão seja 3.10.0 ou superior. Versões antigas podem falhar ao resolver o endpoint corretamente após a migração. Para mais detalhes, consulte Recomendações de atualização do cliente Jedis.

Há perda de dados durante uma migração de zona?

Não. A migração de zona não causa perda de dados e não exige a reconfiguração de listas de permissões ou contas de banco de dados.

Existe cobrança para migrar de zona única para multizona?

Não. A migração de zona única para multizona não gera custos adicionais.

Por que não consigo migrar minha instância para uma zona secundária?

Uma instância standalone não possui nó secundário, portanto não suporta migração para zona secundária.

Se minha instância estiver implantada em duas zonas e uma delas falhar, a instância continuará disponível?

Sim. Uma instância implantada em duas ou mais zonas oferece suporte à recuperação de desastres entre zonas. Se uma zona falhar, o outro nó continua processando as requisições.