Planned failover shifts a MySQL or MariaDB resource group to another Pacemaker node before maintenance, reducing the chance of an unplanned outage during patching or reboots.
Pacemaker typically manages the database as a resource group that includes a floating IP (such as ocf:heartbeat:IPaddr2) and a database service (such as systemd:mariadb). The pcs command pcs resource move applies a temporary location preference for the group and the cluster relocates the resources to the selected node.
The move preference persists until it is cleared in the cluster configuration and can override normal placement and recovery decisions. Clearing the constraint removes the manual preference but does not force a failback, and existing client sessions can drop during relocation so applications should reconnect through the floating IP.
Steps to perform a planned MySQL or MariaDB failover in Pacemaker:
- Confirm the cluster is online and has quorum.
$ sudo pcs status Cluster name: clustername Cluster Summary: * Stack: corosync (Pacemaker is running) * Current DC: node-01 (version 2.1.6-6fdc9deea29) - partition with quorum * Last updated: Thu Jan 1 05:39:41 2026 on node-01 * Last change: Thu Jan 1 05:39:33 2026 by root via cibadmin on node-01 * 3 nodes configured * 2 resource instances configured Node List: * Online: [ node-01 node-02 node-03 ] Full List of Resources: * Resource Group: db-stack: * db_ip (ocf:heartbeat:IPaddr2): Started node-01 * db_service (systemd:mariadb): Started node-01 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled - Identify the database resource group name.
$ sudo pcs status resources * Resource Group: db-stack: * db_ip (ocf:heartbeat:IPaddr2): Started node-01 * db_service (systemd:mariadb): Started node-01The resource group name is used with pcs resource move and pcs resource clear.
- Move the database group to the target node.
$ sudo pcs resource move db-stack node-02
The resource group relocation stops and starts MySQL or MariaDB on another node, which can drop existing client connections.
Related: How to move a Pacemaker resource
- Confirm the resource group is running on the target node.
$ sudo pcs status resources * Resource Group: db-stack: * db_ip (ocf:heartbeat:IPaddr2): Started node-02 * db_service (systemd:mariadb): Started node-02Repeat the check until all resources in the group show Started on the intended node.
- Perform maintenance on the original node that no longer hosts the database resource group.
Disruptive maintenance on the active node shown as Started for the database resources can interrupt service.
- Clear the move constraint.
$ sudo pcs resource clear db-stack
Clearing removes the manual placement preference, but the scheduler may keep the group on the current node until another relocation occurs.
Related: How to move a Pacemaker resource
- Confirm the cluster is healthy.
$ sudo pcs status Cluster name: clustername Cluster Summary: * Stack: corosync (Pacemaker is running) * Current DC: node-01 (version 2.1.6-6fdc9deea29) - partition with quorum * Last updated: Thu Jan 1 05:39:56 2026 on node-01 * Last change: Thu Jan 1 05:39:48 2026 by root via cibadmin on node-01 * 3 nodes configured * 2 resource instances configured Node List: * Online: [ node-01 node-02 node-03 ] Full List of Resources: * Resource Group: db-stack: * db_ip (ocf:heartbeat:IPaddr2): Started node-02 * db_service (systemd:mariadb): Started node-02 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
