GridGain 9.1.1 Release Notes

GridGain 9.1.1 reworks CREATE ZONE syntax and adds snapshot encryption, .NET distributed computing, and further configuration and logging improvements.

Overview

GridGain 9.1.1 is a big milestone release with support for new storage type, big license changes and a host of improvements and enhancements.

Major Changes

Configuration Changes

This release features a major rework of node and cluster configuration, making configuration names more consistent and reorganizing some parameters.

Below is the summary of the changes:

All configuration property names now include the units used.
A number of default values were changed to better work in real environments

You can continue using previously set up node and cluster configurations.

CREATE ZONE Syntax Changes

The CREATE ZONE and ALTER ZONE command syntax was significantly reworked. All additional parameters (specified in the WITH parameter) are now part of common syntax.

Below is the example of creating a distribution zone:

-- Previously used syntax.
CREATE ZONE IF NOT EXISTS "myExampleZone" WITH STORAGE_PROFILES='default', REPLICAS=3, PARTITIONS=2;

-- Current syntax.
CREATE ZONE IF NOT EXISTS "myExampleZone" (REPLICAS 3, PARTITIONS 2) STORAGE PROFILES['default'];

Previously used syntax is supported for backwards compatibility.

New Features

Snapshot Encryption

Starting with this release, if data encryption is enabled on the cluster, your snapshots will also be encrypted.

You can also manually set snapshot encryption when creating then by using the encryption-provider parameter.

cluster snapshot create --type=full --tables=PERSON --destination=relative-path-example --encryption-provider=keystore

.NET Distributed Computing

This release adds support for .NET compute jobs and stream receivers. You can now implement your jobs and receivers in .NET (C#, F#, and others), deploy them to the cluster, and run them from any supported client or language.

Here is an example of a simple compute job:

JobDescriptor<string, string> jobDesc = JobDescriptor.Of(new HelloJob()) with { DeploymentUnits = [...] };
var jobTarget = JobTarget.AnyNode(await client.GetClusterNodesAsync());
var jobExec = await client.Compute.SubmitAsync(jobTarget, jobDesc, arg: "world");

public class HelloJob : IComputeJob<string, string>
{
    public ValueTask<string> ExecuteAsync(IJobExecutionContext context, string arg, CancellationToken cancellationToken) =>
        ValueTask.FromResult("Hello " + arg);
}

Removing All Data From Tables

New removeAll() and deleteAll() methods can be used to remove all data from key-value and record views respectively.

For example:

KeyValueView<AccountKey, Account> kvView = client.tables()
        .table("accounts")
        .keyValueView(AccountKey.class, Account.class);

AccountKey key = new AccountKey(123456);

Account value = new Account(
        "John",
        "Smith",
        100.00d
);

kvView.put(null, key, value);

kvView.removeAll(null)

COPY INTO batchSize Parameter

With this release, you can choose how many entries are processed at a time when executing the COPY INTO operation. By default, 1024 entries are batched. If you want to change the value, use the batchSize parameter:

/* Import data from CSV with custom quotation character */
COPY FROM '/path/to/dir/data.csv'
INTO Table1 (name, age)
FORMAT CSV
WITH 'batchSize'='2048';

New Distribution Zone QUORUM_SIZE Parameter

You can now manually set the required number of available replicas in the distribution zone by setting the QUORUM_SIZE parameter. If at any point there are fewer replicas available than set in the QUORUM_SIZE, the consensus is lost and updating the table will be impossible until the required number is once again available. Previously written data will still be available.

You can set the quorum size to a specific number.

Below is the example of setting quorum size:

CREATE ZONE IF NOT EXISTS exampleZone (REPLICAS 3, QUORUM SIZE 3) STORAGE PROFILES['default'];

Batched Execution Cancellation

The executeBatch() and executeBatchAsync() methods now return cancellation token that can be used to cancel these operations.

Logging Improvement

This release features major effort in improving logging in GridGain 9. A large number of errors that previously caused unexpected exceptions are now correctly caught, categorized and reported with a correct code.

Improvements and Fixed Issues

Issue ID

Upgrade Information

You can upgrade to current GridGain version from previous releases. Below is a list of versions that are compatible with the current version. Compatibility with other versions is not guaranteed. If you are on a version that is not listed, contact GridGain for information on upgrade options.

9.1.0

Known Limitations

Data Restoration After Data Rebalance

Currently, data rebalance may cause partition distribution to change and cause issues with snapshots and data recovery. In particular:

It is currently not possible to restore a LOCAL snapshot if data rebalance happened after snapshot creation. This will be addressed in one of the upcoming releases.
It is currently not possible to perform point-in-time recovery if data rebalance happened after table creation. This will be addressed in one of the upcoming releases.

Data Center Replication With Complex Topologies

Complex Data Center Replication topologies (for example, the ones involving cycles) of 3 or more data centers are not supported. This will be addressed in an upcoming releases.

SQL Performance in Complex Scenarios

There are known issues with the performance of SQL read-write transactions in complex read-write scenarios. These issues will be addressed in an upcoming releases.

We Value Your Feedback

Your comments and suggestions are always welcome. You can reach us here: http://support.gridgain.com/.

Last updated 8 days ago

Was this helpful?