Como posso forçar uma mesclagem de todos os arquivos WAL em pg_xlog de volta ao meu diretório “data” base?

Question

Pergunta:

Existe uma maneira de dizer ao Postgres (9.2) para "mesclar todos os arquivos WAL em pg_xlog de volta nos arquivos de dados não-WAL, e então apagar todos os arquivos WAL mesclados com sucesso?"

Eu gostaria de poder "forçar" essa operação; ou seja, checkpoint_segments ou configurações de arquivamento devem ser ignoradas. O diretório do buffer do WAL do sistema de arquivos ( pg_xlog ) deve ser esvaziado ou quase esvaziado. Tudo bem se algum ou todo o espaço consumido pelo diretório pg_xlog for consumido pelo diretório de dados; nosso DBA solicitou backups de banco de dados de arquivos (ou seja, diretório de dados, em vez de sql) sem nenhum WALs com backlog, mas o consumo de espaço não é uma preocupação.

Ter uma atividade WAL próxima a zero durante essa operação é uma boa restrição. Posso garantir que o servidor de banco de dados seja desligado ou não conectável (carga de transação gerada pelo usuário zero) durante esse processo.

Essencialmente, eu gostaria que o Postgres ignorasse temporariamente as políticas de retenção de arquivamento / verificação e liberasse toda a atividade do WAL para os arquivos do banco de dados, deixando pg_xlog no mesmo estado como se o banco de dados tivesse sido criado recentemente. Arquivos WAL.

O que eu tentei:

Eu sei que o utilitário pg_basebackup executa algo assim (ele gera uma cópia quase toda de WALs de um diretório de dados da instância do Postgres), mas ainda não estamos prontos para usá-lo em todos os nossos sistemas, como ainda estamos testando configurações de replicação; Eu estou esperando por uma solução mais a curto prazo.

Eu tentei emitir CHECKPOINT comandos, mas eles apenas reciclar um arquivo WAL e substituí-lo por outro (isto é, se eles fazem alguma coisa, se eu emiti-los durante o tempo ocioso do banco de dados, eles não fazem nada). pg_switch_xlog() da mesma forma apenas força um comutador para o próximo segmento de registro; ele não libera todos os segmentos enfileirados / armazenados em buffer.

Eu também joguei com o utilitário pg_resetxlog . Esse tipo de utilitário faz o que eu quero, mas todos os seus documentos de uso parecem indicar que ele destrói (em vez de limpar o log de transações e os arquivos de dados principais) alguns ou todos os dados do WAL. Essa impressão é exata? Se não, posso usar pg_resetxlog durante um período de atividade zero-WAL para forçar um flush de todos os dados WAL na fila para dados não WAL? Se a resposta for negativa, como posso alcançar esse objetivo?

Obrigado!

    

Answer 1

. . algo me diz que seu DBA não é um cara do Postgres? : -)

Com base nos seus comentários, parece que o mais próximo da solução que você está procurando é inicializar o banco de dados (usando seu backup básico) e emitir um CHECKPOINT , depois desligar esse banco de dados e fazer o backup. Isso irá liberar os dados do WAL nos logs de "catch-up" para os arquivos de banco de dados primários e deixar você com um WAL "vazio" (embora você ainda tenha alguns segmentos pendurados necessários para iniciar o servidor & verificar consistência).

A única outra maneira de garantir que o backup que você está capturando tenha todos os dados liberados para os arquivos principais do banco de dados é desligar o banco de dados para fazer o backup.

Eu não aconselharia fazer um desses para backups estáticos, que é o que parece que você está fazendo. Apenas espere pelo backup criado pelo manual do Postgres, e se você precisar ativá-lo, inicie um servidor usando-o como faria normalmente no manual.

Honestamente não consigo pensar em uma razão válida para o que seu DBA está solicitando - O breve atraso de inicialização enquanto o Postgres reproduz os arquivos de log coletados depois que o comando pg_stop_backup() não vale fazer algo estranho e diferente em vez de seguir os procedimentos testados e comprovados no manual e a quantidade de testes que você precisaria fazer para verificar se qualquer novo procedimento que você venha a realizar é tão robusto quanto os procedimentos padrão, tornando-o uma opção pouco atraente IMHO.

Obviamente, o procedimento para escravos / streaming / hot-standby é um pouco diferente, novamente de acordo com o manual.
Se seu DBA realmente quiser um número mínimo de segmentos do WAL, sugiro a solução que eu uso:

• Um escravo é designado como o host de backup.
• Quando chega a hora do backup, desligamos o escravo e fazemos o backup do sistema de arquivos
• O escravo é iniciado quando terminamos o backup & geralmente alcança dentro de 15 minutos.

A recuperação desse backup é essencialmente a mesma que ativar um escravo - o escravo é inicializado e o arquivo acionador de recuperação é criado.

Existem alguns truques para configurar isto - nada que não esteja coberto no manual, mas obviamente você quer testar completamente.