PostgreSQL: Posso fazer pg_start_backup () em um banco de dados ao vivo, executando sob carga?

Nossa replicação estabelecida foi interrompida ("o segmento WAL solicitado já foi removido" durante o tempo de inatividade). Não podemos parar o mestre facilmente novamente.

Nós podemos fazer

1. pg_start_backup(),
2. rsync ${PGDATA}/ mestre para escravo,
3. pg_stop_backup()

... enquanto o postgresql mestre ainda está sob carga total? (Ou pg_start_backup()levará a

• fechaduras de mesa,
• Blocos de E / S,
• inconsistências,
• alarme de incêndio,
• resposta lenta db

Em outras palavras, pg_start_backup()afetará nossa aplicação?

pg_start_backupexecutará um ponto de verificação, como dezso observa. Isso tem um impacto, mas seu banco de dados executa pontos de verificação regularmente de qualquer maneira e deve fazê-lo para funcionar, para que eles claramente não sejam um problema para você. Um ponto de verificação antecipado significa que menos dados foram acumulados, o que significa que, se houver um ponto de verificação depg_start_backup impacto menor que o normal.

Onde você precisa se preocupar é o rsync ou equivalente pg_basebackup etapa . A E / S de leitura não será muito ruim, pois é seqüencial, mas provavelmente prejudicará significativamente o desempenho de E / S do banco de dados e também tenderá a empurrar dados quentes do cache de RAM em favor de menos de dados usados, causando a interrupção do cache à medida que os dados mais necessários são então lidos novamente.

Você pode usar nicee ioniceajudar 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é você concluir o backup e executarpg_stop_backup o sistema, o meu sistema está acumulando - como eu o entendo - ele não pode excluir, acumulando dívidas do ponto de verificação para um ponto de verificação GRANDE 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 dar ao luxo de fazer o backup durar para sempre, especialmente se você tiver tabelas de rotatividade muito altas.

No final, é difícil dizer se você pode usar com segurança pg_start_backupe pg_stop_backuppara backups quentes em seu ambiente. A maioria das pessoas pode, mas se você estiver próximo do que seu hardware pode fazer, tiver requisitos de tempo apertados, não puder arcar com o risco de uma paralisação e possuir tabelas de rotatividade muito altas e tabelas muito grandes, pode ser problemático .

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

Se você puder, pode valer a pena emitir um CHECKPOINTinstantâneo atômico do volume em que seu banco de dados está usando LVM, as ferramentas de sua SAN, EBS ou o que você estiver usando. Se você puder fazer isso, poderá copiar o instantâneo à vontade. Essa abordagem não é adequada para fazer um backup básico para PITR / espera quente / espera quente, mas é perfeitamente bom para uma cópia de backup estática e tem um impacto muito menor no sistema. Só é possível fazer isso se os instantâneos forem atômicos e todo o 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
• Disparar 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 de pg_stop_backup
• Copie os dados dos volumes de captura instantânea

Essencialmente, a idéia é reduzir quanto tempo o banco de dados deve atrasar seus pontos de verificação, analisando cada volume que você pode copiar quando quiser.

Esta é uma escavação grave, mas eu 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á acumulando o WAL, como eu o entendo, não pode excluir, acumulando dívida do ponto de verificação para um ponto de verificação GRANDE no final da execução do backup e está acumulando tabela e índice inchar porque não pode limpar linhas mortas. Portanto, você realmente não pode dar ao luxo de fazer o backup durar para sempre, especialmente se você tiver tabelas de rotatividade muito altas.

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

• (2 + ponto de verificação_completo_ratio) * pontos de ponto de verificação + 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 WAL

depois de iniciar "pg_start_backup ()", seus arquivos WAL serão rotacionados durante o backup. Quando o 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á inicializar até que você forneça o arquivo WAL "0000000x0000000B000000D0" (onde x é seu TimelineID ). Esse arquivo WAL é o mínimo necessário para a inicialização do sistema. Obviamente, com apenas esse arquivo, você perderá dados, pois o restante dos dados está localizado nos arquivos WAL que você não possui, mas pelo menos terá um mecanismo de banco de dados em funcionamento.

Portanto, você deve fazer o arquivamento do WAL ou salvar os arquivos WAL necessários, 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 interromper temporariamente a gravação de todos os seus clientes.

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

Então, 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 na pasta pg_xlog). Tudo correu bem, mas o tempo de inatividade era inevitável, é claro.