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 previous blog, we were able to setup a MySQL NDB Cluster replication between one source and one replica cluster. In this blog, we will discuss about replication between one source and three replica clusters.

Note: With MySQL version (8.0.21), we have started changing the term “master” to “source”, the term “slave” to “replica”. So in this blog we will refer these terms ‘source’ and ‘replica’ wherever applicable.

The main advantage of this type of topology is good for giving ‘local’ reads in geographically distant areas as well as increased redundancy in case of issues.

Let’s create four MySQL NDB Cluster with the following environment, from which one will be termed as ‘source’ cluster while the rest will be ‘replica’ clusters.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management node
• 4 Data nodes …

In this blog series, we will discuss various MySQL NDB Cluster replication topologies possible with a demonstration. We will start with a simple case i.e. one source (formerly called master) and one replica (formerly called slave).

Note: With MySQL version (8.0.21), we have started changing the term “master” to “source”, the term “slave” to “replica”. So in this blog we will refer these terms ‘source’ and ‘replica’ wherever applicable.

Let’s create two MySQL NDB Cluster with the following environment, from which one will be termed as ‘source’ cluster while the other one will be ‘replica’ cluster. For now, let’s stick to the identical environment from both the cluster. Later in the following blog series, we will change the environments and will run the replication.

• MySQL NDB Cluster version (Latest GA version)
• 1 Management node
• 4 Data nodes …

Introduction

In my previous two blogs on this topic I first introduced the concept of automatic thread configuration and the thread model we use in RonDB. After receiving some questions on the topic I dived a bit deeper into explaining the RonDB thread model and its thread pipeline and compared it to another similar concept called batch pipelines.

Since then I read up a bit more on the research in this area with a focus on implementations in other key-value stores. Some researchers argue that a model where one handles the request immediately is superior to a model using a thread pipeline.

RonDB Software …

Introduction

Sysbench is a tool to benchmark to test open source databases. We have integrated Sysbench into the RonDB installation. This makes it extremely easy to run benchmarks with RonDB. This paper will describe the use of these benchmarks in RonDB. These benchmarks were executed with 1 cluster connection per MySQL Server. This limited the scalability per MySQL Server to about 12 VCPUs. Since we executed those benchmarks we have increased the number of cluster connections per MySQL Server to 4 providing scalability to at least 32 VCPUs per MySQL Server.

As preparation to run those benchmarks we have created a RonDB cluster using the Hopsworks framework that is currently used to create …

Release of RonDB 21.04.0

RonDB is based on MySQL NDB Cluster optimised for use in modern cloud settings. Today we launch RonDB 21.04.0. In RonDB 21.04.0 we have integrated benchmark scripts to execute various benchmarks towards RonDB.

There are three ways of using RonDB. The first is using the managed version provided by Logical Clocks. This is currently available in AWS and is currently being developed to also support Azure. This is still in limited access mode. To access it contact Logical Clocks at the rondb.com website.

The second way is to use a script provided by Logical Clocks that automates the creation of VMs and the installation of the software components required by RonDB. These scripts are available to create RonDB clusters on Azure and GCP (Google Cloud). This script can be downloaded from nexus.hops.works/rondb-cloud-installer.sh.

In this post, we will see how to access database and its objects in MySQL NDB Cluster from Connector/python program. I assume that the reader has some basic understanding of python language and MySQL NDB Cluster.
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 Mysqld server
• Configuration slots for up to 4 additional API nodes
• Connector/Python version (Latest GA version)

Note: Python software must be installed on the same host where we are planning to install MySQL Connector/Python.

MySQL NDB Cluster Architecture:
Let’s look at the MySQL NDB Cluster architecture.

…

In this blog, we will discuss about how to perform cluster configuration changes while cluster is up and processing transactions (online).

In MySQL NDB Cluster, configuration data is parsed and distributed by the management server (MGMD) nodes. Users supply an input text file (commonly known as config.ini) which describes cluster topology, resource usage limits and other parameters. The MGMD nodes parse this file, combine it with designed in defaults and serve the resulting configuration to other node types (data nodes, api nodes), when they connect.
Reasons for changing configuration might include:

- Increased resource usage limits (Data memory, IndexMemory, buffers)
- Adding a new configuration parameter(s) i.e. enabling a new feature
- Unsupported configuration parameter taken out during downgrade to lower version i.e. disabling a feature
- etc ..

MySQL Cluster nodes pick …