RonDB has now grown up to the same level of memory management as you find in expensive commercial DBMSs like Oracle, IBM DB2 and Microsoft SQL Server.

Today I made the last development steps in this large project. This project started with a prototype effort by Jonas Oreland already in 2013 after being discussed for a long time before that. After he left for Google the project was taken over by Mauritz Sundell that implemented the first steps for operational records in the transaction manager.

Last year I added the rest of the operational records in NDB. Today I completed the programming of the final step in RonDB. This last step meant moving around 30 more internal data structures towards using the global memory manager. These memory structures are used to represent meta data about tables, fragments, fragment replicas, triggers and global replication objects.

One …

When discussing how to achieve High Availability most DBMS focus on handling it via replication. Most of the focus has thus been focused on various replication algorithms.

However truly achieving AlwaysOn availability requires more than just a clever replication algorithm.

RonDB is based on NDB Cluster, NDB has been able to prove in practice that it can deliver capabilities that makes it possible to build systems with less than 30 seconds of downtime per year.

So what is required to achieve this type of availability?

1. Replication
2. Instant Failover
3. Global Replication
4. Failfast Software Architecture
5. Modular Software Architecture
6. Advanced Crash Analysis
7. Managed software

Thus a clever replication algorithm is only 1 of 7 very important parts to achieve the highest possible …

After publishing the Docker container for RonDB I got a suggestion to simplify it further by using Docker Compose. After a quick learning using Google I came up with a Docker Compose configuration file that will start the entire RonDB cluster and stop it using a single command.

First of all I had to consider networking. I decided that using an external network was the best solution. This makes it easy to launch an application that uses RonDB as a back-end database. Thus I presume that an external network has been created with the following command before using Docker Compose to start RonDB:

docker network create mynet --subnet=192.168.0.0/16

The docker-compose.yml is available on GitHub at

…

There was a request to be able to test RonDB using Docker. This is now working.These commands will set up a RonDB cluster on your local machine that can be used to test RonDB:
Step 1: Download the Docker containers for RonDB
docker pull mronstro/rondb
Step 2: Create a Docker subnet
docker network create mynet --subnet=192.168.0.0/16
Step3: Start the RonDB management server
docker run -d \  --net=mynet \  -v /path/datadir:/var/lib/rondb \  -ip 192.168.0.2 \  -name mgmt1 \  mronstro/rondb ndb_mgmd --ndb-nodeid=65
Step 4: Start the first RonDB data node
docker run -d \  --net=mynet \  -v /path/datadir:/var/lib/rondb \  -ip 192.168.0.4 \  -name ndbd1 \  mronstro/rondb ndbmtd --ndb-nodeid=1
Step 5: Start the second RonDB data node
docker run -d \  --net=mynet \  -v /path/datadir:/var/lib/rondb \  -ip 192.168.0.5 \  -name …

In this blog, we will discuss about how to setup MySQL NDB Cluster replication in a more secure way with the help of binary log and relay log encryption and a secure connection. These measures protect binary log dat in transit and at rest.

Let’s create two MySQL NDB Clusters with the following environment, Here, one will be termed as ‘source’ cluster and the other one will be termed as ‘replica’ cluster.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management node
• 4 Data nodes
• 1 MySQLDs
• Configuration slots for up to 4 additional API nodes

Step 1: Start both of the Clusters

Let’s start both the source cluster and replica cluster but do not start the MySQLD servers from both the clusters as we want to modify their configuration first.
…

In this blog, we will discuss about how to scale out MySQL NDB Cluster in few easy steps. The use cases could be, when user business applications demand massive expansion and the existing cluster may not able to handle the request in that case a cluster scaling is needed. This is an online procedure i.e. zero cluster downtime so that user’s business won’t affect while this scaling process is going on.

In the below demo, we will see, how to scale from a 4 nodes cluster to 8 nodes cluster while transactions are going on.

Let’s create a MySQL NDB Cluster with the following environment.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management node
• 4 Data nodes
• 1 MySQLDs
• Configuration slots for up to 4 additional API nodes

Step 1: Let's start the Cluster

Let’s start a 4 nodes cluster.
…

In this blog, we will discuss, how to setup MySQL NDB Cluster replication through backup and restore method. This is bit tricky but interesting. The scenario here is, say user have a standalone cluster up and running, later there is a need to have a replication setup with an another empty cluster without shutting down the existing running cluster i.e. zero downtime. Then this backup and restore method will come in handy.

Let’s create two MySQL NDB Cluster with the following environment, Here, one will be termed as ‘source’ cluster and the other one will be termed as ‘replica’ cluster.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management Node
• 4 Data Nodes
• 1 MySQLDs
• Configuration slots for up to 4 additional API nodes

Replication schema diagram:
CLUSTER 'A'        …

In this blog, we will discuss about bidirectional replication between two NDB clusters. With this topology, user can do transaction simultaneously from both the clusters on the same database objects.

Let’s create two MySQL NDB Cluster with the following environment, Here, both will be termed as ‘source’ cluster as well as ‘replica’ cluster as we will do replication from both the sides.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management node
• 4 Data nodes
• 2 MySQLDs
• Configuration slots for up to 4 additional API nodes

Replication schema diagram:

                    |-----------S1---------->>----------S3--------------|                   …

 In the 1990s I spent a few years studying requirements on databases used in 3G telecom networks. The main requirement was centered around three keywords, Latency, Throughput and Availability. In this blog post I will focus on Availability.

If a telecom database is down it means that no phone calls can be made, internet connections will not work and your app on your smartphone will cease to work. So more or less impacting each and everyone's life immediately.

The same requirements on databases now also start to appear in AI applications such as online Fraud detection, self-driving cars, smartphone apps.

Availability is measured in percent and for telecom databases the requirement is to reach 99.9999% availability. One often calls this Class 6 availability where 6 is the number of nines in the availability percentage.

Almost every database …

 As introduced in a previous blog RonDB enables us to easily execute benchmarks on RonDB using the Sysbench benchmark.

In this blog I will present some results where the RonDB cluster had 2 data nodes, each using a r5.4xlarge VM in AWS that has 16 VCPUs and 128 GB memory. The Sysbench test uses SQL to access RonDB.

In this particular test case we wanted to test the Key-Lookup performance using SQL. Key-Lookup performance is essential in the RonDB use case as an online Feature Store in Hopsworks.

In this case we use the …