← Gestão de alterações: decisões em produção
07 / 12 · 60 MIN

Coexistência, migração e limites

Ensaiar compatibilidade entre versões exige observar leitores, writers, dados e pontos que alteram as opções de recuperação.

Reservar tempo com evidência proporcional

Uma janela que termina ao minuto 120 e exige 25 de recuperação, dez de validação e cinco de margem tem último início seguro de recuperação ao minuto oitenta. Ao minuto 76, um passo indivisível de dez não cabe antes desse limite. Esta conta só é útil se as durações tiverem fundamento. Um restauro de 25 minutos com um décimo dos dados não estabelece um máximo para produção, nem permite multiplicar por dez e chamar garantia ao resultado. Identifica volume, dependências, recursos e validações incluídos no ensaio. Usa observações representativas e explicita incerteza. Quando uma premissa deixa de ser válida, atualiza a decisão antes de gastar a reserva.

Vincular a verificação ao efeito que controla

Uma leitura de revisão seguida por uma escrita incondicional deixa uma janela em que outro processo pode alterar o estado. No ensaio, a condição WHERE revision=? está na própria instrução que modifica a linha e incrementa a revisão. Zero linhas indica que a premissa não correspondeu. Este controlo protege essa alteração na base, sob as condições demonstradas; não protege automaticamente um ficheiro, uma chamada remota ou uma alteração feita fora da instrução. Também não transforma capacidade técnica em autorização organizacional. Num plano de execução, identifica onde cada gate é aplicado, que efeito impede e quais operações continuam fora do seu âmbito. Um OK guardado num log é evidência histórica, não um bloqueio permanente.

Expandir sem generalizar a compatibilidade

O laboratório cria orders com amount_units inteiro e uma linha de valor cem. Depois acrescenta amount_cents opcional. A consulta explícita SELECT amount_units continua a devolver cem, enquanto o novo campo fica NULL. O ensaio demonstra uma combinação concreta de leitor e schema, não todos os clientes antigos. Um cliente que dependa da posição de colunas ou de uma forma rígida de INSERT pode ter outras condições. A nova coluna também não fica preenchida por existir. Antes de promover a leitura nova, identifica a regra de conversão e a origem de verdade durante coexistência. O exemplo usa unidades inteiras e multiplicação por cem; não constitui um desenho completo de valores monetários.

Observar o que acontece depois do backfill

O backfill define amount_cents=amount_units×100. Nesse instante, cem unidades e dez mil cêntimos concordam. Uma segunda ligação, representando um writer antigo, atualiza apenas amount_units para 125. A nova coluna mantém dez mil, quando a regra exigiria 12500. Não houve corrupção física: integrity_check devolve ok. A divergência resulta do caminho de escrita durante coexistência. Um job mensal pode produzir este efeito depois de um canário curto aparentemente saudável. Inventaria todos os produtores relevantes, incluindo manutenção e fecho, e escolhe uma estratégia explícita para manter consistência. Repetir o backfill pode reconciliar um instante, mas não resolve sozinho as escritas futuras do produtor antigo.

Testar falha entre duas escritas

Após reconciliar para 125 e 12500, o ensaio inicia uma transação, altera o campo antigo para 150 e injeta uma exceção antes da segunda escrita. O código executa ROLLBACK e confirma que o par continua 125/12500. Depois, uma transação bem-sucedida muda ambos para 150/15000. O resultado demonstra atomicidade no âmbito exercitado e tratamento explícito da falha. Não significa que qualquer exceção Python reverta automaticamente todos os recursos. Não adapta writers antigos e não testa concorrência distribuída. Para a mudança real, inclui falhas nos pontos relevantes, verifica o estado resultante e documenta os caminhos que ainda não usam o mecanismo de escrita compatível.

Reconhecer o ponto que quebra o contrato antigo

Por fim, o script remove amount_units. A consulta nova devolve 15000 cêntimos e a consulta antiga falha com no such column. O ficheiro do binário anterior pode continuar disponível, mas o contrato de que depende desapareceu. A contração deve ser uma decisão própria, com inventário de consumidores, observação adequada e recuperação compatível com o estado pretendido. Não concluas que a expansão inicial tornou todo o percurso reversível. Testa as direções de compatibilidade necessárias: versão nova sobre dados anteriores, versão antiga sobre dados produzidos pela nova e estado após remoção. Se uma combinação deixa de funcionar, atualiza as opções de recuperação antes de a prometer ao RUN.

-- Disposable lab only; all data is fictional.
ALTER TABLE orders ADD COLUMN amount_cents INTEGER;
UPDATE orders SET amount_cents=amount_units*100;
-- An old writer can now make the new column stale:
UPDATE orders SET amount_units=125 WHERE id=1;
SELECT amount_units,amount_cents FROM orders; -- 125, 10000
NA PRÁTICA

Um serviço fictício migra a representação de valores enquanto um job de fecho mantém o código antigo. O ensaio revela divergência antes de promover a leitura nova.

Armadilhas comuns

Tratar backfill como sincronização, sucesso de uma consulta como compatibilidade universal, exceção como rollback automático ou binário guardado como recuperação demonstrada.

Tópicos relacionados: SQL · Bases de dados · Disaster Recovery

Leva esta ideia contigo

A compatibilidade depende de caminhos de leitura e escrita e do estado produzido. Ensaiar a coexistência torna visíveis riscos que o deployment isolado não mostra.

Criar conta

Referência: SQLite ALTER TABLE · DR Change Management 2026.1; independent technical curriculum