cancel
Showing results for 
Search instead for 
Did you mean: 

Where is my recovery.conf file in PostgreSQL v12?

EDB Team Member

Where is my recovery.conf file in PostgreSQL v12?

 

The short answer is: it’s gone.

 

With PostgreSQL v12,  “recovery.conf” is no longer valid. Even if someone were to create a recovery.conf file manually and keep it under the data directory, the server is not going to start and will throw the following error:

 

snapshot_1.png

The parameter “standby_mode =on”, which used to be the #1 parameter of the recovery.conf file has also been removed from PostgreSQL v12. Also, the “trigger_file” parameter name has been changed to “promote_trigger_file.”

 

Other parameters for recovery.conf are valid and can be written in the “postgresql.conf” file of the slave cluster.  

 

It actually makes more sense if all the required information is mentioned in one file—i.e.,  postgresql.conf—rather than creating and managing separate files.

 

“standby.signal”—which is an empty file—has replaced the recovery.conf file and the presence of this file will signal to the cluster to run in standby mode.

 

Step-by-Step guide to setting up Streaming Replication in PostgreSQL v12 and Failover

 

=======================================

  1. Make sure PostgreSQL v12 server is up and running, with only these two parameters modified in the postgresql.conf file of the master cluster:

 

snapshot_2 (1).png



archive_mode  = Whether to send Write-Ahead Logging (WAL) files for archive storage or not

archive_command = Where to send (i.e., location)

 

  1. Create a standby/slave using “pg_basebackup” with option -R: 

 

 

snapshot_3 (1).png


The “pg_basebackup” utility is used to take the backup online.

 

There is an alternative method as well, where we can fire “select pg_start_backup('My backup..');” in the master cluster to start the online backup, and then using cp command take the backup and later fire  “select pg_stop_backup();” to signal to the master server that online backup is finished. But again, manual intervention is required—i.e. you need to remove the “postmaster.pid /create recovery.conf” file (or in PostgreSQL v12, create standby.signal) in slave directory—so it’s better to use only “pg_basebackup,” which takes care of everything.

 

Option -R will create an empty file with the name “standby.signal.”

snapshot_4 (1).png

  1. Contents of the old “recovery.conf” file (taken from PostgreSQL v10):

   snapshot_5 (1).png                     

 

If you just copy all the above parameters in the postgresql.conf file of slave cluster, the server is going to throw this error: 


snapshot_6 (1).png

 

As the “standby_mode” parameter is no longer supported and “trigger_file” has been renamed to “promote_trigger_file,” the server failed to start. Just correct both of these and the server will start. 


snapshot_7 (1).png


  1. Verify SR setup is properly working:


snapshot_8 (1).png

 

  1. Perform Failover :

There are multiple ways to do this:

  1. a) Shut down the master and promote standby.
  2. b) Shut down the master and touch the file that we mentioned in the “promote_trigger_file parameter” of postgresql.conf,  in step 3 above.

 

In this case, using option b: 


snapshot_9 (1).png

The “standby.signal” file is gone from the slave/data directory. Slave is now the new master and able to perform DDL operations.


snapshot_10 (1).png

1 Comment
Adventurer

Thanks for the information.its so useful