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
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
17. Come to the “Elephant” side of the force !!
19. contato@timbira.com.br