Avoiding MySQL Fabric to become a single point of failure

I managed to install and configure MySQL Fabric that manages multiple MySQL Server nodes. It works very well since I tested it by connecting to the Master node directly and played with the data (insert, delete). The slave nodes become identical to the master.

Now, the fabric server should manage everything. Hence, the application should connect to the Fabric and not to the master node. This way, when the Master fails, Fabric will nominate a new Slave.

Q1: How can I avoid Fabric server itself from becoming a single point of failure?

Q2: Anyone has experience implementing Fabric? Is what I am planning to do is the best practice?

Regards,

The MySQL Fabric node itself is not currently redundant but as stated in the MySQL Fabric FAQ:


There is currently only a single instance of the MySQL Fabric node. If that process should fail then it can be restarted on that or another machine and the state and routing information read from the existing state store (a MySQL database) or a replicated copy of the state store.


While the MySQL Fabric node is unavailable, Fabric-aware connectors continue to route queries and transactions to the correct MySQL Servers based on their cached copies of the routing data. However, should a Primary fail, automated failover will not happen until the MySQL Fabric node is returned to service and so it's important to recover the process as quickly as possible.

In terms of best practices, this MySQL Fabric blog post provides an end-to-end worked example of using MySQL Fabric and then the MySQL Fabric white paper adds more of an overview and context information.

Finally, you can watch the MySQL Fabric webinar replay and read Q&A transcript - there are some good, technical questions + responses there.

If you're looking for more discussion on the topic then there's also a dedicated forum for MySQL Fabric, Sharding, HA & Utilities.

StackExchange Database Administrators Q#69210, answer score: 4