Skip to content

New features in RonDB 21.04#

Automated Thread Configuration#

Thread Configuration defaults to automatated configuration of threads based on the number of CPUs. This feature is introduced in NDB 8.0.23, in RonDB it is the default behaviour. A number of bug fixes have been found and fixed in this area. RonDB will make use of all CPUs it gets access to and also handles CPU locking automatically. It is possible to set NumCPUs to a specific number if one wants to override this default. It is also possible to use RonDB in a backwards compatible manner although this isn't recommended.

Automated Memory Configuration#

NDB has historically required setting a large number of configuration parameters to set memory sizes of various memory pools. In RonDB 21.04 the default behaviour is that no configuration parameter is required. RonDB data nodes will use the entire memory available in the server/VM. One can limit the amount of memory it can use with a new configuration parameter TotalMemoryConfig.

Automated CPU spinning#

NDB 8.0.23 contained support for CPU spinning. RonDB 21.04 defaults to using LatencyOptimisedSpinning.

Improved networking through send thread handling#

RonDB 21.04 has made improvements to the send thread handling making it less aggressive and also automatically activating send delays at high loads.

Configurable number of replicas#

RonDB 21.04 solves another configuration problem from NDB 8.0.23. In NDB 8.0.23 and earlier releases of NDB one could only set NoOfReplicas at the initial start of the cluster. The only method to increase or decrease replication level was to perform a backup and restore.

In RonDB 21.04 one can set NoOfReplicas=3 even if one wants to run with a single replica. It is necessary to define the extra nodes in the configuration, but by setting the configuration parameter NodeActive=0 on those nodes, they are not really part of the cluster until they get activated.

To support this feature three new commands have been added in the management client.

2 ACTIVATE
2 HOSTNAME 192.168.1.113
2 DEACTIVATE

The above commands activates/deactivates node 2 and the HOSTNAME command changes the hostname of node 2 to 192.168.1.113. A node must be inactive to make it possible to change its hostname.

This feature also makes it very easy to move a node from one hostname to another hostname.

3x performance improvement in ClusterJ API#

A new addition to the ClusterJ API was added that release data objects and Session objects to a cache rather than releasing them fully. In addition an improvement of the garbage collection handling in ClusterJ was handled. These improvements led to a 3x improvement in a simple key lookup benchmark.

Integrated benchmarking tools in RonDB binary distribution#

In the RonDB binary tarball we have integrated a number of benchmark tools to assess performance of RonDB.

Improved report of use of memory resources in ndbinfo.resources table#

A new row to the ndbinfo table resources was added which reports TOTAL_GLOBAL_MEMORY. This is the sum of memory resources managed by the shared global memory that contains

New configuration variable LowLatency#

Introduced a new configuration variable LowLatency that is a boolean that defaults to off. If not set we get the normal commit behaviour with linear commit. When set we use normal commit that sends the commit to all nodes in parallel which should decrease latency at the expense of higher networking costs, both CPU wise and bandwidth-wise.

This affects the COMMIT phase and COMPLETE phase. It doesn't affect the prepare phase. Using Low latency means that we will always wait with releasing the lock until the complete phase.

It is mainly useful in clusters with high latency and clusters with 3-4 replicas.

Improvements in ClusterJ to avoid single-threaded garbage collection#

Changes of defaults in RonDB#

A number of configuration variables have new defaults in RonDB 21.04.

ClusterJ lacked support for Primary keys using Date columns#

Removed this limitation by removing check for that this is not supported.

In addition it required the addition of a new object to handle Date as Primary Key based on the handling of Date columns in non-key columns.

Support minimal memory configurations#

Increase SendBufferMemory default#

Place pid-files in configured location#

Add support for Longvarchar data types as primary key in ClusterJ#

This is necessary to handle primary keys that are defined as VARCHAR(x) where max size of this column is larger than 255 bytes. Thus even VARCHAR(64) can be a problem with character sets that are 4 byte per character.

Added tests also for Varchar as primary key which was previously missing although it was supported.

Improvements of ndb_import#

ndb_import will use values from CSV files to set values of auto increment values. It will however not ensure that the auto increment values set in RonDB will be correct after the ndb_import process.

To solve this we introduce a new option to ndb_import called --use-auto-increment, this will ignore the settings from the CSV file and instead set an autoincrement value, this will ensure that INSERTs to the table will be correct and working after importing data using ndb_import.

If this option isn't set it is necessary to set a new starting value for the auto increment. This can be done e.g. by the following transaction:

BEGIN;
INSERT INTO table (column list) (auto\_increment\_value, values);
ROLLBACK;

This will set the new auto increment value in the table.

This version of ndb_import is integrated in the DBT2 benchmark provided with the RonDB release.

Graceful shutdown when using kill -TERM#

For RonDB to interact with systemd in a good way we need to enable graceful shutdown even if it is started using kill -TERM ndbmtd.

The method in NDB to handle shutdown isn't working very well since it is hard to know which processes to stop to really stop ndbmtd. However most use cases can use killall -TERM ndbmtd to kill all ndbmtd processes in the VM. This patch ensures that the above command leads to a graceful shutdown that completes within 30 seconds.

Support larger transactions#

In NDB large transactions can easily cause job buffer explosion or send buffer explosion. By introducing batching of abort and commit and complete requests we ensure that no buffer explosions occur. Also introduced CONTINUEB handling of releasing records belonging to a large transaction to sustain low latency even in the context of large transactions.

ARM64 support#

Mac OS X support for both x86 and ARM#

Two new ndbinfo tables to check memory usage#

Make it possible to use IPv4 sockets between ndbmtd and API nodes#

Use of realtime prio in NDB API receive threads#

Experiments shows that it removes a lot of variance in benchmarks, decreasing variance by a factor of 3. In a Sysbench Point select benchmark it improved performance by 20-25% while at the same time improving latency by 20%. One could also get the same performance at almost 4x lower latency (0.94 ms round trip time for a PK read compared to 0.25 ms after change).

ClusterJ supporting setting database when retrieving Session object#

ClusterJ has been limited to handle only one database per cluster connection. This severely limits the usability of ClusterJ in cases where there are many databases such as in a multi-tenant use case for RonDB.

At the same time the common case is to handle only one database per cluster connection. Thus it is important to maintain the performance characteristics for this case.

A new addition to the public ClusterJ API is the addition of a new getSession call with a String object representing the database name to be used by the Session object. Once a Session object has been created it cannot change to another database. A session object can have a cache of DTO objects, this would be fairly useless when used with many different databases. Thus this isn't supported in this implementation. The limitation this brings about is that a transaction is bound to a specific database.