Início / dba / Perguntas / 133144
Accepted
John K. N.
Asked: 2016-03-24 05:36:52 +0800 CST

PostgreSQL Write Ahead Logs Modo de arquivamento

  • 772

Estou tentando descobrir várias coisas em torno do PostgreSQL e como os backups devem funcionar em conjunto com o WAL e o Commvault Simpana. Simpana está me dizendo que está tudo bem, mas deixa arquivos espalhados no diretório WAL Archive.

Deixe a viagem começar.

Meio Ambiente

PostgreSQL e versão do sistema operacional

O PostgreSQL 9.3 está sendo executado em um servidor Ubuntu 14.04.3 LTS.

Postgres WAL Config

O arquivo postgres.conf é definido da seguinte forma para arquivamento WAL.

#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#wal_level = minimal                    # minimal, archive, or hot_standby
wal_level = archive

[...]

# - Archiving -
archive_mode = on
#archive_mode = off             # allows archiving to be done
                                # (change requires restart)
archive_command = 'cp %p /pgsql-backup/archive/postgres1/%f'
                                # command to use to archive a logfile segment
                                # archive_command = ''           
                                # command to use to archive a logfile segment
                                # placeholders: %p = path of file to archive
                                #               %f = file name only
                                # e.g. 'test ! -f /mnt/server/archivedir/%f    && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0            # force a logfile segment switch after this
                                # number of seconds; 0 disables

Se a test ...peça for deixada no meio archive_command, quebra o backup do Simpana, por isso o omitimos.

A configuração acima deve resultar na cópia dos arquivos WAL do /pg_xlog/diretório para o /pgsql-backup/archive/postgres1/diretório, quando ...

  1. não é mais necessário, devido a um pg_basebackup
  2. um arquivo WAL está cheio (padrão 16 MB) e não está mais em uso

Commvault Simpana

O computador cliente foi configurado para que os bancos de dados/instância PostgreSQL e os arquivos WAL no diretório Archive Log sejam copiados. Os arquivos WAL devem ser excluídos quando não forem mais necessários, porque a opção 'Excluir arquivo' do Simpana foi definida para o cliente PostgreSQL.

Comportamento esperado

Como o Simpana está executando o backup com comandos nativos do PostgreSQL, espero que, quando o Simpana concluir um backup completo ou um backup do WAL, os arquivos no /pgsql-backup/archive/postgres1/diretório sejam excluídos.

Comportamento eficaz

Quando eu verificar o /pgsql-backup/archive/postgres1/diretório após o Simpana ter feito um backup, haverá mais um arquivo no diretório com uma 0000000300000037000000nn.mmmmmmmm.backupsintaxe. Isso é uma dica de que o Simpana está fazendo um backup usando comandos nativos do PostgreSQL, pois um 0000000300000037000000nn.mmmmmmmm.backuparquivo só seria criado após um backup PostgreSQL do banco de dados/instância usando pg_basebackup. Esta é apenas a minha conclusão depois de ler a documentação do PostgreSQL 9.3.

Aqui está um exemplo do conteúdo do diretório:

[...]
00000003000000370000007A
00000003000000370000007B.00000028.backup
000000030000003700000091.00000028.backup
000000030000003700000093.00000028.backup
000000030000003700000095.00000028.backup
000000030000003700000097.00000028.backup
000000030000003700000099.00000028.backup
00000003000000370000009B.00000028.backup

Documentação do PostgreSQL

A documentação oficial afirma que

Para fazer uso do backup, você precisará manter todos os arquivos de segmento WAL gerados durante e após o backup do sistema de arquivos. Para ajudá-lo a fazer isso, o processo básico de backup cria um arquivo de histórico de backup que é imediatamente armazenado na área de arquivo do WAL. Esse arquivo recebe o nome do primeiro arquivo de segmento WAL necessário para o backup do sistema de arquivos. Por exemplo, se o arquivo WAL inicial for 0000000100001234000055CD, o arquivo de histórico de backup será nomeado como 0000000100001234000055CD.007C9330.backup. (A segunda parte do nome do arquivo representa uma posição exata dentro do arquivo WAL e normalmente pode ser ignorada.) Depois de arquivar com segurança o backup do sistema de arquivos e os arquivos de segmento WAL usados ​​durante o backup (conforme especificado no histórico de backup Arquivo), todos os segmentos WAL arquivados com nomes numericamente inferiores não são mais necessários para recuperar o backup do sistema de arquivos e podem ser excluídos. No entanto, você deve considerar manter vários conjuntos de backup para ter certeza absoluta de que pode recuperar seus dados.

Isso prejudica minha conclusão de que o Simpana está usando os comandos nativos do PostgreSQL para fazer backup do banco de dados/instância e de seus arquivos de log do WAL Archive no diretório /pgsql-backup/archive/postgres1/.

De acordo com a documentação, um arquivo nnnnnnnnnnnnnnnnnnnnnn.mmmmmmmm.backup é um ponteiro para o arquivo WAL mais antigo necessário para que uma recuperação rollforward seja bem-sucedida. Quaisquer arquivos WAL mais antigos no diretório Archive Log podem ser excluídos e não são mais necessários.

O que me surpreende é que há um arquivo WAL no diretório Archive Log sem um arquivo apontador *.mmmmmmmm.backup correspondente.

Perguntas

  1. Se eu não estivesse usando o Simpana para o backup, quem (teria que) deletar os arquivos *.mmmmmmmm.backup no diretório WAL Archive? O pg_archivecleanupcomando?
  2. Por que ainda há um arquivo WAL completo no diretório Archive Log, quando ele deveria ter sido excluído como todos os outros arquivos WAL no diretório Archive Log?
  3. Por que não há um 00000003000000370000007A.mmmmmmmm.backuparquivo para o arquivo WAL ainda existente 00000003000000370000007Ano diretório de log do arquivo?

Aguardo suas respostas e espero que alguém tenha uma configuração semelhante de Simpana e PostgreSQL em algum lugar por aí.

postgresql backup

3 respostas

  1. Temos o mesmo problema com o backup postgres do Simpana. A documentação afirma:

    Quais são todos os arquivos cujo backup é feito como parte dos backups somente de log? Somente os arquivos de log de transação relevantes para o ciclo de backup atual são copiados. Não será feito backup de todo o conteúdo do diretório de log. Por exemplo, se você executar um backup de log no horário T1 e posteriormente um backup completo (dados e log) no horário T2; os arquivos de log de transações gerados entre T1 e T2 não farão parte do backup completo mais recente, pois não são relevantes para o ciclo de backup atual. Além disso, os arquivos .backup, que são arquivos temporários criados pelo PostgreSQL Server como parte do arquivamento de log, não são copiados como parte dos backups de log. Como ocorre a limpeza do arquivo de log quando a opção Excluir arquivo está habilitada?

    Como ocorre a limpeza do arquivo de log quando a opção Excluir arquivo está habilitada? Com a opção Archive Delete habilitada, apenas os arquivos de log de transação cujo backup é feito como parte do backup de log são excluídos. Os arquivos de log de transações que não foram excluídos durante as tentativas anteriores de backup não são limpos. Além disso, devido ao arquivamento contínuo de arquivos de log de transações, você pode ver novos arquivos de log de transações no diretório WAL após backups de log bem-sucedidos. Portanto, os arquivos de log de transações que não fazem parte de nenhum backup de log, bem como os arquivos temporários criados pelo PostgreSQL Server, serão deixados para trás no diretório Log.

    Então: Se você não fizer um backup extra somente de log, logo antes do próximo backup completo; Todas essas paredes nunca são copiadas/excluídas; e pior: você nunca pode PITR para este período de tempo em caso de falha no disco.

    • 2
  2. Best Answer

    Esta parece ser fundamentalmente uma questão sobre o Commvault Simpana, não o PostgreSQL. Como o Commvault parece ser um software comercial, você pode ter mais sorte em entrar em contato com o suporte técnico.

    Comportamento esperado Como o Simpana está executando o backup com comandos nativos do PostgreSQL, espero que, quando o Simpana concluir um backup completo ou um backup WAL, os arquivos no diretório /pgsql-backup/archive/postgres1/ sejam excluídos.

    Não sei o que significa "um backup WAL" aqui. Essa é uma terminologia específica para Simpana? Significa apenas que os arquivos WAL em seu diretório de arquivo original foram copiados para algum armazenamento externo?

    Perguntas Se eu não estivesse usando o Simpana para o backup, quem (teria que) deletar os arquivos *.mmmmmmmm.backup no diretório WAL Archive? O comando pg_archivecleanup?

    Se você não estivesse usando o Simpana, usaria outra coisa. Não podemos dizer o que seria essa outra coisa - há muitas opções. Embora pg_archivecleanupseja um desses métodos, está começando a parecer bastante obsoleto nos dias de hoje. Se você deseja apenas manter seus arquivos WAL por tempo suficiente para que sejam armazenados com segurança (ou reproduzidos) em modo de espera, agora você deve usar "replicação de streaming" e, assim, acabar com o envio de logs.

    Ou você pode ter uma política para manter permanentemente o primeiro backup básico feito (imediatamente após inicializar seu banco de dados vazio) e todos os arquivos WAL arquivados desde então, para que você possa fazer uma recuperação pontual a qualquer momento no histórico de seu banco de dados.

    Por que ainda há um arquivo WAL completo no diretório Archive Log, quando ele deveria ter sido excluído como todos os outros arquivos WAL no diretório Archive Log?

    Parece-me que quando o Simpana decide limpar o arquivo, em vez de remover todos os arquivos WAL mais antigos do que o mais antigo atualmente necessário, ele exclui o intervalo de arquivos começando com aquele ainda necessário na última vez que fez uma limpeza, terminando no imediatamente anterior ao atualmente necessário.

    Se este for o caso, se um arquivo WAL foi arquivado pelo PostgreSQL logo após você ativar o arquivamento, mas antes de o Simpana ter sido ativado (ou antes de ter se orientado), esse arquivo nunca será removido.

    Por que não há um arquivo 00000003000000370000007A.mmmmmmmm.backup para o arquivo WAL 00000003000000370000007A ainda existente no diretório de log do arquivo morto?

    Se nenhum backup foi iniciado durante o período em que 00000003000000370000007A era o arquivo WAL ativo, nunca teria havido um arquivo 00000003000000370000007A.mmmmmmmm.backup em primeiro lugar.

    • 1

  3. WAL é a abreviação de Write Ahead Log. Você deve ativar o modo de arquivamento no PostgreSQL, se desejar proteger os dados de qualquer banco de dados crítico.

    Resumindo, o arquivamento é o processo de criar um backup de todas as transações que ocorreram no banco de dados para que você possa recuperar o banco de dados a qualquer momento.

    O que é arquivamento PostgreSQL WAL?

    Qualquer transação realizada no banco de dados é primeiro gravada em um arquivo WAL como redo logs no Oracle e, em seguida, aplicada aos arquivos de dados reais. À medida que você adiciona e modifica os dados nos bancos de dados, os arquivos WAL continuam sendo gerados. Em termos do PostgreSQL, copiar arquivos WAL gerados é chamado de arquivamento, que é usado para backup e recuperação, recuperação pontual e replicação do banco de dados.

    Etapas para ativar o arquivamento WAL no Postgres

    postgres=# show archive_mode;

 archive_mode

 off
(1 row)

postgres=# show archive_command;
 archive_command

 (disabled)
(1 row)

    Aqui estão as etapas completas para: Ativar o modo de arquivamento no PostgreSQL

    • 0

relate perguntas