As we're continuing to configure Corosync and Pacemaker, make sure you've followed all previous recipes.

For this recipe, we will use the same two PostgreSQL nodes: pg1 and pg2. Perform the following steps on either server as the root user:

This recipe differs from those in the previous sections in that we can execute these steps from any server. Commands issued by the crm utility are sent to the cluster itself, so any node will transmit them successfully, and Pacemaker will act accordingly. In the case of our configuration changes, the only action that Pacemaker takes is to alter its stored settings.

The first thing we do is disable STONITH by calling crm with the configure property parameter for stonith-enabled. While STONITH is an amusing acronym, there are actual devices on the market that fill this role. These devices can isolate a node from a network in several ways, and Pacemaker is designed to interact with them by default. As we don't have one right now, it's best to tell Pacemaker that it shouldn't expect such functionality.

Our next step includes shutting down our fledgling democracy by disabling quorum verification. We only have two nodes, and votes comprised of only two voters are entirely meaningless because they will always result in a tie. Without an odd number of nodes, no quorum (agreement) can be reached. This time, we configure property for no-quorum-policy and set it to ignore. This essentially means that the nodes will continue to vote, but we don't care unless they can reach a quorum. As two servers can't reach a quorum, resources will run where we tell them to run, and they have no say in the matter.

The last setting we change with configure property is default-resource-stickiness. As we mentioned earlier, Pacemaker is really built for transient services that act as independent agents. If an HTTP daemon moves from one node to another, nobody really cares or notices. If PostgreSQL acted in a similar manner, there would be several broken applications and irritated users.

By changing this setting to 100, we give every resource a default weight, so it sticks to whichever server it started on. Unless there's a crash or forced migration, it will stay there indefinitely.

Our last step is to view our handiwork by issuing crm with configure show. Pacemaker stores its configuration as XML, and while this is somewhat human readable, it's hardly concise. On our test cluster, it produces this output:

As we can see, both pg1 and pg2 are each labeled as a node. In addition, stonith-enabled, no-quorum-policy, and default-resource-stickiness are all set as we described in the recipe.

We're well on our way to building a Pacemaker cluster.

The crm command is actually a fully functional pseudo-shell. If executed without parameters, it presents a prompt and waits for valid crm commands. These commands include help for every level chosen. For example, to see what options are available when putting a node into standby, we can type this input while in a crm shell:

node help standby

Then, we can use what we learned previously and put the node into standby state until it is rebooted and Corosync is started again. Like this:

node standby pg1 reboot

This is extremely helpful as Pacemaker has a lot of commands, and it's easy to forget the proper syntax.