Release Notes RonDB 26.02.11#
RonDB 26.02.11 is a release of the RonDB 26.02 series. It is a GA version of RonDB 26.02.
RonDB 26.02.11 is based on MySQL NDB Cluster 8.4.11 and RonDB 25.10.19.
RonDB 21.04 is a Long-Term Support version of RonDB that is no longer supported.
RonDB 22.10 is a Long-Term support version and will be maintained at least until 2026.
RonDB 24.10 is a Long-Term support version and will be maintained at least until 2027.
RonDB 25.10 is a Long-Term support version and will be maintained at least until 2028.
RonDB 26.02 is a Long-Term support version and will be maintained at least until 2028.
RonDB 26.02 is released as open source SW with binary tarballs for usage in Linux. It is developed on Linux and Mac OS X and using WSL 2 on Windows (Linux on Windows).
RonDB 26.02.0 and onwards is supported on Linux/x86_64 and Linux/ARM64.
RonDB 26.02.11 is also available as a Docker container for both x86_64 and ARM CPUs and one can also use RonDB through rondb-helm, a Helm chart to use RonDB in Kubernetes.
The other platforms are currently for development and testing. Mac OS X is a development platform and will continue to be so.
Description of RonDB#
RonDB is designed to be used in a managed cloud environment where the user only needs to specify the type of the virtual machine used by the various node types. RonDB has the features required to build a fully automated managed RonDB solution.
It is designed for applications requiring the combination of low latency, high availability, high throughput and scalable storage (LATS).
You can use RonDB in a Serverless version on app.hopsworks.ai. In this case Hopsworks manages the RonDB cluster and you can use it for your machine learning applications. You can use this version for free with certain quotas on the number of Feature Groups (tables) you are allowed to add and quotas on the memory usage. You can get started in a minute with this, no need to setup any database cluster and worry about its configuration, it is all taken care of.
You can use the open source version and use the binary tarball and set it up yourself.
You can use the open source version and build and set it up yourself.
These are the commands you can use to retrieve the binary tarball:
# Download x86_64 on Linux
wget https://repo.hops.works/master/rondb-26.02.11-linux-glibc2.28-x86_64.tar.gz
# Download ARM64 on Linux
wget https://repo.hops.works/master/rondb-26.02.11-linux-glibc2.28-arm64_v8.tar.gz
These versions are also available as Docker containers at
hub.docker.com under hopsworks/rondb. See
https://hub.docker.com/r/hopsworks/rondb/tags for an up to date list
of which RonDB container images are available. These containers can be
used to run RonDB in containers, in Hopsworks they are also used since
version 4.0 as containers in the Hopsworks Kubernetes cluster.
The actions to build both x86_64 and ARM64 tarballs have now been
fully automated.
Summary of changes in RonDB 26.02.11#
RonDB 26.02.11 is based on MySQL NDB Cluster 8.4.11 and RonDB 25.10.19.
RonDB 26.02.11 contains all improvements and bug fixes of RonDB 25.10.19, see the release notes of RonDB 25.10.19. In addition it merges MySQL NDB Cluster 8.4.9, 8.4.10 and 8.4.11, and adds 7 improvements and fixes 7 bugs that are specific to the RonDB 26.02 series.
New features in 26.02.11 include support for up to 8191 API nodes, user rate limits, support for RDMA transporters and a minimal Docker image.
Test environment#
RonDB uses four different ways of testing. MTR is a functional test framework built using SQL statements to test RonDB.
The Autotest framework is specifically designed to test RonDB using the NDB API. The Autotest is mainly focused on testing high availability features and performs thousands of restarts using error injection as part of a full test suite run.
Benchmark testing ensures that we maintain the throughput and latency that is unique to RonDB. The benchmark suites used are integrated into the RonDB binary tarball making it very straightforward to run benchmarks for RonDB.
Finally we also test RonDB in the Hopsworks environment where we perform both normal actions as well as many actions to manage the RonDB clusters.
RonDB has a number of MTR tests that are executed as part of the build process to improve the performance of RonDB.
MTR testing#
RonDB has a functional test suite using the MTR (MySQL Test Run) that executes more than 500 RonDB specific test programs. In addition there are thousands of test cases for the MySQL functionality. MTR is executed on both Mac OS X and Linux.
We also have a special mode of MTR testing where we can run with different versions of RonDB in the same cluster to verify our support of online software upgrade.
Autotest#
RonDB is very focused on high availability. This is tested using a test infrastructure we call Autotest. It contains also many hundreds of test variants that takes around 36 hours to execute the full set. One test run with Autotest uses a specific configuration of RonDB. We execute multiple such configurations varying the number of data nodes, the replication factor and the thread and memory setup.
An important part of this testing framework is that it uses error injection. This means that we can test exactly what will happen if we crash in very specific situations, if we run out of memory at specific points in the code and various ways of changing the timing by inserting small sleeps in critical paths of the code.
During one full test run of Autotest, RonDB nodes are restarted thousands of times in all sorts of critical situations.
Autotest currently runs on Linux with a large variety of CPUs, Linux distributions and even on Windows using WSL 2 with Ubuntu.
Benchmark testing#
We test RonDB using the Sysbench test suite, DBT2 (an open source variant of TPC-C), flexAsynch (an internal key-value benchmark), DBT3 (an open source variant of TPC-H) and finally YCSB (Yahoo Cloud Serving Benchmark). We test the REST API server using benchmark programs written in Go and Feature Store REST API server is benchmarked using a tool called Locust that can be used to test various application variants. This tool is heavily used to benchmark application scenarios required by Hopsworks customers.
Dydra, a community user of RonDB implements a graph database supporting SPARQL on top of RonDB using a Common Lisp NDB API. They also have a set of benchmarks to verify the performance of RonDB in their application.
The focus is on testing RonDBs LATS capabilities (low Latency, high Availability, high Throughput and scalable Storage).
Hopsworks testing#
Finally we also execute tests in Hopsworks to ensure that it works with HopsFS, the distributed file system built on top of RonDB, and HSFS, the Feature Store designed on top of RonDB, and together with all other use cases of RonDB in the Hopsworks framework.
Improvements#
Merge with MySQL 8.4.9, 8.4.10 and 8.4.11#
RonDB 26.02.11 merges MySQL NDB Cluster 8.4.9, 8.4.10 and 8.4.11 and is thus up-to-date with MySQL NDB Cluster 8.4.11 and its security fixes.
Up to 8191 API nodes#
The highest node id of API nodes is raised from 2039 to 8191. All data
nodes must run RonDB 26.02.11 or later to use node ids above 2039, and
SQL nodes with such node ids use the ndb_schema_result protocol for
schema distribution.
Lower memory usage for large clusters#
Arrays indexed by node id and send buffers are now sized by the configuration instead of the highest possible node id, and automatic send buffer sizing is bounded by the number of CPUs.
RONDB-978: User rate limits#
Rate limits can be set per user, not only per database, with the USER
commands of the management client. The REST API server can use the API
key as the user (configuration section RateLimit), and RonSQL returns
HTTP status 429 when rate limited.
RDMA transporter#
RonDB supports RDMA transporters for the communication between data
nodes, a contribution by Eyal Lemberger at PEAK-AIO. It is built with
the CMake option WITH_NDB_RDMA=ON; the release tarballs and Docker
images do not include it yet. Its logging is set with RdmaLogLevel,
also at runtime, and its counters are shown in the ndbinfo table
rdma_transporters.
Faster configuration handling in ndb_mgmd#
ndb_mgmd allocates node ids faster when thousands of API nodes connect at the same time, serves the configuration of a node without copying the whole configuration, and accepts configurations of up to 12 MiB.
RONDB-1116: Minimal Docker image and build updates#
The Docker image contains only runtime packages and includes a CycloneDX SBOM that identifies the MySQL base version. Builds default to Oracle Linux 9 and use Go 1.27.0 and OpenSSL 3.5.8.
Bug Fixes#
RONDB-1058: MGM session closed by the arbitrator startup gate#
The arbitrator startup gate closed the MGM session when it blocked a command, and a data node start failed if the MGM connection was lost before it was converted to a transporter.
ndb_mgmd wedged by node id allocation retries#
Retries of node id allocation could create tens of thousands of MGM sessions and wedge ndb_mgmd. The retries are now bounded and the number of MGM API sessions is capped.
ndb_mgmd deadlock during a configuration change#
A live configuration change could deadlock with node status broadcasts in ndb_mgmd.
Busy retries in ndb_mgmd#
ndb_mgmd retried a busy schema transaction without delay, which could make commands such as changing a user rate limit time out.
RONDB-1105: ClusterJ race in unloadSchema#
Unloading a schema in ClusterJ could race with concurrent NdbRecord
builds.
TTL purge of a dropped table#
The TTL purge worker did not detect that a table had been dropped when its scan failed.
Build fixes#
Fixed building and installing on macOS. libndbclient is now published for both x86_64 and aarch64 (HOPSFS-408).