In this section, we will learn how to set up asynchronous replication quickly and easily. The goal is to set up a system that consists of two nodes.

Basically, most of the work has already been done for WAL archiving. However, to make it easy to understand, we will look at the entire process of setting up streaming because we cannot assume that WAL shipping is really already set up as needed.

The first thing to do is to go to the postgresql.conf file and adjust the following parameters:

wal_level = replica
max_wal_senders = 10         # or whatever value >= 2 
hot_standby = on             # in already a default setting

Just as we have done previously, the wal_level variable has to be adjusted to ensure that PostgreSQL produces enough transaction logs to sustain a slave. Then, we have to configure the max_wal_senders variable. When a slave is up and running or when a base backup is created, a WAL sender process will talk to a WAL receiver process on the client side. The max_wal_senders setting allows PostgreSQL to create enough processes to serve those clients.

Then, there's the hot_standby variable. Basically, a master ignores the hot_standby variable and does not take it into consideration. All it does is make the slave readable during WAL replay. So, why do we care? Keep in mind that the pg_basebackup command will clone the entire server, including its configuration. This means that if we have already set the value on the master, the slaves will automatically get it when the data directory is cloned.

After setting the postgresql.conf file, we can turn our attention to the pg_hba.conf file: just allow the slave to perform replication by adding rules. Basically, those rules are the same as we have already seen for PITR.

Then, restart the database server, just like you did for PITR.

Now, the pg_basebackup command can be called on the slave. Before we do that, make sure that the /target directory is empty. If we are using RPM packages, ensure that you shut down a potentially running instance and empty the directory (for example, /var/lib/pgsql/data):

pg_basebackup -D /target 
         -h master.example.com 
         --checkpoint=fast 
         --wal-method=stream -R 

Just replace the /target directory with your desired destination directory and replace master.example.com with the IP or DNS name of your master. The --checkpoint=fast parameter will trigger an instant checkpoint. Then, there is the --wal-method=stream parameter; it will open two streams. One will copy the data, while the other one will fetch the WAL, which is created while the backup is running.

Finally, there is the -R flag:

  -R, --write-recovery-conf     # write configuration for replication

The -R flag is a really good feature. The pg_basebackup command can automatically create the slave configuration. In old versions, it will add various entries to the recovery.conf file. In PostgreSQL 12 and higher, it will make the changes automatically to postgresql.conf:

standby_mode = on primary_conninfo = ' ...'

The first setting says that PostgreSQL should keep replaying WAL all of the time—if the whole transaction log has been replayed, it should wait for a new WAL directory to arrive. The second setting will tell PostgreSQL where the master is. It is a normal database connection.

After running the pg_basebackup command, the services can be started. The first thing we should check is whether the master shows WAL sender process:

[hs@zenbook ~]$ ps ax | grep sender 
17873 ? Ss 0:00 postgres: wal sender process 
                           ah ::1(57596) streaming 1F/E9000060 

If it does, the slave will also carry WAL receiver process:

17872 ? Ss 0:00 postgres: wal receiver process 
                                 streaming 1F/E9000060 

If those processes are there, we are already on the right track, and replication is working as expected. Both sides are now talking to each other and WAL flows from the master to the slave.