ApsaraDB RDS:Migrate to another zone

Tipo de migração

Cenário

Migrar de uma zona para outra zona

A zona atual está com a capacidade total ou apresentando problemas de desempenho.

Migrar de uma zona para várias zonas

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

Em comparação com as instâncias de zona única, as instâncias de várias zonas toleram falhas de nível mais alto. Por exemplo, as instâncias de zona única resistem a falhas no nível do servidor e do rack, enquanto as instâncias de várias zonas resistem a falhas no nível do data center.

Migrar de várias zonas para uma zona

Para atender a requisitos de recursos específicos.

Categoria

Descrição

Antes da migração

• Perda do ambiente do host: a migração de zona envolve a migração entre hosts. Isso limpa seu host account e quaisquer programas ou arquivos implantados no host original (como SSIS, SSAS, SSRS). Faça backup ou migre esses dados previamente.

  Importante

  O ApsaraDB RDS for SQL Server é construído no mecanismo nativo do Microsoft SQL Server e foca em fornecer services de banco de dados gerenciado estáveis e eficientes. Se o seu negócio exigir recursos como SSIS, SSAS ou SSRS, você precisará de uma forte expertise em operações para garantir a continuidade dos negócios.

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

• A migração não pode ser cancelada: após o início, a migração não pode ser cancelada. Prossiga com cautela.

• escolha horários de menor movimento: a migração geralmente leva cerca de 20 minutos, dependendo do volume de dados. A atividade intensa durante a migração pode estender esse tempo. Realize a migração durante os horários de menor movimento do negócio.

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

• verifique o endereço de conexão: o endereço IP virtual (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. Isso garante que sua aplicação receba o novo VIP ao consultar o DNS novamente quando o VIP do endpoint mudar.

  Definir 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 para 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 do DTS: se você tiver tarefas ativas do DTS, planeje 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 do 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 a alternância durante a janela de manutenção, os backups regulares serão 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 do banco de dados e outras configurações permanecem inalterados. Confirme se essas configurações funcionam corretamente.

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

• 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 do DTS: se você tinha tarefas ativas do DTS antes da migração, reinicie-as manualmente para garantir a operação adequada.