Alterações de banco de dados sem indisponibilidade: Expand e Contract

Objetivo

Alterar a estrutura do banco de dados enquanto o serviço continua atendendo, de modo que cada estado intermediário funcione tanto com a versão antiga quanto com a nova do código.

Pré-requisitos

Migrações versionadas junto com o código; um processo de deploy capaz de entregar código e migrações separadamente; conhecimento de quais comandos adquirem bloqueios fortes. A documentação do PostgreSQL sobre ALTER TABLE indica o nível de bloqueio de cada forma do comando. A maioria adquire ACCESS EXCLUSIVE, que bloqueia qualquer outro uso da tabela. A documentação também registra que ADD COLUMN com um DEFAULT não volátil grava o valor nos metadados em vez de reescrever a tabela; que uma restrição CHECK ou NOT NULL lê a tabela, mas não a reescreve; e que uma restrição criada com NOT VALID só é verificada por VALIDATE CONSTRAINT, que adquire apenas um bloqueio SHARE UPDATE EXCLUSIVE. CREATE INDEX CONCURRENTLY constrói um índice sem bloquear inserções, alterações e exclusões na tabela. O parâmetro lock_timeout cancela um comando que espera por um bloqueio mais tempo do que o valor definido.

Passos

1. Expand: criar a nova coluna, tabela ou índice de forma rápida e sem bloqueio (coluna anulável ou com default constante, CREATE INDEX CONCURRENTLY, restrições NOT VALID). O código antigo ignora o que é novo.
2. Executar cada migração com lock_timeout definido (alguns segundos) e, se ela for cancelada, tentar de novo, em vez de formar, atrás de um bloqueio em espera, uma fila de requisições bloqueadas.
3. Entregar o código que grava as duas representações e continua lendo a antiga.
4. Preencher as linhas existentes em lotes pequenos, com pausas; acompanhar os tempos de espera por bloqueios e o atraso de replicação. Depois, executar VALIDATE CONSTRAINT.
5. Entregar o código que lê a nova representação e, por um tempo, a compara com a antiga (registrando as divergências).
6. Parar de gravar a representação antiga; entregar.
7. Contract: remover a coluna ou tabela antiga em um release posterior, quando um rollback para a versão anterior do código não for mais necessário.

Resultado esperado

Cada deploy é reversível por si só; nenhuma migração mantém um bloqueio por tempo suficiente para ser notada.

Limites e base de verificação

O padrão multiplica o número de etapas e leva dias em vez de minutos. Quando as duas versões do código precisam rodar ao mesmo tempo, uma coluna é renomeada como «criar, copiar, excluir», e não com RENAME. O comportamento dos bloqueios segue a documentação citada; não se afirmam tempos. Se lock_timeout com nova tentativa reduz o número de incidentes, isso está registrado no wiki como hipótese, não como resultado comprovado.

Repetir de olho em quem bloqueia

Um cancelamento por lock_timeout é uma informação, não um convite a um laço infinito: a própria solicitação de bloqueio em espera já bloqueia todos os novos acessos atrás dela, e cada nova tentativa causa mais uma breve paralisação. Antes da próxima tentativa, pg_blocking_pids(pg_backend_pid()), junto com pg_stat_activity (state, xact_start, query), mostra quem detém o bloqueio. Uma consulta analítica longa ou uma sessão presa em idle in transaction não termina sozinha; nesse caso, esperar, cancelar ou usar pg_terminate_backend é uma decisão consciente, e idle_in_transaction_session_timeout previne o tipo mais comum. O laço precisa de uma pausa entre as tentativas e de um limite máximo. lock_timeout limita apenas a espera pelo bloqueio; a duração de VALIDATE CONSTRAINT e dos lotes de preenchimento é limitada por statement_timeout.