A MySQL Fabric instance is composed of a MySQL Fabric process together with a MySQL server. The MySQL Fabric node contains the protocols and the executor, but is in itself stateless in that if it for some reason crashes, re-starting permits it to continue where it left off. The configuration and state information about the farm is instead stored in a separate MySQL server.
To provide a highly available solution, both components must be redundant. From a failure viewpoint, these two components are treated as a single unit, meaning that each pair is collocated on a machine, and if one of them fails, the stack on that machine fails.
There are two MySQL Fabric instances working in active and stand-by mode. The data stored in the MySQL server is replicated through the Distributed Replicated Block Device, or simply DRBD. The MySQL Fabric process is stateless though and must simply be started in the stand-by node in the event of a failure.
Pacemaker and CoroSync are used to monitor whether the instances are running properly, and to automate the failover and switchover operations. Pacemaker is responsible for monitoring components, such as the MySQL Fabric Process, MySQL server, and DRBD, and also for executing the failover and switchover operations. CoroSync is the communication infrastructure used by Pacemaker to exchange massages between the two nodes.
Applications accessing this cluster do so through a Virtual IP address that is assigned to the active node, specifically to the MySQL Fabric process, and is automatically migrated to the stand-by node during a failover or switchover operation.
This section aims to describe how to set up this highly available cluster.