Todos os produtos
Search
Central de documentação

ApsaraDB RDS:Migrar nós de proxy entre zonas

Última atualização: Jun 26, 2026

O ApsaraDB RDS for MySQL permite migrar nós de proxy para outra zona. Recomendamos manter os nós de proxy e a instância RDS primária na mesma zona.

Pré-requisitos

  • A instância RDS deve atender aos seguintes requisitos:

    • Engine: ApsaraDB RDS for MySQL

    • Edition: RDS High-availability Edition ou RDS Cluster Edition

    • Storage type: disco em nuvem

    • O recurso de proxy de banco de dados deve estar ativado.

    • Instance status: Running

      Nota

      A instância RDS primária, as instâncias RDS somente leitura e os nós de proxy devem estar em execução.

  • Não é possível migrar nós de proxy que utilizam endpoint de rede clássica. Para mais informações, consulte Visualizar e gerenciar endpoints e portas da instância.

Faturamento

A migração de nós de proxy entre zonas é gratuita.

Impactos

  • A migração de nós de proxy causa uma desconexão transitória de aproximadamente 30 segundos.

    • Em instâncias RDS High-availability Edition, a migração não afeta cargas de trabalho que usam o endpoint da instância RDS primária ou de uma instância RDS somente leitura.

    • Em instâncias RDS Cluster Edition, a migração não afeta cargas de trabalho que utilizam o endpoint de leitura/gravação, o endpoint de cluster somente leitura ou o endpoint de conexão direta de um nó.

    Nota

    Recomendamos alterar sua aplicação para usar um dos endpoints não afetados e realizar a migração fora do horário de pico.

  • Garanta que sua aplicação possua mecanismo de reconexão automática.

    Nota

    Caso sua aplicação não tenha mecanismo de reconexão automática, reconecte-a manualmente ao banco de dados.

  • A migração entre zonas altera o endereço IP virtual (VIP) do endpoint. Recomendamos sempre utilizar a string do endpoint na sua aplicação para estabelecer conexões, em vez de um endereço IP codificado.

  • Limpe o cache DNS no lado do cliente imediatamente após a migração. Se sua aplicação for executada em uma Java Virtual Machine (JVM), defina o time-to-live (TTL) na configuração da JVM para 60 segundos ou menos. Isso garante que a aplicação use o DNS para resolver o novo VIP após a alteração do endereço.

    Nota

    Para obter informações sobre como definir o TTL na configuração da JVM, consulte a documentação oficial do JDK: Class InetAddress.

  • A migração pode falhar se a zona de destino não tiver recursos suficientes.

  • A migração entre zonas pode invalidar o recurso de acesso mais próximo.

    Após a migração, o acesso mais próximo roteia o tráfego para a nova zona por padrão e o acesso mais próximo da zona original torna-se inválido. Se você modificar a zona de destino de um endpoint de proxy para uma zona diferente da padrão, o acesso mais próximo dessa zona correspondente também se tornará inválido. A tabela a seguir descreve cenários de exemplo.

    Cenário

    Informações originais do proxy

    Informações do proxy de destino

    Zona atual do proxy

    Endpoint do proxy

    Acesso mais próximo

    Zona do proxy de destino

    Zona padrão do endpoint

    Zona do endpoint de destino

    Acesso mais próximo

    Cenário 1:

    Zone A + Zone B para Zone A + Zone C

    Zone A

    Proxy endpoint a

    Zone A

    Zone A

    Zone A

    Zone A

    Zone A

    Zone C

    Inválido

    Zone B

    Proxy endpoint b

    Zone B

    Zone C

    Zone C

    Zone C

    Zone C

    Zone D

    Inválido

    Cenário 2:

    Zone A + Zone B para Zone C + Zone D

    Zone A

    Proxy endpoint a

    Zone A

    Zone C

    Zone C

    Zone C

    Zone C

    Zone E

    Inválido

    Zone B

    Proxy endpoint b

    Zone B

    Zone D

    Zone D

    Zone D

    Zone D

    Zone E

    Inválido

Importante

Se os nós de proxy e a instância RDS primária estiverem em zonas diferentes, o desempenho de gravação poderá diminuir ao conectar-se por meio do proxy de banco de dados. Recomendamos que os nós de proxy e a instância RDS primária usem a mesma VPC e o mesmo vSwitch.

Procedimento

  1. Acesse a página RDS instances, selecione a região da sua instância RDS na barra de navegação superior e clique em no ID da instância.

  2. No painel de navegação à esquerda, clique em Database Proxy. As informações básicas sobre seus nós de proxy serão exibidas.

  3. Clique em Cross-zone Migration.

    Nota

    Se o botão Cross-zone Migration não for exibido, verifique se sua instância atende aos pré-requisitos.

  4. Na caixa de diálogo Cross-zone Migration of Database Proxy, selecione uma zona de destino e um vSwitch para a migração, especifique um horário para a alteração e clique em OK.

    Importante

    Durante a migração entre zonas, não é possível alterar o proxy node type ou as instance specifications.

  5. Leia atentamente os impactos da migração e clique em OK.

Referência da API

API

Descrição

ModifyDBProxyInstance

Migra nós de proxy para uma zona de destino especificando o parâmetro VSwitchIds.

Perguntas frequentes

  • P: A migração de nós de proxy entre zonas afeta as conexões à minha instância RDS primária?

    R: Não. A migração afeta apenas as conexões da aplicação que utilizam endpoint de proxy de banco de dados. Essa migração não impacta conexões que usam o endpoint da instância RDS primária, de uma instância RDS somente leitura, o endpoint de leitura/gravação, o endpoint de cluster somente leitura ou o endpoint de conexão direta de um nó. Recomendamos alternar sua aplicação para um dos endpoints não afetados e executar a migração fora do horário de pico.

  • P: Quais são os impactos da migração de nós de proxy entre zonas?

    R: A migração de nós de proxy causa uma desconexão transitória de aproximadamente 30 segundos. A duração real da interrupção depende da sua carga de trabalho. Recomendamos alternar para um endpoint não afetado e realizar a migração fora do horário de pico. Para mais detalhes, consulte a seção Impactos neste tópico.