¿Ejecutas pg_dump en un servidor en espera activo?

Descargo de responsabilidad: Es cierto que todavía no lo he intentado, pero no estoy seguro de saber si no funcionaba correctamente, así que quería preguntar.

Me gustaría ejecutar un trabajo de copia de seguridad nocturno (vía pg_dumpall) desde un servidor en espera activo que ejecuta la replicación de transmisión, para evitar poner esa carga en el primario. Solo he visto mención de algunas trampas con las que la gente se ha encontrado, por ejemplo, aquí y aquí , pero muy poca orientación. Está bien si la copia de seguridad va un poco por detrás de la primaria, siempre y cuando sea consistente (que debería ser).

Mis preguntas son:

1. ¿Realmente quiero hacer esto, o la copia de seguridad se debe hacer en el servidor primario? ¿Por qué?

2. Al realizar un volcado en el modo de espera, ¿qué configuración necesito y qué procedimiento debo usar para hacerlo correctamente? Por ejemplo, ¿debo detener la replicación mientras dure la copia de seguridad?

AFAIK, ejecutar pg_dumpen un modo de espera activo es una de las principales cosas para las que los recursos en espera son útiles. Es perfectamente seguro, aunque no es perfectamente confiable: los volcados pueden fallar si el modo de espera cancela la transacción cuando se queda demasiado atrás del maestro.

Lo único que realmente necesita ver es asegurarse de que el modo de espera esté actualizado y se mantenga al día. Si el modo de espera perdió su conexión con el maestro y se retrasó demasiado, no querrá retroceder alegremente un modo de espera desactualizado de tres semanas.

Deberá permitir que el modo de espera se quede bastante atrás del maestro durante la copia de seguridad, ya que de lo contrario tendrá que cancelar su pg_dumptransacción para continuar reproduciendo WAL. Consulte la documentación en espera activa , en particular la sección "manejo de conflictos de consulta" y los parámetros max_standby_archive_delayy max_standby_streaming_delay.

Tenga en cuenta que el maestro debe estar dispuesto a mantener suficientes archivos WAL para permitir que el esclavo vuelva a ponerse al día.

1. Hacemos copias de seguridad en modo de espera, está perfectamente bien.
2. Para evitar el conflicto de la declaración cancelada durante la copia de seguridad en el sistema en espera, debe pausar la replicación en el uso en espera SELECT pg_xlog_replay_pause();, luego ejecutar la copia de seguridad, una vez que haya terminado de ejecutarse SELECT pg_xlog_replay_resume();para reanudar la replicación. Tenga en cuenta que ejecutar los comandos anteriores provocará un retraso de recuperación en el esclavo, que puede ser bastante grande, dependiendo del tamaño de su base de datos. Además, tenga en cuenta el espacio que ocuparán los segmentos WAL, ya que no se reproducirán en el esclavo durante la pausa.

Puede encontrar otras funciones administrativas útiles en la documentación . Por ejemplo, comprobar si el servidor es en realidad en la recuperación, antes de la pausa que: SELECT pg_is_in_recovery().

Si pausa la replicación durante la copia de seguridad (esta es una buena idea para preservar la integridad y la consistencia), puede editar algunas líneas en su postgresql maestro:

Cuánto tiempo demora habitualmente su copia de seguridad. Asegúrese de que el nodo maestro conserve todos los archivos x_log necesarios para reanudar la replicación. Puedes hacerlo en la edición postgresql.conf

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

Si no modifica esto y su proceso de copia de seguridad es demasiado largo, es probable que el nodo maestro borre los archivos xlog antes de enviarlos al esclavo.