Como o PostgreSQL lida com os pontos de verificação no meio de um backup habilitado para WAL?

Em um PostgreSQL v9.0, tenho um sistema de arquivamento WAL funcionando. Portanto, o WAL arquiva um arquivo regularmente (quando 3 WAL são criados ou se um WAL tiver mais de 15 minutos).

Agora eu adiciono um pacote binário do diretório PG_DATA (excluindo o subdiretório pg_xlog). Para fazer isso, faço uma pg_start_backup(),cópia binária e a pg_stop_backup().

Acho que entendi muito bem o que estão fazendo pg_start_backup e pg_stop_backup, o primeiro faz um ponto de verificação e o último garante que o último arquivo WAL seja arquivado.

A partir da documentação oficial , podemos ver que, para a cópia de dados binários, devemos:

Execute o backup, usando qualquer ferramenta conveniente de backup do sistema de arquivos, como tar ou cpio (não pg_dump ou pg_dumpall). Não é necessário nem desejável interromper a operação normal do banco de dados enquanto você faz isso.

Então, eu estou bastante perplexo. Isso significa que um ponto de verificação pode ser executado enquanto fazemos a cópia. Eu vi muita documentação afirmando que o comando copy deveria permitir alterações de dados durante a cópia; eu estou bem com isso, simplesmente uma questão de encontrar a ferramenta certa. Mas minha pergunta é como o postgreSQL lidará com a recuperação com um conteúdo pg_data contendo alguns arquivos que são inconsistentes (alguns antes do ponto de verificação, outros depois)?

Ao reproduzir os logs de transações, o Postgresql poderá colocar todos esses arquivos no estado correto? Vi que criar tabelas e soltar operações são perigosas enquanto o backup está em execução. Não existem operações perigosas, como comandos a vácuo ? O pg_backup suspende as operações de vácuo? Devo fazer uma cópia do arquivo global / pg_control no final do processo de cópia binária? Devo usar um sistema de arquivos ativado por snapshot (como no xfs-freeze) para obter um processo de restauração mais rápido?

Vi que uma falha no script de backup não iniciará um pg_stop_backup automaticamente, então há uma chance de que meu estado de backup permaneça por um longo tempo (até que meus nagios telefonem para alguém em algum lugar para corrigir o pg_stop_backup ()). Portanto, se alguma coisa for diferente no PostgreSQL entre esses dois comandos, eu gostaria de conhecê-la, para entender qual o impacto que ela pode ter.

Esclareça-me, por favor.

Você perguntou:

como o postgreSQL lidará com a recuperação com um conteúdo pg_data contendo alguns arquivos inconsistentes.

pg_start_backup()verifique se o arquivo de dados é pelo menos tão novo quanto o ponto de verificação. Na recuperação, os logs são aplicados.

Se os dados forem antigos, o log irá atualizá-lo.

Se os dados forem novos, o log terá o mesmo conteúdo. Não há problema em escrevê-lo novamente.

Os dados nunca são mais novos que o log, porque os logs são gravados com antecedência (WAL).

Você perguntou:

... xfs-freeze...

xfs-freezeé semelhante pg_start_backup(), não é necessário um instantâneo. Você precisa de um gerenciador de volume para fazer isso.

Você perguntou:

... por que criar espaço de tabela e criar instruções de banco de dados não são suportadas se o WAL pode reproduzir tudo?

É suportado, apenas um pouco de pegadinha. Veja http://www.postgresql.org/docs/8.1/static/backup-online.html :

23.3.5 Ressalvas

Os comandos CREATE TABLESPACE são registrados no WAL com o caminho absoluto literal e, portanto, serão reproduzidos como criações de espaço de tabela com o mesmo caminho absoluto. Isso pode ser indesejável se o log estiver sendo reproduzido em uma máquina diferente. Pode ser perigoso, mesmo se o log estiver sendo reproduzido na mesma máquina, mas em um novo diretório de dados: a reprodução ainda substituirá o conteúdo do espaço de tabela original. Para evitar possíveis problemas desse tipo, a melhor prática é fazer um novo backup básico após criar ou eliminar espaços de tabela.