Migrámos nossa base de dados PostgreSQL com 11 segundos de indisponibilidade
Uma equipe do governo do Reino Unido descreve a migração de um banco de dados PostgreSQL de 400 GB para uma nova instância AWS RDS para o serviço GOV.UK Notify com apenas 11 segundos de indisponibilidade, usando AWS Database Migration Service, truques de DNS e replicação lógica. Comentários contrastam essa abordagem com alternativas como ferramentas nativas do PostgreSQL e implantações blue/green do RDS, observando tanto o poder quanto as armadilhas do DMS, especialmente em escala ou com schemas complexos. A mudança também reacende um debate mais amplo sobre a dependência de governos de provedores de cloud estrangeiros, equilibrando resiliência operacional e restrições de contratação contra soberania de dados, custo e controle de longo prazo da infraestrutura crítica.
Uso da AWS pelo Governo do Reino Unido
- Muitos ficam desconfortáveis com o fato de um serviço central do governo britânico rodar na AWS, uma empresa dos EUA, por preocupações com soberania de dados, risco geopolítico e dependência de um fornecedor estrangeiro.
- Outros argumentam que a AWS traz forte conformidade, segurança e confiabilidade, e provavelmente é melhor do que os data centers governamentais internos típicos.
- Alguns observam que o serviço já estava na AWS via GOV.UK PaaS; essa mudança altera principalmente contas/arquitetura, não a dependência básica.
Debate sobre Cloud vs On-Prem / Soberania
- Críticos dizem que um país rico do G7 deveria construir sua própria “public sector cloud” ou operar on-prem para manter conhecimento institucional e controle.
- Contra-argumentos: a contratação de TI no governo é lenta e mal remunerada; on-prem é caro, complexo e muitas vezes acaba terceirizado para grandes integradores de qualquer forma; a cloud pública facilita compras e escala (por exemplo, em pandemias).
- Há uma preocupação mais ampla com a dependência disseminada de tecnologia dos EUA (AWS, Microsoft, Palantir, etc.).
AWS DMS e Abordagens de Migração
- O tópico inclui experiências mistas com o AWS Database Migration Service (DMS):
- Alguns o consideram bugado, opaco e mal suportado, com relatos de corrupção silenciosa de dados, problemas em mudanças de schema e limitações de tipos.
- Outros relatam uso bem-sucedido para MySQL↔Postgres e on-prem→AWS, mas ressaltam testes cuidadosos e transformações mínimas.
- Vários observam que a própria documentação da AWS recomenda ferramentas nativas do Postgres (pg_dump, replicação lógica) para migrações Postgres→Postgres; o DMS pode adicionar complexidade desnecessária.
Indisponibilidade, DNS e Tratamento de Consultas
- As 11 segundos de indisponibilidade do artigo são vistas como boas, mas alguns argumentam que é possível reduzir ainda mais pausando conexões via pgbouncer/pgpool em vez de um corte brusco.
- A dependência de DNS TTL=1s preocupa alguns, já que nem todos os resolvedores respeitam TTL; o comportamento de connection pooling também é discutido.
- Consultas e transações longas são destacadas como inimigas de cutovers sem downtime; timeouts e disciplina operacional ajudam.
Ferramentas e Padrões Alternativos
- Vários comentaristas defendem replicação lógica do Postgres, pglogical, pgloader ou replicação física/WAL para mudanças com pouco downtime.
- RDS Blue/Green Deployments recebem forte elogio por upgrades de versão com downtime quase zero e até mudanças de criptografia, embora sejam limitados entre contas e apenas para upgrades de avanço.
Cultura de TI Governamental e Procurement
- Vários descrevem a TI do setor público como limitada por orçamentos, procurement rígido, contratação lenta e cultura avessa a riscos, o que leva a decisões de “comprar, não construir”.
- Alguns veem a publicação de um relato detalhado e claro da migração como um sinal positivo de transparência e de boa prática de engenharia.