It's always considered good practice to test a failover procedure to prove that it functions as designed. There are a lot of moving parts in the cluster design discussed in this chapter, and an errant setting in PostgreSQL, repmgr, SSH, the VIP, network hardware, or any number of other influences can impact automation.
Testing helps reveal potential problem areas in a procedure, demonstrates average event durations, and serves as practice for when unexpected outages actually occur. The easiest way to test a cluster is to stop PostgreSQL on the primary server, which should trigger repmgr on other nodes to hold an election and promote the standby.
This recipe will demonstrate a simple failover procedure caused by stopping PostgreSQL, but also more advanced techniques to test operation during a network outage.
