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".

Transcript

1. PostgreSQL Upgrade
   Like a Boss
   @fabriziomello
   

   View Slide

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

   View Slide

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

   View Slide

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/
   

   View Slide

5. PostgreSQL Versioning Numbering
   MAJOR . MINOR . PATCH
   9.6.15
   MAJOR . PATCH
   11.5
   ... 9.6 10 ...
   

   View Slide

6. Rollback
   • Gerência de Risco
   • Planejar primeiro
   • Recursos computacionais a disposição
   

   View Slide

7. Minor Upgrade
   - Binários compatíveis
   - Não existe necessidade de dump/restore ou
   pg_upgrade
   - Necessita “restart” (downtime mínimo)
   

   View Slide

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
   

   View Slide

9. Major Upgrade
   • Existe janela para “downtime”?
   • Qual o tamanho do cluster?
   • Existe recurso computacional para Rollback?
   

   View Slide

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)
    

    View Slide

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)
    

    View Slide

12. Casos Reais
    

    View Slide

13. View Slide

14. View Slide

15. View Slide

16. View Slide

17. Come to the “Elephant” side of the force !!
    

    View Slide

18. View Slide

19. contato@timbira.com.br
    

    View Slide