APRENDER. PRATICAR. EVOLUIR.Escolher a unidade de migração
Um projeto fictício de fundos tem três elementos: tabelas relacionais, ficheiros de reconciliação e servidores de uma aplicação legada. Escolhe a ferramenta pelo elemento e pelos requisitos. DMS permite migrar dados entre motores suportados; a conversão de esquema exige o seu próprio trabalho e validação. DataSync trata ficheiros e objetos. AWS Transform MGN, anteriormente Application Migration Service, trata rehosting de servidores. Antes da janela, regista versões, volumes, dependências, responsáveis e critérios de aceitação. Uma avaliação prévia DMS pode encontrar tipos incompatíveis. Resolve a ocorrência e ensaia a transformação; um relatório prévio aprovado não demonstra que o resultado final contém todas as operações de negócio.
Ler o atraso antes de prometer a janela
Full load concluído significa que a carga inicial terminou, não que as alterações seguintes já chegaram ao destino. CDC precisa de logs acessíveis na origem; aumentar a rede não recupera binlogs já eliminados sem outra cópia utilizável. Se a captura acompanha a origem mas a aplicação atrasa, investiga o destino e as operações de escrita, incluindo índices necessários. No modelo didático, chegam 100 MB/s, aplicam-se 140 MB/s e existem 2400 MB em espera: o saldo de 40 MB/s dá 60 segundos. É uma estimativa constante, sem transações longas nem validação. Mede condições reais antes de a transformar num compromisso de indisponibilidade.
Provar os dados que o negócio vai usar
Define a aceitação antes de abrir o destino a escritas. Num lote fictício, a equipa exige todos os movimentos selecionados, nenhuma divergência por resolver e reconciliação dos totais por data. O estado de validação DMS distingue registos pendentes, suspensos e divergentes; zero falhas não equivale a zero trabalho pendente. A validação também consome recursos, pelo que entra no ensaio de capacidade e no tempo reservado. Para ficheiros, confirma o âmbito da verificação DataSync: apenas os transferidos não prova o conjunto completo. Uma opção de preservação do destino pode manter um ficheiro antigo. Compara o inventário exigido com os itens efetivamente legíveis e migrados.
Ensaiar ficheiros e servidores como serviços
Uma cópia de ficheiros com bytes corretos ainda pode falhar para a conta do batch. Em NFS com metadados POSIX preservados, confirma UID, GID e permissões efetivas no destino; nomes iguais não bastam quando os números diferem. Num ensaio MGN, alterações novas seguem para staging e não atualizam a instância de teste já lançada. Testa autenticação, certificados, ligações e processamento, além do arranque. Se o AD fica na origem, isola o teste para evitar que o clone interfira com a identidade de produção. Documenta as dependências não ensaiadas e quem decide sobre o risco residual antes de aceitar o serviço.
Decidir a passagem com evidência
Constrói uma sequência com donos e pontos de decisão: suspender entradas e escritas autorizadas, obter a proteção prevista, concluir sincronização, reconciliar, mudar encaminhamento e validar o serviço. O detalhe depende do motor e do desenho; não existe um comando universal de cutover. Numa migração parcial, mede a latência entre componentes que ficam separados. Se o batch exceder a janela apenas por esse percurso, aumentar servidores pode não resolver. Finalize cutover do MGN termina a replicação e remove os recursos de replicação, pelo que pressupõe aceitação concluída. Para recuperação continuada com failback, avalia AWS DRS e os requisitos próprios dessa solução.
Preparar o regresso depois de novas escritas
Depois da entrada em produção, o destino pode conter movimentos que a origem nunca recebeu. Mudar DNS não transporta esses movimentos. Na oficina, a origem conhece os identificadores 1 a 100 e o destino confirmou até 103; um regresso sem reconciliação perde a visão de três operações. Define como preservar as novas confirmações, impedir escritores concorrentes e verificar a reposição ou correção em frente. O modelo local mostra essa diferença e o saldo de replicação, sem representar um protocolo transacional distribuído. Entrega a APS evidência de aceitação, alarmes, responsáveis e um plano de recuperação ensaiado. Rever contagens é uma parte da aceitação, não uma prova completa de integridade.
// Synthetic constant-rate teaching model; no AWS calls or production data.
function drain(backlog,arrivals,apply){
if(![backlog,arrivals,apply].every(x=>Number.isFinite(x)&&x>=0))throw Error('Non-negative finite rates required');
if(backlog===0)return 0;
return apply>arrivals?backlog/(apply-arrivals):null;
}
const source=new Set(Array.from({length:100},(_,i)=>i+1));
const acknowledged=Array.from({length:103},(_,i)=>i+1);
console.log(JSON.stringify({drainSeconds:drain(2400,100,140),noConvergence:drain(2400,100,90),frozenSeconds:Math.round(drain(2400,0,140)*100)/100,missingOnReturn:acknowledged.filter(id=>!source.has(id))}));Oficina de vinte minutos: calcula o tempo de drenagem de 2400 MB com chegadas de 100 MB/s e aplicação de 140 MB/s. Repete com aplicação de 90 MB/s e depois com escritas suspensas. Esperado: 60 segundos, ausência de convergência e cerca de 17,14 segundos. Explica os limites do modelo e identifica as operações 101, 102 e 103 que faltariam à origem num rollback fictício.
Armadilhas comuns
Confundir full load com CDC atualizado, ignorar ficheiros omitidos, testar apenas o arranque ou prometer rollback por DNS depois de novas escritas. Uma cópia e uma contagem iguais não provam comportamento de negócio.
Tópicos relacionados: Resiliência, capacidade e recuperação · Bases de dados, réplicas e cache · Recuperação: dependências, capacidade e custo
Escolhe a ferramenta pelo elemento, confirma a sincronização e valida dados e serviço antes de mudar. Os exercícios são fictícios; o modelo local não mede AWS, não garante RPO/RTO e não substitui ensaio autorizado.
Referência: SAA-C03 resilient architectures · SAA-C03