A migração de um bilhão de linhas de logs

O banco ainda respondia, mas cada mês custava mais

A tabela de logs crescia todos os dias e por muito tempo o aumento foi absorvido com mais espaço, manutenção e índices, até que relatórios começaram a percorrer períodos enormes, rotinas de limpeza demoravam cada vez mais e operações comuns do banco disputavam recursos com consultas históricas, então medimos o volume total, o crescimento diário, a distribuição por tipo de evento, usuário, componente e período, identificando também integrações que registravam informações em excesso, porque migrar um bilhão de linhas sem reduzir a causa apenas transportaria o mesmo problema para um lugar novo.

A projeção mostrou que ampliar a infraestrutura adiaria a dificuldade, mas não mudaria a relação entre uma base operacional, que precisa responder rapidamente às ações atuais, e um histórico usado para auditoria e análise, que aceita outra organização e outras formas de consulta, por isso levantamos todos os consumidores antes de mover qualquer registro, incluindo relatórios do Software Moodle™, ferramentas de BI, integrações, investigações de suporte, obrigações de retenção e consultas manuais que existiam apenas na rotina de uma pessoa.

Esse mapeamento revelou dependências inesperadas, como relatórios que presumiam encontrar toda a vida do aluno na tabela principal, processos que guardavam o último identificador lido e rotinas externas que buscavam novamente períodos já processados, então cada consumidor recebeu uma decisão, continuar consultando a janela recente no banco operacional, passar a usar a base histórica ou combinar as duas fontes por uma camada controlada, evitando que o corte terminasse com dezenas de consultas apontando silenciosamente para dados incompletos.

Laboratório com tamanho suficiente para dizer a verdade

Os primeiros ensaios com alguns milhões de linhas funcionaram rápido demais e produziram uma confiança enganosa, pois índices, cache, ordenações e espaço temporário se comportam de outra maneira quando a tabela e os lotes crescem, então montamos uma base proporcional ao volume real, preservando distribuição de datas, tipos de evento e tamanhos de campos, depois repetimos extração, importação, consulta e exclusão enquanto observávamos uso de disco, geração de logs internos, bloqueios, replicação e tempo de recuperação após uma interrupção.

Definimos uma janela recente que continuaria no banco operacional e uma estrutura histórica preparada para consultas por período, usuário, curso, componente e evento, sem copiar todos os índices da origem por hábito, porque cada índice aumenta o custo de importação e armazenamento, então começamos pelos caminhos realmente usados, medimos os planos de execução e deixamos espaço para ajustar depois que os relatórios estivessem trabalhando com o volume verdadeiro.

A migração foi dividida por intervalos de tempo e limites de identificadores, com lotes pequenos o suficiente para serem retomados e grandes o bastante para não desperdiçar a maior parte do tempo abrindo transações, cada lote recebia situação, primeira e última linha esperada, contagem, horário, checksum calculado sobre campos estáveis e resultado da importação, permitindo que uma falha de rede ou armazenamento voltasse ao ponto de controle em vez de reiniciar meses de eventos.

Mover o passado enquanto o presente continuava chegando

Começamos pelos períodos mais antigos e mantivemos o Software Moodle™ em funcionamento, pois os novos eventos eram gravados em uma faixa muito distante daquela que estava sendo transferida, mesmo assim limitamos ritmo e concorrência para que a leitura de grandes lotes não retirasse recursos das atividades dos alunos, ajustando o processo conforme latência do banco, tamanho da fila e horários de maior uso, uma migração quente que demorava mais no calendário, porém reduzia bastante o trabalho necessário durante a parada definitiva.

Depois de cada importação comparávamos contagens por período e tipo, limites de identificadores, checksums e amostras escolhidas de diferentes componentes, mantendo os registros na origem até a validação e separando o ato de copiar do ato de remover, porque apagar imediatamente tornaria a recuperação mais difícil e misturaria duas operações de risco, então somente lotes confirmados entravam na fila de retenção e ainda respeitavam o prazo definido para retorno.

O ponto de controle guardava o último evento incluído na migração quente e permitia buscar, perto do corte, apenas aquilo que havia sido criado depois, enquanto relatórios eram adaptados e testados contra as duas fontes, primeiro comparando resultados no mesmo período e depois medindo consultas longas, paginação e filtros, pois o sucesso não seria apenas ter um bilhão de linhas em outro banco, mas permitir que auditoria e análise continuassem encontrando a informação com tempo previsível.

O corte e o trabalho que veio depois

Na janela de manutenção interrompemos os produtores conhecidos, registramos o último identificador, transferimos os eventos posteriores ao ponto de controle, repetimos as validações e direcionamos os relatórios históricos para a nova estrutura, depois executamos um conjunto curto de consultas conhecidas em ambos os lados para confirmar totais, limites e amostras antes de liberar a plataforma, com um procedimento de retorno que preservava a origem e permitia desfazer o direcionamento sem tentar reimportar todo o histórico às pressas.

As primeiras consultas no destino ainda apresentaram planos inadequados, porque as estatísticas não representavam bem a distribuição recém importada e alguns filtros combinavam colunas de uma forma diferente da observada no laboratório, então atualizamos estatísticas, revimos índices, reescrevemos consultas específicas e medimos novamente com períodos pequenos e extensos, evitando declarar o projeto encerrado no momento em que o último lote havia sido copiado.

Também implementamos uma política contínua de retenção, na qual novos eventos permanecem no banco operacional pelo período necessário e depois seguem para o histórico com os mesmos controles de lote e validação, acompanhada de indicadores de crescimento, divergência, atraso e desempenho, pois sem esse ciclo a plataforma voltaria ao ponto inicial alguns meses depois e a grande migração teria servido apenas como uma limpeza excepcional.

O resultado foi um banco operacional menor e mais previsível, relatórios históricos capazes de consultar períodos longos sem disputar o mesmo espaço das ações atuais e um processo verificável para continuar movendo dados, mantendo a trilha de auditoria sem exigir que toda consulta, antiga ou recente, percorresse um bilhão de linhas no coração da plataforma.