recovery.conf es el fichero que creamos cuando se quiere recuperar una base de datos a partir de un backup base y en él especificamos parámetros tan importantes como por ejemplo restore_command y recovery_target_time/recovery_target_name.
El servidor, al iniciar, detecta la existencia de este fichero, entiende que debe iniciar una recuperación, y de los parámetros obtiene la ubicación de los ficheros WAL archivados y el punto hasta el que debe recuperar.
Una vez finalizada la recuperación el fichero pasa a llamarse recovery.done lo que nos garantiza, entre otras cosas, que se evite que un nuevo reinicio del servidor inicie una recuperación no deseada.
Actualizando a PostgreSQL 12 estamos diciendo adiós al fichero recovery.conf y dando la bienvenida al fichero recovery.signal… pero no es sólo un cambio de nombre.
recovery.signal no sustituye a recovery.conf en todas sus funciones, su existencia sólo indica al servidor que debe iniciar una recuperación que, cuando ésta termina, es eliminado y deja parte del protagonismo al fichero postgresql.auto.conf, que editaremos para incluir en él, los parámetros de recuperación.
En este artículo te explico con detalle las diferencias a la hora de realizar recuperación Point-In-Time-Recovery entre versiones de PostgreSQL anteriores a la 12 y versiones de PosgreSQL a partir de la 12.
Los backups no se ven afectados por este cambio, tan sólo afectan a la tarea de recuperar.
Primero. Repartimos las funciones de recovery.conf y nos olvidamos de él.
La función de bandera que tenía recovery.conf la tendrá ahora el fichero recovery.signal.
Este fichero lo crearemos, sin contenido, para avisar a nuestro servidor PostgreSQL que deseamos entrar en modo recuperación.
Una vez finalizada la recuperación, recovery.signal será automáticamente eliminado.
La función de contenedor de los parámetros de recuperación que tenía recovery.conf recae sobre el fichero postgresql.conf
Aquí puedes ver el nuevo bloque de parámetros que postgresql.conf dedica a los parámetros de recuperación:
# – Archive Recovery –
# These are only used in recovery mode.
#restore_command = » # command to use to restore an archived logfile segment
# placeholders: %p = path of file to restore
# %f = file name only
# e.g. ‘cp /mnt/server/archivedir/%f %p’
# (change requires restart)
#archive_cleanup_command = » # command to execute at every restartpoint
#recovery_end_command = » # command to execute at completion of recovery
# – Recovery Target –
# Set these only when performing a targeted recovery.
#recovery_target = » # ‘immediate’ to end recovery as soon as a
# consistent state is reached
# (change requires restart)
#recovery_target_name = » # the named restore point to which recovery will proceed
# (change requires restart)
#recovery_target_time = » # the time stamp up to which recovery will proceed
# (change requires restart)
#recovery_target_xid = » # the transaction ID up to which recovery will proceed
# (change requires restart)
#recovery_target_lsn = » # the WAL LSN up to which recovery will proceed
# (change requires restart)
#recovery_target_inclusive = on # Specifies whether to stop:
# just after the specified recovery target (on)
# just before the recovery target (off)
# (change requires restart)
#recovery_target_timeline = ‘latest’ # ‘current’, ‘latest’, or timeline ID
# (change requires restart)
#recovery_target_action = ‘pause’ # ‘pause’, ‘promote’, ‘shutdown’
# (change requires restart)
Los parámetros más comúnmente usados serían primary_conninfo, restore_command y recovery_target_time o recovery_target_name.
Puedes pensar que es lógico que los parámetros estén en postgresql.conf y no en un fichero aparte (recovery.conf) o que tiene sentido que los parámetros de recuperación estén en un fichero que existirá sólo si se va a llevar a cabo una recuperación y por lo tanto, que estén permanentemente en postgresql.conf es innecesario.
Para gustos colores.
El caso es que así era antes, y así es ahora. Lo cierto es que si no estamos en modo recuperación (o lo que es lo mismo, que recovery.signal no existe) esos parámetros sin ignorados por el servidor.
Sigamos…
Segundo. El parámetro standby_mode desaparece.
Servía para indicarle al servidor si tenía que entrar en modo recuperación o en modo standby. Ahora, si queremos que entre en modo standby, en lugar de crear el fichero recovery.signal crearíamos el fichero standby.signal por lo que mantener dicho parámetro sería redundante.
Tercero. Curiosidades.
El fichero postgresql.auto.conf sigue avisando de que:
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
Sin embargo lo editaremos para incluir los parámetros y sus valores tal y como lo haría el comando ALTER SYSTEM.
La opción -R de pg_basebackup sigue llamándose
-R, –-write-recovery-conf
pero con distinta interpretación. Observa la descripción anterior y la actual::
-R, –-write-recovery-conf, escribe recovery.conf para replicación (PostgreSQL <12)
-R, –-write-recovery-conf, escribe configuración para replicación (PostgreSQL 12+)
Este tipo de recuperaciones se utilizan cuando se hacen backups continuos en bases de datos PostgreSQL que son, a su vez, el único tipo de backup que permite recuperaciones hasta un punto determinado en el tiempo (técnica que se conoce con el nombre de PITR, Point In Time Recovery).
En el curso online Administración PostgreSQL: Técnicas de Backup y Recuperación se explica en profundidad esta técnica, tanto para versiones de PostgreSQL anteriores a las 12, como para versiones de la 12 en adelante.
El siguiente video es una clase teórica del curso y en él se explica en qué consiste el Archivado Continuo (WAL Archiving) y las recuperaciones Point In Time Recovery.