Using PostgreSQL in enterprise environments gets more and more popular. And why not? This extremely stable and performant database can compete with ease with almost all enterprise database installations out there today.
Competing technically? Sure!
Competing from a business perspective? Absolutely!!
Making sure your database systems stay up during planned maintenance? Absolutely yes, no discussion about that!
Ensuring your systems stay up during a catastrophic failure of your master? Yes! We need to ensure 99.99999 availability.
Introducing EDB Failover Manager (or short: EFM).
A tool that will do precisely this.
- A graceful switch-over from a master database to a slave database (and back) with just one single command. This way you have the chance to do maintenance on the (previously master) node.
- Failover from a master node to a slave node (which will be promoted to new master).
It is based on PostgreSQL streaming replication, which allows you to create multiple slave clusters to your master cluster.
The tool ensures access to the cluster of database clusters using a Virtual IP Address. It gives you a wealth of ‘hooks’, where you can call scripts to help you reconfigure you surrounding landscape to a switch of masters. Think of re-configuring your load-balancing tools, like Pgpool-II to make sure read and write queries get assigned to the correct cluster nodes.
Well, that sounds good, right!
So, what do you need to do?
- Make sure your PostgreSQL streaming replication is running.
- Allocate at least 3 nodes (master/slave/slave or master/slave/witness). You will need three nodes to have a quorum to prevent a split brain scenario.
- Install EFM on those 3 nodes and configure it.
- Start, run and play!
Configuration of EFM is done through
efm.properties in the
Tip is to create 1 copy of this file and distribute this over you EFM cluster nodes. There are respectively one (master/slave/slave configuration) or two (master/slave/witness configuration) parameters that are node-specific.
bind.address: specific to each node,
<node IP-address>:9001(9001 is cluster communication port, same for all cluster members)
is.witness: put this parameter to true if the node hold no database.
All other parameters are well documented in the
<IP-address>:9001 of the membership coordinator (basically the first node of the EFM-cluster you start), in the
efm.nodes-file of all the cluster members.
With this, we are basically good to go!!
systemctl start efm-2.1 and your cluster is running!
The efm-command allows you to manage your cluster. Syntax for the command is:
efm <command> <cluster-name> <option>.
efm cluster-status efmgives you a nice overview of what is happening. Precede this with the linux
watchcommand and you can monitor this nicely.
efm allow-node efm pg-11allows node pg-11 to join the EFM cluster
efm promote efm -switchovermakes the first slave in the standby priority list the new master and converts the precious master to slave
efm set-priority efm pg-10 1makes node pg-10 the first node in the standby priority list
-bash-4.2$ watch efm cluster-status efm# Every 2.0s: efm cluster-status efm Sun Aug 27 10:02:49 2017 Cluster Status: efm VIP: 192.168.56.10 Agent Type Address Agent DB Info -------------------------------------------------------------- Master pg-10 UP UP Standby pg-11 UP UP Standby pg-12 UP UP Allowed node host list: pg-10 pg-11 pg-12 Membership coordinator: pg-10 Standby priority host list: pg-11 pg-12 Promote Status: DB Type Address XLog Loc Info -------------------------------------------------------------- Master pg-10 0/AB0000D0 Standby pg-11 0/AB0000D0 Standby pg-12 0/AB0000D0 Standby database(s) in sync with master. It is safe to promote.
For troubleshooting and checking purposes, there are very informative logs in
EFM truely is a very nice tool to add resilience and flexibility to your PostgreSQL database cluster configuration..