Esecuzione di pg_dump su un server hot standby?

Disclaimer: Devo ammettere che non l'ho ancora provato, ma non sono sicuro di sapere se non funzionava correttamente, quindi volevo chiedere.

Vorrei eseguire un processo di backup notturno (tramite pg_dumpall) da un server hot standby che esegue la replica di streaming, per evitare di caricare quel carico sul primario. Ho visto solo la menzione di alcuni Gotcha in cui le persone si sono imbattute, ad esempio qui e qui , ma una guida molto scarsa. Va bene se il backup è leggermente indietro rispetto al primario, purché sia ​​coerente (come dovrebbe essere).

Le mie domande sono:

1. Voglio davvero farlo, o devo fare il backup sul server primario? Perché?

2. Quando eseguo un dump in standby, quali impostazioni sono necessarie e quale procedura devo utilizzare per farlo correttamente? ad es. devo interrompere la replica per la durata del backup?

AFAIK, l'esecuzione pg_dumpsu hot standby è una delle cose principali per cui gli standbys sono utili. È perfettamente sicuro, sebbene non sia perfettamente affidabile: i dump possono fallire se lo standby interrompe la transazione quando è troppo indietro rispetto al master.

L'unica cosa che devi davvero guardare è assicurarti che lo standby sia aggiornato e sia al passo. Se lo standby ha perso la connessione con il master ed è rimasto troppo indietro, non si desidera eseguire il backup allegramente di uno standby non aggiornato di tre settimane.

Dovrai consentire allo standby di rimanere abbastanza indietro rispetto al master durante il backup, poiché altrimenti dovrà annullare la pg_dumptransazione per continuare a riprodurre WAL. Consultare la documentazione su hot standby , in particolare la sezione "gestione dei conflitti di query" e i parametri max_standby_archive_delaye max_standby_streaming_delay.

Si noti che il master deve essere disposto a mantenere un numero sufficiente di archivi WAL per consentire allo slave di recuperare.

1. Facciamo il backup in standby, va benissimo.
2. Per evitare conflitti di dichiarazione annullati durante il backup sul sistema di standby, è necessario mettere in pausa la replica in standby utilizzando SELECT pg_xlog_replay_pause();, quindi eseguire il backup, una volta terminata l'esecuzione SELECT pg_xlog_replay_resume();per riprendere la replica. Tenere presente che l'esecuzione sopra i comandi causerà un ritardo di recupero sullo slave, che potrebbe essere piuttosto grande, a seconda delle dimensioni del database. Inoltre, tenere conto dello spazio che i segmenti WAL occuperanno, poiché non verranno riprodotti sullo slave durante la pausa.

È possibile trovare alcune altre utili funzioni amministrative nella documentazione . Per esempio, controllare se il server è in realtà nel recupero, prima della pausa che: SELECT pg_is_in_recovery().

Se metti in pausa la replica durante il backup, (Questa è una buona idea per preservare l'integrità e la coerenza), puoi modificare alcune righe nel tuo postgresql master:

Quanto tempo ritarda abitualmente il backup. Assicurarsi che il nodo principale conservi tutti i file x_log necessari per riprendere la replica. Puoi farlo nella modifica di postgresql.conf

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

Se non si modifica questo e il processo di backup è troppo lungo, è probabile che il nodo master cancelli i file xlog prima di inviarli allo slave.