A cada nova release do Protheus, a mesma pergunta aparece na sala: quantas horas de operação vamos sacrificar desta vez? Enquanto o migrador roda, faturamento, expedição, financeiro e fechamento esperam. Em uma operação que funciona 24 horas por dia, essa conta simplesmente não fecha.
Este artigo documenta, com os números e os diagramas do relatório final do projeto, como executamos uma migração com zero downtime em um ambiente TOTVS Protheus de grande porte: banco Oracle de 11 TB em um RAC de dois nós, duas empresas no mesmo ambiente, cada uma com o próprio dicionário de dados, e um salto de várias releases de uma vez. A simulação da virada convencional mediu 20 horas e 38 minutos de indisponibilidade. Com a arquitetura de zero downtime, a parada na virada caiu para cerca de 30 minutos.
Por que a virada convencional dói
No método tradicional, a receita é conhecida: o sistema para, o migrador roda na própria base de produção e o ambiente só volta quando tudo termina. Em bases pequenas, funciona. Em bases de terabytes, não: a migração altera, recria e exclui estruturas sobre o banco inteiro, de forma sequencial e sem aproveitar paralelismo. O tempo cresce junto com o dado.
Antes de propor o zero downtime, rodamos duas simulações de virada convencional nesse ambiente para medir o processo de ponta a ponta: 2 horas de backup, 8 horas de tratamento de duplicidades, 9 horas e 39 minutos de migrador de release, quase 1 hora de ajustes finais. Total: 20 horas e 38 minutos com o sistema parado.
E existe o risco que o cronômetro não mostra: se algo falhar na hora 15, o caminho de volta é um restore. Com o negócio parado esperando.
A ideia por trás do zero downtime
A metodologia inverte a ordem dos fatores: em vez de parar a operação para migrar o banco, criamos uma segunda produção, já migrada para a release nova, e a mantemos sincronizada em tempo real com a produção atual. Todo o trabalho pesado acontece com o sistema no ar. A virada deixa de ser um evento e vira um detalhe: mudar o apontamento.
- Início da captura de transações na base produtiva.
- Backup completo da produção via RMAN, com o SCN anotado.
- Restore desse backup criando o novo banco de dados.
- Migração de release do Protheus executada sobre a base nova.
- Compatibilização de estruturas e dados entre as versões, com ferramentas próprias e tratamento de RUP.
- Streaming contínuo de dados entre as duas bases até o dia da virada.
- Virada: o Protheus passa a apontar para a nova base. Só isso.
A arquitetura por dentro
Replicação por CDC, guiada pelo SCN
O coração da solução é a replicação por CDC (Change Data Capture): cada transação confirmada na base atual é capturada a partir do archive log ou do redo log e reaplicada na base nova como DML e DDL, na ordem exata em que aconteceu, guiada pelo SCN (System Change Number) do Oracle. Os mapeamentos e conversões entre as versões são aplicados automaticamente durante essa replicação.
A ferramenta de streaming pode variar: Oracle GoldenGate, AWS DMS, SQL Server CDC ou Fivetran. O requisito inegociável é ler as mudanças com base no SCN e reproduzi-las de forma síncrona e sequencial. Do lado do banco, a preparação inclui supplemental logging, parâmetros de replicação, configuração de redo logs e archives e uma área dedicada para trail files.
Duas produções lado a lado
Do lado do ERP, montamos uma infraestrutura transitória que espelha a produtiva: RPO padrão e RPO customizado sincronizados entre os ambientes, migrador do Protheus e o banco replicado por CDC. Se uma janela de mudança altera a produção no meio do projeto, os RPOs são sincronizados de novo. Nada anda separado por muito tempo.
O processo, etapa por etapa
1. Backup, SCN e o nascimento da base nova
Tudo começa com um backup completo da produção via RMAN e um número anotado: o SCN daquele instante. Ele é a fronteira exata entre o que o backup carrega e o que a replicação vai reaplicar depois. É isso que garante que nenhuma transação se perde no caminho: o que aconteceu depois do backup chega à base nova pelo streaming, na ordem certa.
2. O migrador roda na base nova, a produção segue no ar
Com a base restaurada, a migração de release do Protheus roda inteira ali: UPDDISTR, UPDBATCH, atualização de binários e DBAccess. As 9 horas e 39 minutos de migrador, que na virada convencional seriam downtime puro, viram trabalho de bastidor. Os usuários seguem trabalhando na base atual, sem interrupção.
3. Compatibilizar as versões: dicionário, regras e RUP
Duas releases diferentes significam estruturas diferentes. Usamos ferramentas de domínio próprio para mapear as discrepâncias entre os dicionários das duas versões e transformá-las em regras de replicação: valores padrão para campos novos, tratamento de colunas com tamanhos diferentes, regras condicionais para campos modificados ou unidos. As tabelas de dicionário (as famílias SX e XX) ficam fora da réplica de propósito: quem cuida delas é o migrador.
Há ainda o capítulo que a TOTVS considera crucial em migrações com streaming de dados: o RUP, que engloba estruturas que não mudaram entre as versões, mas cujos dados mudaram. O mesmo mapeamento identifica esses casos e aplica as regras para que a replicação continue íntegra entre as releases.
4. Réplica contínua até o dia da virada
Dali em diante, as duas produções vivem em paralelo: a replicação em tempo real mantém os bancos idênticos, e a preparação da virada acontece com dias ou semanas de antecedência. Dbaccess, appservers, APO, TSS e license server do ambiente futuro já ficam configurados em pastas espelhadas, idênticas às da produção atual com um caractere de diferença no nome. No dia da virada, os caminhos e as configurações já são os definitivos.
O dia da virada e o plano B
A virada aconteceu de madrugada, em uma janela entre 01h30 e 03h30: sincronização final do banco, alteração de DNS, acerto de sequences e indexação. A migração da base de dados em si se resumiu a um apontamento, feito via DNS e TNS. E o plano B ficou tão simples quanto: se algo desandar, o apontamento volta para o ambiente anterior, que permanece intacto. Reverter a migração custa minutos, não um restore de horas.
Os números, lado a lado
| Etapa | Virada convencional | Zero downtime |
|---|---|---|
| Backup completo | 2h00 com o sistema parado | dias antes, com o sistema no ar |
| Tratamento de duplicidades | 8h00 | antes da virada, sem parada |
| Migrador de release (UPDDISTR) | 9h39 | antes da virada, na base nova |
| Ajustes finais (UPDBATCH) | 0h59 | antes da virada |
| Mudança de apontamento | incluída na janela | cerca de 30 minutos |
| Indisponibilidade total | 20h38 | 0h30 |
De 20 horas e 38 minutos para 30 minutos: 97,68% menos indisponibilidade na virada.
Quando o zero downtime vale a pena
Sendo honesto com os dois lados: a virada convencional é mais simples e autoguiada, e continua sendo uma escolha razoável para bases pequenas, com janela de parada confortável e tolerância a indisponibilidade. O zero downtime exige mais tempo de planejamento e conhecimento avançado de replicação, dicionário e infraestrutura para montar e administrar o processo.
Em troca, ele entrega o que o método tradicional não consegue: o sistema disponível durante todo o processo, testes e validações com dados reais antes da virada, rollback trivial e muito mais segurança para os dados. Para operações 24×7, bases que crescem sem parar e saltos grandes de release, o tempo de migração do método convencional cresce junto com o banco. O do zero downtime, não.
O que os testes nos ensinaram
Nenhuma migração desse tamanho sai perfeita de primeira, e é exatamente para isso que a metodologia prevê simulações e homologação antes do dia 0. Foi nos testes que apareceram duplicidades no dicionário de dados (tabelas SX3010 e SX3020), sequences fora de ordem gerando violação de unicidade, corrigidas com a equalização das triggers, e triggers customizadas que a mudança de estrutura invalidou. Tudo mapeado, corrigido e validado antes da produção. Na virada real, nada disso apareceu.
Desde essa primeira execução, o processo virou rotina nesse ambiente: a cada ciclo de release, a nova produção nasce ao lado da atual e a operação não para. O resumo dessa história, com o resultado mais recente, está na nossa página de cases.
Perguntas frequentes
O que é uma migração de Protheus com zero downtime?
É a metodologia que cria uma segunda produção, já migrada para a release nova e sincronizada em tempo real com a atual por CDC. Todo o trabalho pesado acontece com o sistema no ar e a virada se resume a mudar o apontamento do Protheus para a base nova.
Quanto tempo o sistema fica indisponível na virada?
Neste projeto, cerca de 30 minutos de mudança de apontamento, em uma janela de madrugada, contra 20 horas e 38 minutos medidos na simulação da virada convencional: 97,68% menos indisponibilidade.
E se algo der errado depois da virada?
O rollback é voltar o apontamento para o ambiente anterior, que permanece intacto e sincronizado. A reversão custa minutos, sem restore e sem perda de dados.
A metodologia funciona com qualquer banco e ferramenta de replicação?
O requisito é uma replicação por CDC capaz de ler as mudanças na ordem das transações, como Oracle GoldenGate, AWS DMS, SQL Server CDC ou Fivetran. Cobrimos os dois mundos do Protheus, Oracle e SQL Server, e adaptamos a ferramenta ao ambiente do cliente.
Quer subir de release sem parar a sua operação? Conheça o upgrade de Protheus com zero downtime dentro da nossa frente de consultoria e sustentação de Protheus, que cuida também do banco de dados por trás do ERP. Ou fale direto com um especialista: você descreve o cenário e sai da conversa com um caminho honesto.