MariaDB SkySQL Adds Distributed SQL with Dynamic Elasticity


With this major new release of MariaDB SkySQL, we’ve added distributed SQL capabilities that let you easily scale from 3 to 20 nodes. Distributed SQL is provided through the MariaDB Xpand technology and provides built in high availability (HA) and linear write scaling while at the same time being fully ACID with strong consistency for transactional workloads.

The distributed SQL service in SkySQL is automatically configured for HA and read/write scaling. Due to the dynamic elasticity of this service, you can change the node count on-the-fly without any need to take the service offline for resizing.

MariaDB SkySQL’s distributed SQL option is best suited for applications that need:

  • extreme elasticity, such as application workloads with seasonality or periodicity
  • to scale beyond the capacities of a single node
  • full ACID compliance and five nines of availability

Easily Scale

With the click of a button, you can change the capacity of your service to suit current workload requirements. When you increase or decrease the node count, the service automatically adapts to the new size. You can, for example, start small with a 3 node service but then, as there is a natural increase in demand, you can expand the service up to as many as 20 nodes. If the demand then decreases, you can resize the service again to a smaller node count, which also reduces your spend accordingly.

Changing the node count of a service is easily done from the MariaDB SkySQL portal. Choose the desired node count and click “Apply Changes”.


How It Works

The magic is in the Xpand smart engine that behind the scenes splits each table into horizontal pieces called “slices”. Each slice contains a part of the table, and altogether the slices of a table form the whole table. These slices are spread across the nodes so that each node is responsible for the data on one slice (or more as the table grows).

To ensure HA, each slice will also have a copy on a separate node. If for some reason a node fails, the slice copies become the primary copy of the data and all the data remains intact. Most importantly, the self-healing design of Xpand means that if a node fails, its slices are automatically rebalanced to ensure your data remains protected.

MariaDB Xpand distributes “slices” of data onto multiple nodes and also distributes copies of the slices across nodes for high availability and fault tolerance.

When you expand your service, the new nodes join the service and some of the slices that were on the original nodes will be moved to the new nodes. This rebalancing happens behind the scenes without interrupting traffic. Once the slices have been moved, you have a service that is fully balanced with the new node number and leverages the capacity of all nodes.

If you need to decrease the number of nodes, the operation is done in reverse. The copies of the slices on the node that is being removed will become the primary slices of that data and then copies of the slices will be created on the remaining nodes to guarantee redundancy and HA. Slices are then moved around to make sure the traffic is balanced.

In fact, if for some reason the usage of a table is skewed so that one node is more utilized than others, Xpand will move the slices around automatically to rebalance the load on the nodes. Balanced resource utilization is another great Xpand feature.

For More Information

MariaDB Platform for Distributed SQL on MariaDB SkySQL automatically slices, replicates, and balances data to provide built-in HA and easily scale elastically as workload demands change.