Executando o pg_dump em um servidor em espera quente?

Isenção de responsabilidade: reconhecidamente não tentei isso ainda, mas não tenho certeza se saberia se não estivesse funcionando corretamente, por isso queria perguntar.

Gostaria de executar uma tarefa de backup noturno (via pg_dumpall) de um servidor em espera, executando a replicação de streaming, para evitar colocar essa carga no primário. Eu só vi menção de algumas dicas que as pessoas encontraram, por exemplo, aqui e aqui , mas com muito pouca orientação. Tudo bem se o backup ficar um pouco atrás do primário, desde que seja consistente (o que deveria ser).

Minhas perguntas são:

1. Eu realmente quero fazer isso ou o backup deve ser feito no servidor principal? Por quê?

2. Ao fazer um dump no modo de espera, que configurações e procedimentos são necessários e que devo usar para fazer isso corretamente? por exemplo, devo parar a replicação durante o backup?

AFAIK, rodar pg_dumpem modo de espera quente é uma das principais coisas para as quais os standby são úteis. É perfeitamente seguro, embora não seja perfeitamente confiável - os despejos podem falhar se o modo de espera interromper a transação quando estiver ficando muito atrás do mestre.

A única coisa que você realmente precisa assistir é garantir que o modo de espera esteja atualizado e continuando. Se o modo de espera perdeu a conexão com o master e ficou muito para trás, você não deseja fazer um alegre backup de um modo de espera desatualizado de três semanas.

Você precisará permitir que o modo de espera fique muito atrás do mestre durante o backup, pois ele precisará cancelar sua pg_dumptransação para continuar a reproduzir o WAL. Consulte a documentação no modo de espera ativa , particularmente a seção "Manipulando conflitos de consulta" e os parâmetros max_standby_archive_delaye max_standby_streaming_delay.

Observe que o mestre deve estar disposto a manter arquivos WAL suficientes para permitir que o escravo se recupere novamente.

1. Fazemos backup em modo de espera, está perfeitamente bem.
2. Para evitar conflitos de instruções canceladas durante o backup no sistema em espera, é necessário pausar a replicação no modo de espera usando e SELECT pg_xlog_replay_pause();, em seguida, execute o backup, assim que terminar de executar SELECT pg_xlog_replay_resume();para continuar a replicação. Lembre-se de que executar os comandos acima causará um atraso na recuperação do escravo, que pode ser bastante grande, dependendo do tamanho do banco de dados. Além disso, leve em consideração o espaço que os segmentos WAL terão, pois eles não serão reproduzidos no escravo durante a pausa.

Você pode encontrar outras funções administrativas úteis na documentação . Por exemplo, verifique se o servidor está realmente em recuperação, antes de congelar-lo: SELECT pg_is_in_recovery().

Se você pausar a replicação durante o backup (é uma boa idéia para preservar a integridade e a consistência), edite algumas linhas no seu postgresql mestre:

Quanto tempo está atrasando seu backup habitualmente. Certifique-se de que o nó principal preserve todos os arquivos x_log necessários para continuar a replicação. Você pode fazer isso na edição do postgresql.conf

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Se você não modificar isso e seu processo de backup for muito longo, é provável que o nó mestre apague os arquivos xlog antes de enviá-los ao escravo.