Treinamento PostgreSQL - Aula 09 Eduardo Ferreira dos Santos SparkGroup Treinamento e Capacitação em Tecnologia eduardo.edusantos@gmail.com eduardosan.com 10 de Junho de 2013 Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 1 / 21 edua
Cronograma Semana 1: 27 de Maio a 3 de Junho Administração de Dados Semana 2: 4-11 de Junho Administração de Banco de Dados Semana 3: 13-18 de Junho Alta disponibilidade Semana 4: 19-24 de Junho Performance Tuning Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 2 / 21 edua
Backup [PostgreSQL, 2013] Tipos de backup SQL Dump Utilização da ferramenta pg_dump para gerar diferentes tipos de backup: Comandos SQL para recriação da base Utiliando COPY Utilizando INSERT Formato binário padrão do PostgreSQL (pg_dump -FC) Backup do sistema de arquivos Compressão e empacotamento do diretório PGDATA t a r c z v f backup. t a r. gz / u s r / l o c a l / p g s q l / data PITR Arquivamento contínuo e Point-in-Time Recovery Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 3 / 21 edua
Backup [PostgreSQL, 2013] SQL Dump # Backup com COPY pg_dump dbname > o u t f i l e # Usando INSERT pg_dump i n s e r t s dbname > o u t f i l e # R e s t o r e p s q l dbname < i n f i l e # Backup de t o d o o c l u s t e r pg_dumpall > o u t f i l e p s q l f i n f i l e p o s t g r e s # Compressao e n q u a n t o g e r a o backup pg_dump dbname g z i p > f i l e n a m e. gz g u n z i p c f i l e n a m e. gz p s q l dbname # D i v i d i n d o em p e q u e n o s a r q u i v o s de 1M pg_dump dbname s p l i t b 1m f i l e n a m e c a t f i l e n a m e p s q l dbname # Formato b i n a r i o do PostgreSQL pg_dump Fc dbname > f i l e n a m e p g _ r e s t o r e d dbname f i l e n a m e Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 4 / 21 edua
Backup [PostgreSQL, 2013] Backup do sistema de arquivos t a r c z v f backup. t a r. gz / u s r / l o c a l / p g s q l / data Qualquer comando para cópia do diretório PGDATA pode ser utilizado: Duas restrições importantes que tornam a cópia física praticamente inutilizável: 1 É obrigatório parar o servidor para obter um backup reutilizável. 2 Fazer backup de certos arquivos e diretórios somente não funciona. Os dados das tabelas são inúteis sem referenciar as informações de transação na tabela pg_clog/, que contém o status de todas as transações. Resumo Não faça backup somente utilizando o sistema de arquivos. Salvo raríssimas exceções, não vai funcionar!!! Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 5 / 21 edua
Backup [PostgreSQL, 2013] Tempo de recuperação pg_dump 1 Tempo de recuperação do backup estimado? 1GB Uns 30min? 10GB Umas 3-4h? 100GB 1 dia inteiro? 500GB Vários dias? 1 Óbvio que o tempo é apenas um chute. O tempo para recuperação do backup depende de tantos fatores que não vale nem a pena citar Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 6 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. Falha no SO. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. Falha no SO. Sistema de arquivos corrompido. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. Falha no SO. Sistema de arquivos corrompido. Dados removidos e/ou alterados. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. Falha no SO. Sistema de arquivos corrompido. Dados removidos e/ou alterados. Falha do próprio PostgreSQL. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
Backup [PostgreSQL, 2013] pg_dump não é backup [Telles, 2010] Por que fazemos backup? Recuperação em caso de desastres! Para os tipos de desastre elencados, pg_dump resolve? Em quanto tempo? Desastre natural. Falha de hardware. Falha nos discos. Falha no SO. Sistema de arquivos corrompido. Dados removidos e/ou alterados. Falha do próprio PostgreSQL. duardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 7 / 21 edua
PITR Introdução 1 Backup [PostgreSQL, 2013] 2 PITR Introdução Congurando o arquivamento do WAL Executando o backup 3 Referências Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 8 / 21 edua
PITR Introdução Conceitos O log de transações (pg_xlog) contém o registro de todas as alterações realizadas no sistema. Existe para recuperação em caso de desastres: caso o sistema falhe, as transações podem ser executadas novamente. Ideia: utilizar um backup do sistema de arquivos junto com o backup do WAL. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 eduardo.edusantos@gmail.com 10 de Junho de 2013 9 / 21 edua
PITR Introdução Vantagens O backup não precisa estar 100% consistente para começar: se houver qualquer problema as transações do WAL são executadas novamente; O tamanho do WAL é indenidamente grande, então uma la de transações a executar pode ser criada; Nem todas as transações precisam ser executadas novamente. É possível parar em determinado momento e ter um backup consistente naquele ponto; Enviar os arquivos do WAL para outra máquina que contém um backup da estrutura do banco de dados gera um sistema de Warm Stand By, que a qualquer momento pode substituir o sistema principal. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 10 / 21 edua
PITR Introdução Restrições Administrar um sistema para o Warm Stand By envolve administrar um pequeno cluster. Não é uma tarefa simples 2. Só é possível restaurar todo o cluster, e não um pequeno subconjunto de dados. Para funcionar, a sequência de arquivos do WAL deve ser contínua. Assim, ajuste o cluster antes de executar o primeiro backup. 2 Vale sempre ressaltar que Banco de dados não é para amadores Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 11 / 21 edua
PITR Introdução Estrutura Backup [Momjian, 2010] Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 12 / 21 edua
PITR Congurando o arquivamento do WAL 1 Backup [PostgreSQL, 2013] 2 PITR Introdução Congurando o arquivamento do WAL Executando o backup 3 Referências Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 13 / 21 edua
PITR Congurando o arquivamento do WAL Etapas 1 Execute o backup físico 2 Ajuste o tamanho dos pedaços do WAL (WAL segments). Normalmente 16MB. 3 Altere os seguintes parâmetros no postgresql.conf: wal_level = 'archive' archive_mode = 'on' archive_command archive_command = ' t e s t! f /mnt/ s e r v e r / a r c h i v e d i r /%f && cp %p /mnt/ s e r v e r / a r c h i v e d i r /%f ' # U n i x archive_command = ' copy " % p " " C : \ \ s e r v e r \ \ a r c h i v e d i r \ \ % f " ' # Windows 4 Execute o backup. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 14 / 21 edua
PITR Congurando o arquivamento do WAL Observações importantes O usuário do banco de dados deve possuir permissão de escrita no diretório (normalmente postgres) Teste o comando antes de executar O comando pode falhar por várias razões: Falha de rede; Falta de espaço em disco; Falha no sistema de arquivos; Etc... O comando deve returnar status zero somente se não houver nenhuma falha Sempre considere o fator humano e tente encontrar as falhas o mais rápido possível. Normalmente o PostgreSQL vai executar um PANIC shutdown se houver alguma inconsistência no archive. Todas as outras observações possíveis. O seu backup não pode falhar. Mantenha o pg_dump. Vai que... Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 15 / 21 edua
PITR Executando o backup 1 Backup [PostgreSQL, 2013] 2 PITR Introdução Congurando o arquivamento do WAL Executando o backup 3 Referências Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 16 / 21 edua
PITR Executando o backup Passos 1 Certique-se de que o archive está congurado e funcionando; 2 Entre como superusário no banco e execute o comando: SELECT pg_start_backup ( ' l a b e l ' ) ; Ou o outro: SELECT pg_start_backup ( ' l a b e l ', t r u e ) ; 3 Copie o sistema de arquivos do banco de dados para outra máquina. Não é necessário parar o banco 4 Pare o backup: SELECT pg_stop_backup ( ) ; 5 Após a nalização da cópia, o backup está funcional. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 17 / 21 edua
PITR Executando o backup Observações Teste! Teste! Teste! Lembre-se de incluir todos os tablespaces no comando de cópia do archive O tempo entre a execução do pg_start_backup e do pg_stop_backup não é tão importante Verique o tamanho dos arquivos de backup e garanta que o diretório tem espaço suciente Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 18 / 21 edua
PITR Executando o backup Recuperando o backup 1 Pare o servidor, se estiver no ar 2 Se houver recursos disponíveis, copie todo o diretório PGDATA e os Tablespaces para outro servidor 3 Restaure todos os arquivos do backup físico realizado 4 Apague todos os arquivos do diretorio pg_xlog/ 5 Crie um arquivo de recuperação recovery.conf no diretório do Cluster para impedir conexões até que você esteja certo de que o backup está funcionando 6 Inicie o servidor 7 Verique se o arquivo recovery.done foi criado na pasta PGDATA 8 Verique o conteúdo do banco de dados Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 19 / 21 edua
PITR Executando o backup Recuperação Chave: criar um arquivo de conguração que diga claramente o que deve ser recuperado e quando deve. restore_command = ' cp /mnt/ s e r v e r / a r c h i v e d i r /%f %p ' # e. g. ' cp /mnt/ s e r v e r / a r c h i v e d i r /%f %p ' Perceba que o arquivo vem com todas as opções em branco. Montar cluster não é seguir receita de bolo. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 20 / 21 edua
PITR Executando o backup Estrutura para recuperação Point-In-Time Recovery [Momjian, 2010] Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 21 / 21 edua
Referências Momjian, B. (2010). Mastering postgresql administration. http://momjian.us/main/writings/pgsql/administration.pdf Acessado em 10/11/2009. PostgreSQL, C. (2013). Backup. http://www.postgresql.org/docs/9.1/interactive/backup.html Acessado em 10/06/2013. Telles, F. (2010). Dump não é backup. http://savepoint.blog.br/dump-nao-e-backup/ Acessado em 10/06/2013. Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 22 / 21 edua
Referências Contato Eduardo Ferreira dos Santos Sparkgroup Lightbase Consultoria em Software Público eduardo.santos@lightbase.com.br eduardo.edusantos@gmail.com www.postgresql.org.br www.eduardosan.com +55 61 3347-1949 Eduardo Ferreira dos Santos (SparkGroup TreinamentoePostgreSQL Capacitação- Aula em Tecnologia 09 10 eduardo.edusantos@gmail.com de Junho de 2013 22 / 21 edua