Automatic Failover

Automatic Failover in CCX is only applicable and available for the following database vendor:

• MariaDB Cluster
• Percona XtraDB Cluster
• PostgreSQL

Can A Single Node Do Failover?

No. A single-node data store offers no redundancy. CCX has no option for failover for this setup if something goes wrong with the database node.

Failover Mechanism

CCX is a fully managed service which means that there are no further actions to be made by the end-user. Once a node fails, CCX has a controller that facilitates all the status and does a health check for all the deployed nodes in your account. It is done on a timely basis in order to safeguard the failure of the nodes.

There are certain cases and occasions that a node is irrecoverable by the controller. These occasions can be a failed hardware, data corruption due to a bug either at the OS level or the database software layer. The Severalnines Support Team is a group of highly skilled engineers and developers that is there to facilitate and manage the administrative process in order to bring back the failed node, delegated in accordance to the SLA’s that we offer on our customer’s behalf.

CCX Controller

The CCX Controller is an automated software that acts as a virtual DBA that facilitates the health checks, raises alarms, sends notifications, performs automatic recovery, backups and restorations and many more. It is backed by ClusterControl which is a proven and battle-tested database management software, especially for open-source database management systems.

MariaDB Cluster

MariaDB Cluster is also known as MariaDB Galera Cluster. It is a virtually synchronous multi-master cluster for MariaDB and is powered by MySQL-wsrep patch for MariaDB and Galera wsrep library.

The failover mechanism is a built-in capability within Galera. If chosen, the architecture type of this database is already designed with automatic failover, automatic member provisioning and syncing. There is no need to perform failover for writes as long as it can still able to apply quorum, i.e. deployed with 3 (three) nodes. Writes and reads will be redirected correctly within its load balancer which uses ProxySQL on top of the database nodes.

Upon using this type of database cluster, ideally, your application clients have to use your load balancer as the target endpoint so that no disruption and downtime for your writes and reads in case your database node experienced failures, like a database server crash, VM corruption, loss of network connectivity, or hardware failure.

Percona XtraDB Cluster

Percona XtraDB Cluster is a database clustering solution for MySQL. It ensures high availability, prevents downtime and data loss, and provides linear scalability. Within this 3-node cluster deployment, it applies the same capability as with the MariaDB Cluster. It is also powered with Galera and wsrep library and has built-in capability for failing over as long as it can still apply and proceed a quorum, i.e. deployed with 3 nodes. Writes and reads will be redirected correctly within its load balancer which uses ProxySQL on top of the database nodes.

Upon using this type of database cluster, ideally, your application clients have to connect to the load balancer as the target endpoint so that no disruption and downtime for your writes and reads in case your database node experienced failures, like a database server crash, VM corruption, loss of network connectivity, or hardware failure.

PostgreSQL

PostgreSQL deployment consists of a single primary and two replica nodes. Once the primary fails, the CCX Controller will react accordingly and applies an auto-failover for which the failed primary will be terminated and will be totally fenced. Whereas the newly promoted primary, which either comes between the two available standby nodes shall take the role of a master. Whichever of the two standby has the most advanced copy of the previous or failed primary, that shall take the role of the new master.

Upon using this type of database cluster, ideally, your application clients have to connect to the load balancer as the target endpoint so that no disruption and downtime for your writes and reads in case your database node experienced failures, like a database server crash, VM corruption, loss of network connectivity, or hardware failure.