Upgrade de Postgres sem downtime

Preparação para o upgrade do Postgres

• Avaliação de riscos: listar os riscos que podem surgir durante o processo de upgrade e ordená-los por importância.
• Busca de soluções para os riscos: considerar soluções que eliminem completamente os riscos ou que permitam distribuí-los ao longo do tempo.
• Atualização da lista de riscos: atualizar a lista quando novos riscos forem descobertos durante o andamento do projeto.

Sobre monitoramento e métricas

• Monitoramento do sistema: usar ferramentas robustas para acompanhar a saúde do banco de dados e do sistema.
• Observação das métricas principais: monitorar métricas importantes como transaction ID, uso de CPU, sessões em espera, latência de queries e latência de resposta da API.

Opções de upgrade do Postgres

Upgrade in-place (inadequado para upgrade com zero downtime)

• Limitações do upgrade in-place: ao executar no AWS RDS, é necessário reiniciar o banco de dados, e o tempo necessário varia conforme o volume de dados.

Upgrade baseado em replicação

• Escolha do upgrade baseado em replicação: etapas de migração graduais, teste do novo banco com carga de trabalho e dados reais, e maior controle sobre o upgrade.
• Configuração dos bancos de origem e destino: configurar replication slots e definir wal_level como logical.

Escolha do método de replicação de tabelas

Replicação de tabelas "pequenas"

• Replicação de tabelas pequenas: é possível replicá-las com uma simples adição e atualização da assinatura.

Tabelas grandes, somente de inserção

• Replicação de tabelas somente de inserção: definir a opção copy_data como false para replicar apenas mudanças futuras e depois preencher os dados antigos a partir de um backup.

Tabelas grandes com muitas atualizações

• Replicação de tabelas grandes com muitas atualizações: reduzir o tamanho da tabela, executar VACUUM e considerar particionamento.

Verificação do estado da replicação

• Monitoramento do estado da replicação: verificar o estado da replicação por meio da tabela de sistema pg_subscription_rel; recomenda-se replicar uma tabela por vez.

Interrupção da replicação

• Como interromper a replicação: se necessário, é possível interromper a replicação de tabelas e reverter com uma atualização da assinatura.

Cuidados com a migração de replication slots

• Problema na migração de replication slots: o LSN de um replication slot é exclusivo do banco de dados principal, portanto não pode ser copiado diretamente para o novo banco.

Finalizando a migração

• Validação da consistência das tabelas: confirmar que a contagem de linhas das tabelas coincide entre os dois bancos e, se necessário, validar a consistência dos dados com amostragem aleatória.

Mudanças no nível da aplicação

• Alteração da conexão com o banco: mudar a aplicação para se conectar ao novo banco de dados e definir uma estratégia de transição de tráfego.

Observações adicionais sobre sequences

• Sincronização de sequences: como os valores de sequence não são sincronizados durante a replicação, é preciso ajustá-los manualmente.

Checklist final

• Verificação final: consistência das tabelas, estado da assinatura, consistência do schema, tamanho do banco de dados, adição de réplicas, reconstrução de índices, testes de performance, avaliação de riscos e ensaio em ambiente de staging.

Troca final

• Execução da troca final: replicar as tabelas no período da noite, praticar várias vezes em ambiente de staging e então fazer a verificação final e a troca do flag.

Opinião do GN⁺

• Importância: a Knock concluiu com sucesso o processo complexo de upgrade do Postgres 11.9 para 15.3 com zero downtime. Isso representa um marco importante para gestão de bancos de dados e disponibilidade de serviço.
• Interessante: a abordagem de upgrade baseada em replicação permite uma transição suave para o novo banco de dados, algo que pode atrair grande interesse entre administradores de banco e a comunidade técnica.
• Curiosidade: o processo de upgrade da Knock mostra um excelente exemplo de como superar desafios técnicos complexos com gestão sistemática de riscos e resolução de problemas.

[GN⁺]

Comentários do Hacker News

• Existe uma abordagem melhor do que copiar tabelas grandes.

  • É possível criar uma réplica lógica com criação de slot de replicação, obtenção de snapshot, restauração do snapshot em uma nova instância, avanço do LSN e início da replicação.
  • Um artigo da Instacart descreve esse processo.
  • O artigo pode ter pequenos erros, mas isso já foi usado com sucesso várias vezes para fazer upgrade de instâncias em escala de TB.

• A abordagem apresentada aqui é interessante e bem documentada, mas não concorda com a frase "clientes modernos esperam 100% de disponibilidade".

  • Pela experiência como cliente ou fornecedor, consistência é muito mais importante do que disponibilidade.
  • Quando um fornecedor avisa sobre downtime, isso é visto como um sinal de que os dados estão sendo tratados com cuidado, o que traz alívio.

• A AWS agora oferece suporte a implantações blue-green.

• Foi criada uma ferramenta que automatiza a maior parte dos problemas.

  • A ferramenta é compartilhada no GitHub e pode ser expandida com feedback ou ideias.

• Na hava.io, está em andamento uma migração do AWS RDS PostgreSQL 11.13 para 15.5.

  • Foi escolhida uma abordagem de replicação unidirecional com pglogical.
  • Essa abordagem não é rápida, mas pode levar alguns dias para replicar gradualmente o banco de dados para a nova instância.
  • Ela oferece mais liberdade para alterar o tipo e o tamanho do armazenamento.

• Há ceticismo quanto à afirmação de que qualquer downtime seria inaceitável para o serviço da Knock.

  • Sistemas complexos têm incidentes e downtime.
  • Um downtime de 15 minutos anunciado com antecedência não é um problema para a maioria dos negócios SaaS.
  • Investir tempo de engenharia no desenvolvimento do produto ou em aumentar a velocidade do time de desenvolvimento pode trazer mais satisfação aos usuários.
  • Em migrações de banco de dados, a diferença de esforço entre criar uma migração com "pouco downtime" e uma migração com "zero downtime" é grande.

• Há surpresa pelo fato de não ser possível inicializar a replicação a partir de um backup.

  • Isso poderia reduzir a complicação de fazer streaming do conteúdo de um DB estável existente para o novo servidor.
  • Embora se fale em "zero downtime", na prática há alguns segundos de indisponibilidade durante a troca para o novo servidor.
  • Faltam detalhes sobre como a consistência é mantida.
  • Não há menção a uma opção de rollback, e ao realizar uma migração única de dados em grande escala é sempre necessário ter um plano para voltar à etapa anterior.

• Pergunta-se se haveria interesse em uma ferramenta all-in-one que faz atualização de Postgres com zero downtime apenas informando as credenciais do banco de dados.

• A parte sobre uso de sequences é interessante.

  • Em vez de sequence, normalmente são usados UUIDs sequenciais ou o algoritmo HiLo.

• Em tom de brincadeira, diz-se que problemas em sistemas distribuídos podem ser resolvidos com um apropriado sleep(1000).

  • Postgres não é um sistema familiar para DBAs, mas está melhor do que antes.