Alterações de especificação — incluindo mudanças na edição do RDS, no tipo de instância e na capacidade de armazenamento — podem levar de alguns segundos a um período prolongado, dependendo do tipo de armazenamento e da carga de trabalho da instância. O fator determinante é a ocorrência ou não de migração de dados entre instâncias.
Para minimizar o tempo necessário, agende as alterações de especificação durante períodos de baixa escrita ou interrompa a gravação de dados na instância antes de iniciar o processo.
Como o tipo de armazenamento determina o caminho de migração
O tipo de armazenamento da instância define se a alteração de especificação exige migração de dados para uma nova instância:
|
Tipo de armazenamento |
Migração de dados entre instâncias |
Tempo necessário |
|
SSD local |
Pode ser necessária |
Longo (se houver migração) ou curto (caso contrário) |
|
SSD padrão ou aprimorado |
Não necessária |
Curto |
Em instâncias com SSDs padrão ou aprimorados, não ocorre migração de dados. A alteração de especificação é concluída rapidamente, e os fatores descritos na próxima seção não se aplicam.
Nas instâncias com SSDs locais, a mudança de especificação pode acionar uma migração da instância original para uma nova. Nesse caso, o ApsaraDB RDS faz backup dos dados na instância original e os restaura na nova instância — um processo que pode demandar tempo considerável.
Fatores que afetam o tempo de migração (apenas SSDs locais)
Quando ocorre migração de dados entre instâncias, os seguintes fatores determinam a duração do processo.
Tamanho total dos dados
O volume total de dados influencia diretamente a duração do backup inicial e da restauração. A largura de banda da rede e a velocidade de backup também contribuem: conjuntos de dados maiores sob largura de banda limitada levam proporcionalmente mais tempo.
Tamanho dos redo logs
Redo logs grandes fazem com que o volume real de dados a serem copiados exceda a estimativa inicial, aumentando o tempo necessário para restaurar os dados na nova instância.
Locks
O ApsaraDB RDS bloqueia objetos relacionados durante a fase de backup. Atividade intensa de locks torna o backup mais lento e estende o tempo total de migração.
Quantidade de tabelas
O número de tabelas na instância também impacta a duração da migração.
Volume de dados incrementais
Após a conclusão da migração completa dos dados, o ApsaraDB RDS migra os dados incrementais gerados durante a janela de migração. Quanto maior esse volume incremental, mais tempo leva a alteração de especificação como um todo.
Velocidade de escrita dos dados incrementais
A taxa de reaplicação dos dados incrementais determina a rapidez com que a nova instância alcança a sincronização. Essa taxa depende dos seguintes aspectos:
Velocidade de reaplicação das instruções SQL registradas em log
Execução de instruções SQL em tabelas individuais
Execução de instruções de linguagem de definição de dados (DDL) na instância original durante a migração
Latência de sincronização de dados
Antes de direcionar o tráfego para a nova instância, o ApsaraDB RDS precisa estabelecer um vínculo de sincronização e aguardar a conclusão desse processo. Latência elevada atrasa o switchover. Os principais fatores que influenciam a latência são:
Carga de escrita na instância original
Instruções DDL executadas na instância original durante a sincronização
Consultas conjuntas executadas em várias tabelas