Começamos dizendo que o PostgreSQL utiliza dois métodos para realização de cópia de segurança: cópia física e cópia lógica. Na cópia física, realizamos a cópia dos arquivos pertinentes ao funcionamento do PostgreSQL (todos os datafiles, arquivos de log de transação, arquivos de controle) exceto arquivos de log e aqueles que podem ser gerados novamente (por exemplo, estatísticas e free space map). Na cópia lógica, geramos instruções SQL que serão capazes de reconstruir determinado banco de dados.
As características da cópia física são:
- online ou offline: a cópia pode ser feito com o serviço em execução;
- completa: não há seleção de bancos de dados. Todos bancos do agrupamento (cluster) devem ser copiados;
- incremental: a partir da cópia (a qual chamaremos de cópia base) podemos aplicar as mudanças (logs de transação) para chegar a qualquer ponto no tempo (PITR);
- mesmo hardware e sistema operacional: por utilizar um formato dependente de plataforma, não dá para pegar uma instalação no Windows e restaurar no AIX;
- versão do PostgreSQL: a cada nova versão, mudanças no catálogo impedem que o PostgreSQL seja compatível com agrupamento (cluster) de uma outra versão, isso quer dizer que iniciar o serviço de um agrupamento (cluster) criado na 9.3 com os binários da 9.6 não vai funcionar.
- online: o serviço precisa estar em execução para executarmos a cópia de segurança;
- seletiva: você pode escolher o banco de dados a ser copiado (inclusive pode optar por excluir alguns objetos ou dados de tabelas);
- compatível: pode haver compatibilidade entre versões utilizadas para cópia e restauração (algumas instruções podem se tornar obsoletas em versões novas ou não existirem em versões antigas). Além disso, podemos restaurar em plataformas (hardware e sistema operacional) diversas ou até mesmo em SGBDs que utilizam a linguagem SQL (provavelmente com algumas correções nas instruções).
- perda de dados: na cópia lógica, e no pior caso (considerando um cenário de cópia de segurança 1 vez ao dia), podemos ter perda de 24 horas de dados porque não há cópia incremental. Na cópia física, a perda de dados é menor já que há cópia das mudanças (logs de transação) ao longo do dia (existem técnicas para ter perda zero ou próximo disso);
- uso de recursos: em ambos os casos haverá uso intenso de I/O durante a cópia, o que pode tornar a operação lenta nesse período. No entanto, na cópia física, somente a cópia base (primeira cópia) é lenta pois precisa copiar tudo; as cópias subsequentes podem copiar somente aqueles arquivos que mudaram;
- eficiência: na cópia lógica, deve-se copiar tudo; não há possibilidade de copiar somente o incremento (a janela de perda de dados aumenta até que façamos outra cópia lógica). Além disso, se uma cópia lógica falha ou é interrompida durante a execução, não há a possibilidade de reinício a partir daquele ponto. Na cópia física, fazemos a cópia base e a partir daquele ponto copiamos somente os incrementos (minimizando a perda ao longo do tempo). Podemos retomar do ponto onde paramos, evitando uma nova cópia base;
- inflexível: na cópia lógica é possível selecionar quais objetos farão parte da cópia de segurança (a restauração também pode ser seletiva). Na cópia física, não há possibilidade de selecionar determinados bancos de dados ou mesmo objetos a serem restaurados; deve-se restaurar tudo e depois proceder com a exclusão daquilo que não é de interesse.
- tamanho: para cópia lógica, quanto maior o cluster mais horas levará para copiar as instruções SQL. Essa lentidão pode ocasionar problemas operacionais (por exemplo, inchaço de datafiles e bloqueio de DDLs). Na cópia física, a cópia base pode demorar mas não vai ocasionar problemas operacionais (exceto alta taxa de I/O). Em um agrupamento (cluster) que tenha tamanho na casa das centenas de gigabytes, a cópia física tende a ser mais rápida do que a cópia lógica (não há necessidade de ler dados e formatá-los em um instrução SQL);
- objetos globais: na cópia lógica, informações globais (tais como roles e tablespaces) não são copiadas. É necessário utilizar o pg_dumpall para copiar tais informações. São informações que podem ser importantes para o negócio e, portanto, precisam ser copiadas também. Na cópia física, como todos os datafiles são copiadas as informações são mantidas idênticas na cópia de segurança.
- perda de dados pode ser inaceitável para negócio. Perder um dia de trabalho pode ocasionar sérios problemas operacionais na empresa;
- você terá acesso aos dados em um determinado ponto no tempo: o momento que iniciou a cópia lógica. Isso quer dizer que se a cópia demorou 14 horas e após o término o serviço apresentou problemas, a cópia de segurança estará defasada em 14 horas!
- a falha de uma cópia de segurança pode forçar a execução da rotina durante o expediente que, por sua vez, pode ocasionar muita lentidão ao acessar os dados;
- fazer cópia lógica em um agrupamento (cluster) com mais de 1 TB pode demorar dezenas de horas (sim, dias). Trocando em miúdos, lentidão por alguns dias;
- objetos globais são importantes (por exemplo, propriedades e senhas de roles). Certifique-se que faça a cópia deles ao realizar a cópia lógica.
- a perda de dados seria de algumas transações ou mesmo perda (próximo de) zero. Seria uma perda máxima controlada pelo DBA;
- com uma cópia base de 01/01/2016 e todos os logs de transação do ano de 2016 seria possível restaurar o estado do banco a qualquer ponto no tempo no ano de 2016. Isso quer dizer que se alguém removeu um registro em 07/08/2016 é possível que eu restaure o estado do banco de dados antes da remoção e recupere os dados excluídos;
- os servidores de homologação e testes podem ser gerados (automaticamente) a partir de uma cópia física de x dias atrás;
- caso a cópia base esteja inconsistente, você poderá utilizar uma anterior desde que tenha os logs de transação a partir daquela cópia base anterior;
- a cópia base pode demorar dias mas, uma vez feita, você pode optar por fazer cópias incrementais nela para agilizar a cópia física. Como os incrementos são copiados ao longo do dia, eu não preciso me preocupar com o tempo gasto para copiá-los.
- extrair dados de uma tabela no mês passado não importando a data/hora exata para recuperação;
- extrair dados de algumas tabelas para dar carga em outro SGBD;
- recuperar um banco de dados cuja cópia de segurança é da versão 7.0.
Até a versão 7.4, a cópia física não era tão difundida porque não era possível fazê-la online. Além disso, ela não era incremental. A partir da versão 8.0, foram implementados os conceitos de arquivamento de logs de transação e PITR (Point In Time Recovery). Na versão 8.2, houveram inúmeras melhorias para cópia física incluindo adição de um parâmetro (archive_timeout) para controlar o tempo de perda máximo (RPO, Recovery Point Objective). Na versão 9.1, o pg_basebackup foi implementado para facilitar a execução de cópias base (utilizando o próprio protocolo do postgres) antes disso um programa ou script seguindo os passos da cópia base deve ser utilizado. Na versão 9.2, o pg_receivexlog foi implementado (ele usa streaming) para ser uma alternativa ao arquivamento e manter uma perda menor ainda (na versão 9.5 é possível configurá-lo síncrono, tornando a perda zero).
Antes que alguém pergunte, há outras soluções de cópia física como o pgBarman e pgBackRest que não fazem parte do PostgreSQL mas que são mantidos por membros da comunidade. Contudo, isso é assunto para um outro artigo ...
No comments:
Post a Comment