Migrações de dados sem downtimes! Truques e lições aprendidas com PostgreSQL na Olist, TDC Porto Alegre 2020

Você tem receio de executar migrações de dados? Tem que rodar elas de madrugada, torcendo para não afetar a performance do sistema? Na Olist tivemos vários problemas em decorrência de migrações em tabelas grandes no PostgreSQL, e também muitos aprendizados de truques de como fazê-las e monitorá-las com segurança.

Transcript

1. Migrações de dados sem downtimes! Jéssica Bonson Principal Engineer no Olist TDC Porto Alegre 2020, Trilha Big Data Truques e lições aprendidas com PostgreSQL no Olist
2. Jéssica Pauli de C Bonson • +-8 anos de exp em pesquisa/desenvolvimento • graduação/mestrado em Ciências da Computação • foco em dev backend, machine learning e big data Jogar RPG Livros Duolingo Hobbies:
3. Maior loja nos principais marketplaces do Brasil. Arquitetura em microsserviços e serverless. Python. Go. PostgreSQL. AWS. Kubernetes. 20+ APIs 120+ serviços 3m+ produtos 30k+ logistas 10m+ anúncios 230k+ pedidos por mês
4. • As migrações de dados são parte do processo de deploy. ◦ Alterações nas tabelas ou nos dados • Como executar as migrações? ◦ Downtime X Runtime
5. Conceitos
6. DELETEs e UPDATEs no Postgres • DELETEs não deletam dados, matam • UPDATEs não atualizam dados, duplicam • Por quê? ◦ Rollback de transações ◦ Diferentes visibilidades de dados ◦ Permitir escrita em paralelo com leitura • Resultado: Cemitério de linhas mortas
7. VACUUM • É quem deleta ‘de verdade’ • Não causa exclusive locks nas tabelas • Só deleta dead rows quando não estão mais sendo usadas • Na verdade, não deleta, só marca para reuso ◦ Alternativa: VACUUM FULL
8. Autovacuum • PostgreSQL sabe se virar ◦ Um daemon checa as tabelas de tempos em tempos ◦ Se necessário, roda o VACUUM • Porém… transações lentas são um problema ◦ VACUUM não consegue deletar as linhas ◦ Causa table bloat
9. Table Bloat • Live rows X Dead rows • Se o VACUUM continuar sem conseguir rodar… ◦ A tabela fica cada vez maior ◦ VACUUM leva mais tempo ◦ Performance da API piora • Se for um problema recorrente, tunar o autovacuum
10. heroku pg:vacuum_stats DATABASE_URL --app <app_name> https://github.com/heroku/heroku-pg-extras
11. Locks Locks
12. Migrações para atualização de dados
13. Antes UPDATE product SET currency = 'BRL' WHERE currency is Null;
14. • Fazer a atualização registro a registro • Dividir a migração em lotes Como resolver?
15. SELECT id FROM product WHERE currency is Null LIMIT :limit; Depois UPDATE product SET currency = 'BRL’ WHERE id = :id;
16. Migrações para alteração de tabelas (PostgreSQL < 11)
17. ALTER TABLE freight ADD COLUMN enable_subsidy boolean NOT NULL DEFAULT FALSE; Antes
18. • Dividir a migração em partes: ◦ Exemplo: Criar campo com default False i. Criar campo novo nullable ii. Setar default da coluna para False iii. Setar valores do campo para False iv. Remover nullable Como resolver?
19. ALTER TABLE freight ADD COLUMN enable_subsidy boolean; ALTER TABLE freight ALTER COLUMN enable_subsidy SET DEFAULT FALSE; < Migração para alterar os valores do campo para FALSE > ALTER TABLE freight ALTER COLUMN enable_subsidy SET NOT NULL; Depois
20. Migrações para alteração de tabelas (PostgreSQL >= 11)
21. ALTER TABLE freight ADD COLUMN enable_subsidy boolean NOT NULL DEFAULT FALSE; Quase instântaneo!
22. Réplicas
23. Trade-offs • Custo x Benefício ◦ Melhor performance de leitura ◦ Alta disponibilidade ◦ Tolerância a falhas ◦ Custo maior ◦ Performance de escrita vs Consistência dos dados
24. Monitoramento
25. PgHero
26. Elastic APM
27. CloudWatch (AWS)
28. Dicas e Precauções
29. Django • Testar tempo da migração localmente ◦ time python manage.py migrate • Verificar o SQL que será executado ◦ python manage.py sqlmigrate <app> <número da migração>
30. Modelagem do BD • UPDATE vs INSERT • Estrutura das tabelas de histórico • CREATE INDEX CONCURRENTLY vs CREATE INDEX
31. Precauções • Antes da migração… ◦ Evitar executar em horário de pico ◦ Lidar com queries longas em execução ◦ Criar backup do banco de dados ◦ Avisar os outros developers
32. Valeu! @jpbonson
33. Referências https://www.citusdata.com/blog/2018/02/15/when-postgresql-blocks/ http://pankrat.github.io/2015/django-migrations-without-downtimes/ https://momjian.us/main/writings/pgsql/nulls.pdf https://www.citusdata.com/blog/2018/02/22/seven-tips-for-dealing-with-postgres-locks/ https://www.cybertec-postgresql.com/en/a-beginners-guide-to-postgresqls-update-and-autovacuum/ https://devcenter.heroku.com/articles/managing-vacuum-on-heroku-postgres https://www.datadoghq.com/blog/postgresql-vacuum-monitoring/ https://www.cybertec-postgresql.com/en/reasons-why-vacuum-wont-remove-dead-rows/ https://www.percona.com/blog/2018/08/06/basic-understanding-bloat-vacuum-postgresql-mvcc/ https://blog.timescale.com/scalable-postgresql-high-availability-read-scalability-streaming-replication-fb95023e2af/ https://realpython.com/create-django-index-without-downtime/ http://www.interdb.jp/pg/pgsql06.html https://stackoverflow.com/questions/1113277/how-do-i-do-large-non-blocking-updates-in-postgresql https://www.devmedia.com.br/transacoes-no-postgresql-locks-e-bloqueios/5164 https://www.postgresql.org/docs/current/transaction-iso.html https://www.percona.com/blog/2018/10/16/postgresql-locking-part-1-row-locks/