Instantâneos de armazenamento para backup consistente do postgresql - diferentes volumes de dados e log

Estamos executando muitas VMs do Linux em um ambiente de vmware / armazenamento compartilhado, cada uma executando sua própria instância do postgreSQL (uma mistura de 9.0 e 9.3). Atualmente, toda a VM fica em uma única partição / volume raiz e tivemos grande sucesso (~ 8 anos) usando instantâneos baseados em armazenamento dos volumes VMFS subjacentes para processo de backup / restauração (e replicação para o nosso site de recuperação de desastres).

Devido à arquitetura de nosso armazenamento, seria vantajoso separar os arquivos WAL do postgres em um volume não armazenado em cache, principalmente de gravação, para fornecer menos rotatividade de cache no lado do armazenamento. Com nosso armazenamento (Nimble Storage), podemos atribuir os dois volumes a um único grupo de proteção / captura instantânea, mas não pude deduzir ao nosso fornecedor que as capturas instantâneas ocorrerão EXATAMENTE ao mesmo tempo em todos os volumes no grupo de proteção - provavelmente sim, mas sempre há essa chance de que seus milissegundos se separem.

Para esse fim, realizamos algumas experiências, enquanto escrevíamos dados no banco de dados o mais rápido possível usando o pg_bench. Após os experimentos, restauramos nossos volumes de instantâneos e iniciamos o VM + postgres

• Faça um instantâneo dos volumes de dados e de log quase simultaneamente - resultado: banco de dados recuperado
• Volume de dados da captura instantânea primeiro, volume de log ~ 1 minuto depois - resultado: banco de dados recuperado
• Volume do log de instantâneo primeiro, volume de dados ~ 1 minuto depois - resultado: banco de dados recuperado
• Volume do log de instantâneo primeiro, volume de dados ~ 3 minutos depois, depois que um ponto de verificação do WAL gravou novos dados nos arquivos de dados: resultado: banco de dados recuperado

Portanto, o teste parece nos dizer, desde que os dois snapshots sejam consistentes no nível do volume e relativamente próximos, você obtenha uma cópia consistente do banco de dados, com base no tempo do snapshot do volume WAL / Log.

Minha pergunta: isso é seguro? Quais são os casos esquecidos que faltam em nossos testes e o que pode dar errado?

O documento do Postgres indica que isso não é seguro, mas o teste parece indicar sua robustez: http://www.postgresql.org/docs/9.1/static/backup-file.html

Se o seu banco de dados estiver espalhado por vários sistemas de arquivos, pode não haver maneira de obter instantâneos congelados exatamente simultâneos de todos os volumes. Por exemplo, se seus arquivos de dados e log WAL estiverem em discos diferentes ou se os espaços de tabela estiverem em sistemas de arquivos diferentes, talvez não seja possível usar o backup de captura instantânea porque as capturas instantâneas devem ser simultâneas. Leia a documentação do sistema de arquivos com muito cuidado antes de confiar na técnica de captura instantânea consistente nessas situações.

NOTA: Sim, conhecemos outras opções para garantir que elas sejam consistentes, como colocar o PostgreSQL no modo de backup ativo ou usar a integração VMware do nosso armazenamento para desativar as próprias VMs, mas estamos procurando uma solução exclusiva de armazenamento para velocidade, conveniência, e zero impacto para nossos clientes.

A documentação que você citou diz tudo, mas eu não culpo você se você quiser tentar verificar as reivindicações do fornecedor em relação a instantâneos tirados ao mesmo tempo. Talvez uma maneira de descobrir algo possa ser o teste de estresse do sistema WAL, mais especificamente.

Por exemplo, além de seus testes com base no pgbench, tente adicionar chamadas aleatórias pg_switch_xlog()para forçar a rotação do log, intervalos mais curtos e mais longos do ponto de verificação (encurtamento e alongamento checkpoint_timeoute checkpoint_timeout) e até mesmo usar tamanhos de arquivo wal pequenos ou grandes.

A menos que algo esteja faltando, para seus instantâneos não tirados ao mesmo tempo, eu atribuiria seus DBs recuperados talvez a um tempo de sorte. No último caso, imagine que você tirou o instantâneo do log enquanto o local atual do xlog era, digamos 0/A1C0FFEE,. Então você tem 3 minutos de carga particularmente pesada no sistema, que causa um ciclo completo nos arquivos WAL, e seu banco de dados está agora no momento em 0/DEADBEEFque o instantâneo de dados é obtido. Quando você tenta restaurar, os arquivos WAL que estão sendo gravados no momento do instantâneo de dados desaparecem há muito tempo e a recuperação falha.