Início / dba / Perguntas / 30626
Accepted
jberryman
Asked: 2012-12-18 11:25:30 +0800 CST

Executando pg_dump em um servidor hot standby?

  • 772

Isenção de responsabilidade: admito que ainda não tentei isso, mas não tenho certeza se saberia se não estivesse funcionando corretamente, então gostaria de perguntar.

Eu gostaria de executar um trabalho de backup noturno (via pg_dumpall) de um servidor de espera ativa executando a replicação de streaming, para evitar colocar essa carga no primário. Eu só vi menção de algumas pegadinhas que as pessoas encontraram, por exemplo, aqui e aqui , mas 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 standby, quais configurações eu preciso e procedimento devo usar para fazer isso corretamente? por exemplo, devo interromper a replicação durante o backup?

postgresql replication

3 respostas

  1. Best Answer

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

    A única coisa que você realmente precisa observar é garantir que o modo de espera esteja atualizado e funcionando. Se o modo de espera perdeu sua conexão com o mestre e ficou muito para trás, você não quer fazer backup alegremente de um modo de espera desatualizado de três semanas.

    Você precisará permitir que o standby fique muito atrás do mestre durante o backup, pois, caso contrário, ele terá que cancelar sua pg_dumptransação para continuar reproduzindo o WAL. Consulte a documentação sobre hot standby , particularmente a seção "lidando com 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 recupere o atraso.

    • 25
    1. Fazemos backup em standby, está perfeitamente bem.
    2. Para evitar conflito de instrução cancelada durante o backup no sistema de espera, você precisa pausar a replicação no modo de espera usando SELECT pg_xlog_replay_pause();, em seguida, executar o backup, uma vez concluído, execute SELECT pg_xlog_replay_resume();para retomar a replicação. Lembre-se de que a execução dos comandos acima causará um atraso de recuperação no escravo, que pode ser muito grande, dependendo do tamanho do banco de dados. Além disso, leve em consideração o espaço que os segmentos WAL ocuparão, pois eles não serão repetidos 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 pausá-lo: SELECT pg_is_in_recovery().

    • 14

  3. Isenção de responsabilidade: funciona apenas até PG12 , PG13+ usa slots de replicação

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

    Quanto tempo está atrasando seu backup habitualmente. Certifique-se de que o nó mestre preserve todos os arquivos x_log necessários para retomar 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 para o escravo.

    • 0

relate perguntas