ApsaraDB RDS:Migrate to another zone

Tipo de migração

Cenário

Migrar de uma zona para outra

A zona atual atingiu a capacidade máxima ou apresenta problemas de desempenho.

Migrar de uma zona para várias zonas

Após a migração, as instâncias primária e secundária ficam em zonas diferentes, permitindo recuperação de desastres entre data centers.

Em comparação com instâncias de zona única, instâncias multizona toleram falhas de nível mais alto. Por exemplo, instâncias de zona única suportam falhas em nível de servidor e rack, enquanto instâncias multizona suportam falhas em nível de data center.

Migrar de várias zonas para uma zona

Para atender a requisitos específicos de recursos.

Categoria

Descrição

Antes da migração

• Perda do ambiente do host: a migração entre zonas envolve migração entre hosts. Esse processo limpa sua conta do host e quaisquer programas ou arquivos implantados no host original (como SSIS, SSAS, SSRS). Faça backup ou migre esses dados com antecedência.

  Importante

  O ApsaraDB RDS for SQL Server foi desenvolvido sobre o mecanismo nativo do Microsoft SQL Server e foca em fornecer serviços de banco de dados gerenciados de forma estável e eficiente. Se o seu negócio exigir recursos como SSIS, SSAS ou SSRS, é necessária uma sólida expertise em operações para garantir a continuidade do negócio.

• Evite alterações de metadados: não adicione nem exclua bancos de dados e não altere o modelo de recuperação durante a migração entre zonas. Essas ações podem causar inconsistência de dados.

• A migração não pode ser cancelada: depois de iniciada, a migração não pode ser cancelada. Prossiga com cautela.

• Escolha horários de baixa demanda: a migração normalmente leva cerca de 20 minutos, dependendo do volume de dados. Atividade intensa durante a migração pode estender esse tempo. Execute a migração fora do horário de pico do negócio.

• Garanta a reconexão automática: a instância ficará indisponível por alguns minutos durante o switchover, afetando brevemente a disponibilidade. Garanta que sua aplicação tenha um mecanismo de reconexão.

• Verifique o endereço de conexão: o virtual IP address (VIP) muda após a migração. Garanta que sua aplicação use o endpoint em vez de um endereço IP direto para acessar a instância.

  Para clientes baseados em JVM, defina o TTL para 60 segundos ou menos. Assim, sua aplicação recebe o novo VIP ao reconsultar o DNS quando o VIP do endpoint mudar.

  Definir o TTL na JVM

  • Para todas as aplicações JVM: defina o parâmetro networkaddress.cache.ttl como 60 no arquivo $JAVA_HOME/jre/lib/security/java.security.

  • Para uma aplicação local específica: antes de fazer qualquer conexão de rede — especificamente, antes da primeira chamada a InetAddress.getByName() — adicione esta linha ao código de inicialização da sua aplicação: java.security.Security.setProperty("networkaddress.cache.ttl" , "60");.

• Planeje o tratamento de tarefas DTS: se você tiver tarefas DTS ativas, planeje-se com antecedência. Você deve reiniciar manualmente essas tarefas após a migração.

• O negócio permanece acessível: os dados são movidos durante a migração, mas sua instância RDS SQL Server permanece acessível. As operações do negócio não são afetadas.

• Limitação de backup regular: se você optar por fazer o switchover durante a janela de manutenção, os backups regulares ficam desativados desde o envio da tarefa até a conclusão da migração.

Após a migração

• Verifique a consistência da configuração: o nome da instância, a porta, as tags, as contas de banco de dados e outras configurações permanecem inalteradas. Confirme que essas configurações funcionam corretamente.

• Limpe o cache DNS: limpe imediatamente o cache DNS do seu cliente para evitar falhas de conexão causadas por entradas desatualizadas.

• Valide a conectividade: use o endpoint para verificar se a instância está acessível e confirme se as funções do negócio operam normalmente.

• Reinicie as tarefas DTS: se você tinha tarefas DTS ativas antes da migração, reinicie-as manualmente para garantir o funcionamento adequado.