New Features

Added support for the RapidJSON library which delivers significantly improved runtime performance when executing JSON functions.

For more information, see REOPTIMIZE Hint.

The new database metrics are:

For more information, see Metrics Published by Database Processes.

The sql-results logging category logs query results to facilitate debugging and diagnostics. For more information, see Description of Logging Options.

The SM write throttle mechanism was improved to use memory more efficiently allowing for greater overall SM reliability and resilience by reducing memory oscillation and out of memory related process shutdown events. (12214, 12237, 12238)

The Administrative Process (AP) and JDBC driver can now use the Java 17 Runtime Environment. For more information, see System Requirements.

Accelerated queries with parameterized LIKE predicates through outer to inner join optimization when applicable, and applied further optimizations if the parameter started without a wildcard.

The following JSON built-in functions were added:

For more information, see SQL JSON String Functions.

Several optimizations have been added to improve performance on partitioned tables, including:

Additional partitioned table performance optimizations may be added in future releases.

Previously, for externally started database processes, the database processes may not distribute evenly across the available Admin processes (APs). A new start te and start sm parameter is used to supply the Admin with distribution policies used to ensure better distribution.

The Kubernetes resource log messages are written to a new log file on the NuoDB Admin server, "nuoadmin_k8sclient.log". Information about fetched API resources and notifications received are logged with DEBUG level. To reduce logging verbosity, Kubernetes API resources used to make decisions in the NuoDB Kubernetes Aware Admin (KAA) module are logged with INFO level if the domain state has been changed. Process labels are included in the logging message in case the domain process is resynchronized by the KAA module.

To better assist our Customer Support team with problem resolution, several new command switches have been added, --collect-cores, --modified-after, and --live-cores. For more information, see NuoDB Command Reference.

If the number of database process tombstones grew large, it would negatively impact display performance when running either the nuocmd show domain or nuocmd show database commands. The number of tombstones grows when a database process is created and then is shutdown or exits for any reason. This enhancement will trigger garbage collection (the purging of the oldest database processes tombstones) if the number of tombstones grows larger than the nuoadmin.conf property variable tombstoneGarbageCollectionThreshold. For more information on how to configure this feature, see the tombstone and incarnationsToRetain property variables located here, Host Properties (nuoadmin.conf).

Previously, in physical/VM host deployments (i.e., not Kubernetes environments) system OS dependencies and NuoDB binary files were collected only if live cores were requested. To improve supportability, system dependencies, binaries, and non-live core files are now packaged and collected if a core file is generated by a database process. This aids the NuoDB Support team when opening and analyzing the core files received when triaging a customer trouble ticket.

To improve diagnostics and supportability, all database process container logs are automatically collected and sent to the Admin Process (AP) that manages the database process, including the very first log messages that contain configuration parameters. Previously, all the database process log messages from its startup were missing and the only way to retrieve them was with kubectl logs <engine pod>. Also, in the event of database process startup failure, the container logs are sent to NUOCMD_API_SERVER which can be defined as a load-balancer endpoint and represents any ready AP pod.

In Kubernetes deployment environments, if the AP was restarted then the database processes (SMs or TEs) may not reconnect quickly enough to the newly started AP to prevent the AP from concluding they are unresponsive and thereby removing them from the NuoDB Admin domain. To improve database and AP communications, periodic liveness checking has been implemented from the database process to its AP, such that, if a reconnect to a new AP process is necessary, the reconnect will happen more quickly. The feature is configured using the processLivenessCheckSec and evictUnkownProcesses property values located in the nuoadmin.conf file. Perviously, the processLivenesCheckSec property only enabled liveness checking of database processes by the APs.

A new version of NuoDB database software may also introduce a new version of the database protocol. To simplify NuoDB version rollout, Kubernetes Aware Admin (KAA) is used to automatically upgrade database protocol and restart a Transaction Engine (TE) as an upgrade finalization step. The feature is configured at the database level and is disabled by default. For more information on how to configure this feature, see Automatic Database Protocol Upgrade.

In Physical / Virtual machine environments, client applications can now connect to the database using a manually configured external IP address. Previously, client applications could only connect to a Transaction Engine (TE) from within the database’s local network or connect from an external IP address by using the direct=true connection property. However, the latter approach bypasses the Admin Process (AP) Load Balancer and its policy assignment feature which is useful for assigning specific TEs to client applications. For more information on how to configure external IP address database connections, see Setting External Connectivity.

The new category of metrics are prefixed by Percent and summarize process resource usage and how much time is spent either doing work or waiting on a particular resource. For more information, see Metrics Published by Database Processes.

The Docker specific subcommands are used to manage externally started database processes that run in containerized environments. In the NuoDB Docker image, NUOCMD_PLUGINS=$NUODB_HOME/etc/nuodocker.py defines the location that the Docker specific subcommands are discovered and registered by nuocmd. For more information, see Docker Specific NuoDB Command Reference.

When a Storage Manager (SM) restarts the above nuocmd subcommands will report journal recovery progress with a status "CONFIGURED:RECOVERING_JOURNAL(NN.N%)" which includes the percentage of the journal that has been recovered. These percentages are updated every five seconds.

In containerized deployment environments, the NuoDB user that starts the database containers can now run as a non-root user and group. This is required to support security policies that prevent containers from running as either the root user (user ID 0) or a member of the root group (group ID 0). Previously NuoDB only supported running with an arbitrary user ID, but always required a group ID of 0. NuoDB can now run with user and group ID 1000:1000. Arbitrary user IDs (i.e. not 1000) are still supported and still require a group ID of 0, which is standard for Red Hat OpenShift environments.

The following --process-filter option has been added to several hot copy related commands:

For more information, see NuoDB Command Reference and Docker-specific NuoDB Command Reference.

These new commands obtain the statuses of all hot copies that have been issued on the currently running Storage Managers (SMs) in the database. For more information, see NuoDB Command Reference.

For more information about how to cancel a hot copy job and the required parameters, see nuocmd subcommand cancel hotcopy.

This support was also added in other client drivers that are built using the C driver, e.g., the C++ and node.js drivers.