PostgreSQL Upgrade Like a Boss

PostgreSQL Upgrade Like a Boss

Quem não fica com os dedos coçando quando sai uma nova versão do PostgreSQL com "aquela" nova funcionalidade tão aguardada que irá resolver todos os seus problemas?? Parece simples né, basta instalar, configurar, efetuar um dump na versão antiga e restaurar na nova e pronto, tudo resolvido.

Infelizmente não é tão simples como parece pois existem algumas variáveis que julgo importate a serem consideradas como as versões envolvidas, tamanho do cluster, tempo minimo de downtime (SLA), entre outros.

Então iremos, baseado em diversas experiências que tive no mundo real, revisar diversas técnicas e formas e efetuar upgrade de versão do PostgreSQL desde casos mais simples com dump/restore até cenários complexos utilizando replicação física e/ou lógica. Falaremos de planejamento de upgrade, plano de rollback, garantindo contingencia antes, durante e depois do upgrade e também tomada de decisão de "quando atualizar" e "quando NÃO atualizar".

508e4ba6653fc7b538626f82e409e812?s=128

Fabrízio de Royes Mello

August 03, 2019
Tweet

Transcript

  1. PostgreSQL Upgrade Like a Boss @fabriziomello

  2. Fabrízio de Royes Mello Empreendedor Colaborador PostgreSQL Pai, Marido, etc

    ...
  3. Porque realizar upgrade? - Correção de Bugs/Falhas Segurança - Novos

    Recursos
  4. PostgreSQL Versioning Policy - Ciclos Anuais (major) - Versões corretivas

    trimestrais (minor) https://www.postgresql.org/developer/roadmap/ - Suporte por 5 (cinco) anos https://www.postgresql.org/support/versioning/
  5. PostgreSQL Versioning Numbering MAJOR . MINOR . PATCH 9.6.15 MAJOR

    . PATCH 11.5 ... 9.6 10 ...
  6. Rollback • Gerência de Risco • Planejar primeiro • Recursos

    computacionais a disposição
  7. Minor Upgrade - Binários compatíveis - Não existe necessidade de

    dump/restore ou pg_upgrade - Necessita “restart” (downtime mínimo)
  8. Minor Upgrade • Switchover/Switchback para minimizar downtime • Rollback? Manter

    cópia dos pacotes em um repositório local porque no oficial não ficam TODOS disponíveis
  9. Major Upgrade • Existe janela para “downtime”? • Qual o

    tamanho do cluster? • Existe recurso computacional para Rollback?
  10. Major Upgrade com Dump/Restore • Tempo de dump/restore (paralelo?) •

    Ao final temos um cluster totalmente “novo” • Tempo para warmup (cache das páginas)
  11. Major Upgrade com pg_upgrade • Dois modos: “copy” e “in-place”

    • Tranfere catálogo entre versões com pg_dump e copia ou linka (hard link) os datafiles • Tempo para warmup (cache das páginas)
  12. Casos Reais

  13. None
  14. None
  15. None
  16. None
  17. Come to the “Elephant” side of the force !!

  18. None
  19. contato@timbira.com.br