PostgreSQL: Posso fazer pg_start_backup () ao vivo, executando db sob carga?

pg_start_backupirá realizar um checkpoint, como observa dezso. Isso tem um impacto, mas seu banco de dados executa pontos de verificação regularmente de qualquer maneira e deve fazê-lo para funcionar, então eles claramente não são um problema para você. Um ponto de verificação inicial significa que menos dados foram acumulados, o que significa que, se houver alguma coisa, um ponto de verificação pg_start_backupterá um impacto menor do que o normal.

Onde você precisa se preocupar é o rsync ou pg_basebackupetapa equivalente. A leitura de E/S não será tão ruim, já que é sequencial, mas ainda provavelmente prejudicará significativamente o desempenho de E/S do seu banco de dados e também tenderá a enviar dados quentes para fora do cache de RAM em favor de menos -used data, causando debulha de cache à medida que os dados mais necessários são lidos de volta.

Você pode usar nicee ionicepara ajudar a limitar o impacto de E/S (mas não o impacto do cache); no entanto, há um custo para isso. O backup levará mais tempo e, até que você conclua o backup e execute pg_stop_backup, seu sistema está - pelo que entendi - acumulando WAL que não pode excluir, acumulando dívida de ponto de verificação para um GRANDE ponto de verificação no final da execução do backup e acumulando tabela e índice inchar porque não pode limpar linhas mortas. Portanto, você realmente não pode permitir que o backup demore uma eternidade, especialmente se você tiver tabelas de churn muito altas.

No final, é difícil dizer se você pode usar com segurança pg_start_backupe pg_stop_backuppara backups dinâmicos em seu ambiente. A maioria das pessoas pode, mas se você estiver perto do limite do que seu hardware pode fazer, tiver requisitos de tempo apertados, não puder correr o risco de travar e tiver tabelas de churn muito altas, bem como tabelas muito grandes, pode ser problemático .

Infelizmente, você praticamente precisa testá-lo e ver.

Se puder, pode valer a pena emitir um CHECKPOINTinstantâneo atômico do volume em que seu banco de dados está, em vez de usar o LVM, as ferramentas de sua SAN, EBS ou o que você estiver usando. Se você puder fazer isso, poderá copiar o instantâneo quando quiser. Essa abordagem não é adequada para fazer um backup de base para PITR/warm standby/hot standby, mas é perfeitamente adequada para uma cópia de backup estática e tem um impacto muito menor no sistema. Você só pode fazer isso se seus instantâneos forem atômicos e todo o seu banco de dados, incluindo o WAL, estiver em um único volume.

Uma possibilidade que ainda não investiguei é combinar as duas abordagens. Ocorre-me que alguém poderia ( não testado e possivelmente errado e inseguro , ainda não sei):

• pg_start_backup
• Acionar instantâneos de todos os espaços de tabela, o datadir principal e o volume xlog
• pg_stop_backup
• Copie o WAL até o arquivo final depg_stop_backup
• Copie os dados dos volumes instantâneos

Essencialmente, a ideia é reduzir quanto tempo o banco de dados deve atrasar seus pontos de verificação, obtendo um ponto no tempo de cada volume que você pode copiar quando quiser.

Esta é uma escavação de túmulos, mas tenho que corrigir algo aqui.

A resposta anterior está afirmando:

Você pode usar nice e ionice para ajudar a limitar o impacto de E/S (mas não o impacto do cache); no entanto, há um custo para isso. O backup levará mais tempo e, até que você conclua o backup e execute o pg_stop_backup, seu sistema está - pelo que entendi - acumulando WAL que não pode excluir, acumulando dívida de ponto de verificação para um GRANDE ponto de verificação no final da execução do backup e acumulando tabela e índice inchado porque não pode limpar linhas mortas. Portanto, você realmente não pode permitir que o backup demore uma eternidade, especialmente se você tiver tabelas de churn muito altas.

Isso não é verdade. O sistema manterá o número de WAL informado em sua configuração (consulte a documentação online ). Então, basicamente, o maior valor entre:

• (2 + checkpoint_completion_ratio) * checkpoint_segments + 1
• wal_keep_segments

Vamos imaginar este caso:

• seu backup está demorando muito, pois há centenas de shows para copiar
• você tem uma pequena retenção WAL (checkpoint_segments para 3, por exemplo)
• você não configurou o arquivamento do WAL

depois de iniciar "pg_start_backup()", seus arquivos WAL serão girados durante o backup. Quando seu backup for concluído, você tentará restaurá-lo em outro mecanismo de banco de dados. O mecanismo no lançamento solicitará pelo menos o arquivo WAL gerado quando você emitiu "pg_start_backup()".

pg_start_backup 
-----------------
B/D0020F18
(1 row)

O banco de dados não aceitará a inicialização até que você forneça o arquivo WAL "0000000x0000000B000000D0" (onde x é seu TimelineID ). Este arquivo WAL é o mínimo necessário para o sistema inicializar. É claro que, com apenas este arquivo, você perderá dados, pois o restante dos dados está localizado nos arquivos WAL que você não possui, mas pelo menos você terá um mecanismo de banco de dados funcionando.

Portanto, você deve fazer o arquivamento do WAL ou deve salvar os arquivos necessários do WAL sozinho, mas o Postgresql não fará isso por você.

Quanto à minha experiência com o PostgreSQL, é uma operação relativamente segura, a menos que você tenha um grande impacto no desempenho naquele momento. Se você o tiver, é melhor pausar temporariamente a gravação de todos os seus clientes.

Eu tive apenas um caso crítico ao sincronizar meu mestre com o escravo sob carga e foi causado pelo OOM killer (sim, você realmente deveria desabilitar COMPLETAMENTE o OOM Killer nos nós do banco de dados, eu não sabia disso naquele dia).

Portanto, restaurei o banco de dados do backup noturno e dei ao postgres todos os segmentos WAL do diretório pg_archive para reprodução (apenas copiei-os para a pasta pg_xlog). Tudo correu bem, mas o tempo de inatividade era inevitável, é claro.