Todos os produtos
Search
Central de documentação

Tair (Redis® OSS-Compatible):Alterar arquitetura da instância

Última atualização: Aug 28, 2026

O Tair (compatível com Redis OSS) permite alternar uma instância entre as arquiteturas padrão (master-replica) e cluster.

Limitações

Nem todos os tipos de instância permitem alterações de arquitetura. Consulte a tabela abaixo antes de prosseguir.

Tipo de instância

Padrão para cluster

Cluster para padrão

Instância padrão com divisão de leitura e gravação ativada

Desative primeiro a divisão de leitura e gravação

Desative primeiro a divisão de leitura e gravação

Instância filha de uma instância distribuída

Não compatível

Não compatível

Instância baseada em SSD do Tair (Enterprise Edition)

Não compatível

Não compatível

Instância cluster no modo de conexão direta

Não compatível

Faturamento

As cobranças dependem do método de faturamento:

  • Pagamento conforme o uso: A cobrança ocorre imediatamente após a alteração, com base na nova tarifa de especificação.

  • Assinatura: Há cobrança ou reembolso da diferença de preço, dependendo se houve upgrade ou downgrade.

Para mais detalhes, consulte Configuration changes.

Alterar de padrão (master-replica) para cluster

Antes de começar

Analise estes impactos antes de iniciar a alteração.

  • Endpoints, contas, senhas e listas de permissões permanecem inalterados. Nenhuma mudança no código da aplicação é necessária.

  • Os dados geralmente são preservados. No raro evento de falha do nó primário durante o switchover, pode haver perda de uma pequena quantidade de dados não sincronizados.

  • Ocorrem de 1 a 2 desconexões transitórias, cada uma com duração inferior a 30 segundos. Certifique-se de que sua aplicação possua um mecanismo de reconexão.

  • Estado somente leitura por aproximadamente 1 minuto. A instância entra em modo somente leitura enquanto a nova instância sincroniza dados incrementais e o cache DNS é limpo. Instâncias com alta carga de escrita podem apresentar um período somente leitura mais longo.

  • Scripts Lua podem ser perdidos. Faça backup dos seus scripts Lua antes de prosseguir. Para mais detalhes, consulte Special limits on cluster instances.

  • Em clusters no modo proxy, o primeiro argumento de redis.call ou redis.pcall em scripts Lua deve ser uma string literal (por exemplo, 'GET'), e não uma variável. Um argumento variável aciona o erro ERR bad lua script for redis cluster, first parameter of redis.call/redis.pcall must be a single literal string. Essa restrição afeta frameworks de terceiros, como o Redisson, que constroem nomes de comandos dinamicamente. Para desativar essa verificação, defina o parâmetro script_check_enable como 0. Para mais informações, consulte Special limits on cluster instances.

  • Limitações adicionais de comandos se aplicam. Alguns comandos não são compatíveis com a arquitetura cluster. Avalie o impacto na sua carga de trabalho antes de alterar. Para mais detalhes, consulte Command limitations for cluster instances.

  • A instância é atualizada para a versão secundária mais recente. Versões secundárias possuem compatibilidade futura; portanto, não se esperam problemas de compatibilidade.

Alterar a arquitetura

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

  2. No canto superior direito, clique em Specification Adjustment e então:

    • Para uma instância de assinatura: selecione Specification Upgrade.

    • Para uma instância de pagamento conforme o uso: selecione Specification Upgrade/Downgrade.

  3. Na página de alteração de especificação, selecione a configuração desejada e clique em Buy Now. Para o parâmetro Switching Time, escolha uma das seguintes opções:

    Opção

    Comportamento

    Switch Within Maintenance Window (recomendado)

    O switchover ocorre durante a maintenance window (horário fora de pico). Antes do switchover, acesse o Task Hub e clique em Modify Switchover Time para ajustar o horário, se necessário.

    Switch after Data Migration

    O switchover ocorre imediatamente após a conclusão da migração de dados.

  4. Conclua o pagamento conforme solicitado.

Após enviar a solicitação, o status da instância muda para Changing Configuration, independentemente do horário de troca selecionado. Esse status não afeta seus serviços em execução — o sistema prepara recursos e sincroniza dados em segundo plano. Desconexões transitórias ocorrem apenas no momento do switchover.

Após a alteração

  • O modo de conexão assume o padrão proxy. Monitore as conexões do cliente na página de monitoramento do nó proxy. A contagem de conexões nos nós de dados é exibida como 0.

  • As configurações de alerta são desativadas. Grupos de aplicações existentes no CloudMonitor também podem ser desativados. Reconfigure-os para retomar o monitoramento.

  • O flashback de dados é desativado. Reconfigure o recurso para retomar a recuperação point-in-time.

  • Se sua aplicação depender de notificações de keyspace (notify-keyspace-events), reconfigure o parâmetro na página Parameter Settings após a conclusão da alteração.

Alterar de cluster para padrão (master-replica)

Antes de começar

Analise estes impactos antes de iniciar a alteração.

  • Endpoints, contas, senhas e listas de permissões permanecem inalterados. Nenhuma mudança no código da aplicação é necessária.

  • Os dados geralmente são preservados. No raro evento de falha do nó primário durante o switchover, pode haver perda de uma pequena quantidade de dados não sincronizados.

  • Ocorrem de 1 a 2 desconexões transitórias, cada uma com duração inferior a 30 segundos. Certifique-se de que sua aplicação possua um mecanismo de reconexão.

  • Estado somente leitura por aproximadamente 1 minuto. A instância entra em modo somente leitura enquanto a nova instância sincroniza dados incrementais e o cache DNS é limpo. Instâncias com alta carga de escrita podem apresentar um período somente leitura mais longo.

  • A instância é atualizada para a versão secundária mais recente. Versões secundárias possuem compatibilidade futura; portanto, não se esperam problemas de compatibilidade.

Alterar a arquitetura

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

  2. Para uma instância de assinatura, no canto superior direito, clique em Specification Adjustment e selecione Specification Downgrade.

    Importante

    Instâncias de pagamento conforme o uso não podem fazer downgrade da arquitetura cluster para a arquitetura padrão (master-replica) diretamente pelo console. Utilize um dos métodos a seguir:

    • Chame a API ModifyInstanceSpec para realizar o downgrade da instância. Certifique-se de especificar o InstanceClass correto para a família de especificações desejada.

    • Primeiro Convert to Subscription e, em seguida, siga as etapas acima.

  3. Na página de alteração de especificação, selecione a configuração desejada e clique em Buy Now. Para o parâmetro Switching Time, escolha uma das seguintes opções:

    Opção

    Comportamento

    Switch During Maintenance Window (recomendado)

    O switchover ocorre durante a maintenance window (horário fora de pico). Antes do switchover, acesse o Task Hub e clique em Modify Switchover Time para ajustar o horário, se necessário.

    Switch after Data Migration

    O switchover ocorre imediatamente após a conclusão da migração de dados.

  4. Conclua o pagamento conforme solicitado.

Após enviar a solicitação, o status da instância muda para Changing Configuration, independentemente do horário de troca selecionado. Esse status não afeta seus serviços em execução — o sistema prepara recursos e sincroniza dados em segundo plano. Desconexões transitórias ocorrem apenas no momento do switchover.

Após a alteração

  • As configurações de alerta são desativadas. Grupos de aplicações existentes no CloudMonitor também podem ser desativados. Reconfigure-os para retomar o monitoramento.

  • O flashback de dados é desativado. Reconfigure o recurso para retomar a recuperação point-in-time.

Perguntas frequentes

Quanto tempo leva uma alteração de arquitetura?

A duração depende das condições da rede, volume de solicitações e tamanho dos dados; portanto, não é possível prever com antecedência.

Acompanhe o progresso clicando em no ícone image.png no canto superior direito da página de detalhes da instância.

Preciso pausar operações de leitura e gravação durante uma alteração de especificação?

Não. No entanto, como a instância pode entrar em estado somente leitura por cerca de 1 minuto e sofrer de 1 a 2 desconexões transitórias de menos de 30 segundos cada, recomendamos realizar o switchover durante horários fora de pico.

Os dados são migrados automaticamente para cada shard ao alterar para cluster?

Sim. O sistema migra os dados automaticamente e os distribui uniformemente por todos os shards.

O número de bancos de dados muda após uma alteração de arquitetura?

Não. O número padrão de 256 bancos de dados permanece inalterado.

Os conjuntos de backup são perdidos após uma alteração de especificação?

Não. Os conjuntos de backup são preservados. No entanto, quando você reduz o número de shards de uma instância cluster clássica ou altera sua arquitetura para padrão, o mapeamento entre conjuntos de backup históricos e nós da instância muda.

Para localizar conjuntos de backup históricos nesse caso, pesquise por horário de backup ou ID do conjunto de backup. Para restaurar dados, baixe o conjunto de backup (arquivo RDB), analise-o e importe os dados para a nova instância.

Por que as configurações não são atualizadas após a alteração?

Isso geralmente ocorre devido a um atraso na atualização do cache de metadados. Aguarde alguns minutos e atualize a página.

O que significa o erro "The direct custins can not trans to normal custins"?

Esse erro ocorre ao tentar alterar a arquitetura de uma instância cluster clássica com um endpoint de conexão direta para a arquitetura padrão ou de divisão de leitura e gravação. Essa operação não é compatível. Para alterar a arquitetura, primeiro release the direct connection endpoint e tente novamente.

Posso alterar uma instância de alta disponibilidade (réplica dupla) para uma instância de réplica única?

Não. Instâncias de réplica única não garantem confiabilidade dos dados; portanto, essa conversão não é compatível.

Se precisar de uma instância de réplica única, adquira uma instância de alta disponibilidade separada e use o DTS para migrar seus dados para uma instância de réplica única. Para mais detalhes, consulte Migration between Tair (Redis OSS-compatible) instances.

Posso alterar o meio de armazenamento de uma instância Tair (Enterprise Edition)?

Não. A alteração do meio de armazenamento entre tipos (otimizado para memória, memória persistente e ESSD) não é compatível.

Posso atualizar apenas o desempenho da CPU de uma instância?

Upgrades exclusivos de CPU não são compatíveis. Para melhorar o desempenho geral da CPU, utilize uma das seguintes abordagens:

  • Altere a arquitetura de padrão para cluster ou divisão de leitura e gravação.

  • Adicione nós somente leitura a uma instância de divisão de leitura e gravação.

  • Adicione shards a uma instância cluster.

Para mais detalhes, consulte How to upgrade the CPU specifications of an instance e Instance types and FAQ.

Uma instância clássica pode ser atualizada diretamente para uma instância cloud-native?

Sim. Para mais detalhes, consulte Convert to the cloud-native deployment mode.