One of the utilities that walctl includes is a script dedicated to creating a copy of the source database. Why don't we just use pg_basebackup? When dealing with large databases common to high availability systems, we want to copy as little data as possible. The pg_basebackup utility is a great basic tool, but it always copies every file. The walctl_clone program that we use in this recipe relies on rsync.
Of course, this raises another question: why not just use rsync directly? Due to its extensive capabilities, rsync is inherently dangerous. Did you accidentally transpose the source and target destination parameters? If you did so, you've just erased or corrupted your database master. The walctl_clone tool wraps rsync in such a way that it can only retrieve data from a master node. We can stay safe by limiting its use to clone servers.
In this recipe, we'll introduce and invoke the walctl_clone command, which does a few other useful things on our behalf. Not only does it copy the database files, it creates a recovery.conf to retrieve WAL files from a remote archive and starts the PostgreSQL server. There isn't much manual work involved. Let's try it out!
This recipe depends on walctl being installed on both a primary server and the clone that we will use. Please follow the Installing and configuring walctl recipe before continuing.
For this recipe, we only care about two servers. The primary PostgreSQL server is pg-primary, and the new standby will be pg-clone. Execute this command as the postgres system user on the pg-clone server:
walctl_clone pg-primary walctl
When the command finishes, we should have a fully operational clone of pg-primary.
It may seem impossible that such a simple command can clone an entire database. Yet, in the previous recipe, we wrote a configuration file, and that's all walctl needs to operate. The walctl_clone command only has two parameters: the hostname of the database we are cloning and the name of the database superuser necessary to invoke a backup. Given these settings, walctl_clone performs a number of actions on our behalf:
- Puts the master node into backup mode.
- Retrieves all files from the database. If data files already exist in the
PGDATAdirectory, it only copies changed files. - Ends backup mode on the master node.
- Creates a
recovery.conffile that will continuously retrieve files frompg-arcand connect as a streaming standby topg-primary. - Starts the PostgreSQL server.
We can't think of any other PostgreSQL clone utility that is as easy to use. This is important when maintaining a high availability cluster, because simplicity prevents accidents.