Skip to content

Online scalable RonDB#

Originally MySQL NDB Cluster was built for extreme throughput and low latency. This meant that data structures were used that required lots of manual configuration steps and it was possible to specify the thread model used in NDB to a very high level.

RonDB is targeting the same requirements on extreme throughput and low latency. The goal of RonDB is to be self-managed. This means that the user specifies the VMs to use by RonDB, the rest is handled by managed RonDB automatically.

Most of the algorithms to handle this is available in the open source version of RonDB. The Hospworks company has added commercial software to work with RonDB in a cloud environment with user interface, monitoring and managed reconfiguration of RonDB clusters.

All algorithms to handle memory internally in RonDB nodes is part of the open source product, so is the adaptive algorithms to handle CPU spinning, thread management and checkpointing algorithms.

One of the main objectives with the RonDB development is to make it possible to scale a RonDB cluster in all directions. More concretely, this means the ability to do the following three things:

  1. to increase and decrease the number of CPUs and the amount of memory used by the data nodes

  2. to increase and decrease the replication level used by RonDB.

  3. to increase the number of shards (or node groups as they are called in RonDB)

The possibility to scale up and down the number of ldm threads was added in MySQL NDB Cluster 8.0.23. In RonDB a number of bug fixes have been made in this areas as well as making automatic thread configuration the default behaviour.

In RonDB 21.04 we have added automatic memory configuration and made this the default behaviour as well.

In MySQL NDB Cluster it is not possible to change the number of replicas. If one starts with 1 replica, it is necessary to perform a backup and restore to grow into a larger cluster.

In RonDB it is possible to change the number of replicas, the configuration should always be prepared for the largest possible number of replicas. However the nodes that you don’t need for the moment are defined as inactive. In this manner we can increase the replication level by simply activating a new node and starting this node up.

In a cloud setting to move from one VM size to another VM size requires actually shutting down a VM and starting up a new VM. This VM could have a new IP address. To ensure that we can handle this, RonDB also supports changing the hostname of a data node when it is in the inactive state.

Thus we are capable to have a fully flexible configuration where we can automate the management of RonDB to ensure that it can both grow and shrink in size.

All of these operations are performed while the cluster is up and running, thus no downtime is incurred due to those changes.

These features are the most important building block of RonDB, thus we will explain them in more detail in the following chapters.