GridGain 9.1.8 Release Notes

GridGain 9.1.8 is a public release featuring AWS KMS encryption and improved continuous queries, along with cumulative improvements since 9.1.0.

Overview

GridGain 9.1.8 is a public release that features AWS KMS encryption, improved continuous query management and logging.

As a public release, it also includes cumulative improvements since 9.1.0, now available to users of community edition.

Known Issues

Array Node Configuration Update at Runtime

In this release, you cannot add new values to configurations defined as arrays via CLI or REST API at runtime. This affects the following properties:

ignite.clientConnector.listenAddresses
ignite.failureHandler.handler.ignoredFailureTypes
ignite.network.listenAddresses
ignite.network.nodeFinder.netClusterNodes
ignite.nodeAttributes.nodeAttributes
ignite.storage.profiles
ignite.system.properties

To add new values to these properties, define them in the initial node configuration and restart the node. By default, the node loads the configuration from the {GRIDGAIN_HOME}/etc/gridgain-config.conf file.

This issue will be fixed in an upcoming release.

Major Changes

This release has the following major changes:

Closeable Table Views

Starting with this release, all table views are AutoCloseable and can be wrapped in a try-with-resources statement.

Only views for near caches require closing to ensure correct resource cleanup and must be wrapped in a try-with-resources statement.

// Using try-with-resources statement to safely handle a near cache.
public static void demonstrateNearCacheClient() throws Exception {
    try (IgniteClient client = IgniteClient.builder()
            .addresses("127.0.0.1:10800")
            .build()) {

        // Configure near cache options.
        NearCacheOptions nearCacheOptions = NearCacheOptions
                .builder()
                .expireAfterAccess(5000)
                .expireAfterUpdate(100000)
                .maxEntries(100)
                .build();

        // Create table view configuration.
        TableViewOptions tableViewOptions = TableViewOptions
                .builder()
                .nearCacheOptions(nearCacheOptions)
                .build();

        try (RecordView<Tuple> accounts = client.tables().table("accounts").recordView(tableViewOptions)) {
            // Work with the near cache.
        }
    }
}

New Features and Changes

These features were added in this release:

AWS KMS Encryption

When using encryption on the cluster, you can now set up AWS KMS provider. When used, AWS will manage your keys and provide them as required.

The example below shows how to create a provider and use it on the cluster:

{
    "ignite" : {
        "encryption" : {
            "enabled" : true,
            "activeProvider" : "aws",
            "providers" : [{
                "name" : "aws",
                "type" : "aws_kms",
                "keyId" : "my_key"
            }]
        }
    }
}

Skipping Old Entries in Continuous Queries

A new skipOldEntries option was added to continuous queries. When set to true, TableRowEvent#oldEntry() will return null for TableRowEventType#UPDATED events. This option can be used to reduce the network load and avoid resending old entries.

var options = ContinuousQueryOptions.builder()
        .pollIntervalMs(10)
        .pageSize(pageSize)
        .skipOldEntries(true)
        .build();

view.queryContinuously(subscriber, options);

Improvements and Fixed Issues in This Release

This release features the following improvements:

Issue ID

Cumulative Major Changes

The following major changes were implemented in one of the releases between 9.1.0 and 9.1.8. If you are already using one of those releases, see the release notes for individual releases for the list of changes.

Partition Colocation

This release features a major rework of how partitions are distributed to the nodes and organized.

With partition colocation enabled by default for new clusters, partitions with the same index for all tables in the same distribution zone will now be stored on the same node and use the same RAFT group. This change results in improved performance, as the cluster requires fewer resources to manage distribution zones.

For nodes started with persistent storage from previous versions, partition colocation will be disabled by default. Due to major changes in partitions management, persistent storage from previous versions is not compatible with colocation. We recommend recreating persistent storage on a new 9.1.4 or later cluster and manually migrating data to it.

If you receive the incompatible colocation mode error when the node attempts to join the cluster, clear the persistent data on the node and explicitly set the replication mode by setting the IGNITE_ZONE_BASED_REPLICATION system property to true (to enable colocation mode) or false (to disable colocation mode).

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

Previously used configuration is temporarily supported for backwards compatibility and should be replaced by new configuration options.

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 temporarily supported for backwards compatibility and should be replaced by new syntax.

Changed Syntax for Getting Nodes in Java

The ignite.clusterNodes() method was deprecated in this release and is replaced by ignite.cluster().nodes() method. This method now returns nodes in the logical topology.

The clusterNodes() will temporarily continue to work for backwards compatibility, however we recommend changing your code to use the new method.

Ignite ignite = node.api();

// Deprecated method for getting cluster nodes
var oldClusterNodes = ignite.clusterNodes();

// New method for getting cluster nodes
var newClusterNodes = ignite.cluster().nodes();

Extended Critical Worker Timeouts

This release increases default timeout values for critical workers. The following values are changed:

ignite.system.criticalWorkers.livenessCheckIntervalMillis changed from 200 to 2000 milliseconds,
ignite.system.criticalWorkers.maxAllowedLagMillis changed from 500 to 5000 milliseconds,
ignite.system.criticalWorkers.nettyThreadsHeartbeatIntervalMillis changed from 100 to 1000 milliseconds.

Cumulative Features Since 9.1.0

These features were added in one of the releases between 9.1.0 and 9.1.8. If you are already using one of those releases, see the release notes for individual releases for the list of features added in them.

Near Caches

This release reintroduces support for near caches in GridGain 9. Near caches provide a way to store data locally on your clients and avoid lengthy network queries for latest data from the cluster.

You can configure near cache for any table view. Data will be queried from the cluster when it is read, and stored locally for the configured duration for repeated access.

Just like with table views, it is recommended to use try-with-resources statement to avoid any possible memory leaks.

Below is a simple example of configuring near cache for a table:

NearCacheOptions nearCacheOptions = NearCacheOptions
  .builder()
  .expireAfterAccess(5000)
  .expireAfterUpdate(100000)
  .maxEntries(100)
  .build();
TableViewOptions tableViewOptions = TableViewOptions
  .builder()
  .nearCacheOptions(nearCacheOptions)
  .build();
QualifiedName myTable = QualifiedName.parse("PUBLIC.accounts");
try (KeyValueView<Tuple, Tuple> kvView = client.tables().table(myTable).keyValueView(tableViewOptions)) {
    ...
}

For more information on near caches, as well as limitations, see Near Cache documentation.

Python Client

This release brings the first version of the Python client. The client API is experimental and may change in subsequent releases. Currently, the Python client is exclusively dedicated to working with distributed maps.

You can install the python client from pip by installing pygridgain of version 9 or later:

pip install pygridgain>=9

The following example demonstrates how you can use the client to create a map, add a value to it, and get it back:

async with AsyncClient(address) as client:
    await client.connect()
    print("client connected")
    binary_map = await client.structures().get_or_create_binary_map('myMap')
    await binary_map.put(b'1', b'Hello World')
    value_exists = await binary_map.contains(b'1')
    print(f"Does 1 exist on the cluster: {value_exists}")
    print(await binary_map.get(b'1'))

For more information about Python client, see client documentation.

Change Data Capture

This release features the first implementation of change data capture. You can now use it to configure replication of data to Iceberg. Once configured all updates to GridGain tables will be automatically propagated to Iceberg.

To start CDC replication:

Configure data source:

cdc source create --name gridgain_source --type gridgain --tables PUBLIC.MY_TABLE1

Configure data sink:

cdc sink create --name iceberg_sink --type Iceberg

Create a replication that uses previously configured sink and source:

cdc replication create --name my_replication --source gridgain_source --sink iceberg_sink

Start the replication:

cdc replication start --name my_replication

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 them 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);
}

Archiving Data in Secondary Storage

When using secondary storage, you can configure your tables to delete data from primary storage when it is no longer in active use. To do this, you specify the ARCHIVE AT condition with a ttl of when the data should be removed from primary storage, for example:

CREATE TABLE IF NOT EXISTS Person (
  id int primary key,
  name varchar,
  ttl TIMESTAMP WITH LOCAL TIME ZONE)
  ZONE zone1 SECONDARY ZONE secondary_zone SECONDARY STORAGE PROFILE 'columnar_storage' ARCHIVE AT ttl;

Once data is archived, it will no longer be available in primary storage, but can still be accessed from secondary storage. To make sure data is read from secondary storage, you can use the /*+ use_secondary_storage */ sql hint.

SELECT * FROM Person /*+ use_secondary_storage */

Partition Awareness for Client SQL

With this release, clients will benefit from partition awareness for SQL queries, significantly improving their performance.

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'];

Improved Migration Tools

This release features major changes in migration tools:

A new way of configuring mapping between caches and tables during DCR from GridGain 8 was added. By using it, you can map key and value cache fields separately, as well as ignore the fields that are not required. The example below shows how you can configure mapping:

dr-service-config = {
  cacheMapping = [
    {
      cache = "cacheName"
      table = "schemaName.tableName"
      keyFields = [
        { field = "K1", column = "COL_1" }
        { field = "K2", column = "COL_2" }
        { field = "K3", column = "COL_3" }
      ]
      valueFields = [
        { field = "V1", column = "COL_4" }
        { field = "V2", column = "COL_5" }
        { field = "V3", column = "COL_6" }
        { field = "V4", ignore = true }
      ]
    }
  ]
}

Code adapter now supports migration of GridGain 8 ScanQueries.

Creating Caches From Java

With this release, you can use the @Cache annotation in Java to create caches from Java classes. You can create caches from Key-Value POJOs. Once a cache is created, you can work with it as described in cache documentation.

class PojoKey {
    @Id
    Integer id;

    @Id(SortOrder.DESC)
    @Column(value = "id_str", length = 20)
    String idStr;
}

@Cache(
    value = "kv_pojo",
    zone = @Zone(
		value = "zone_test",
		replicas = 2,
		storageProfiles = "default"
   ),
    colocateBy = { @ColumnRef("id"), @ColumnRef("id_str") },
    indexes = { @Index(value = "ix", columns = {
                    @ColumnRef(value = "f_name"),
                    @ColumnRef(value = "l_name") })
    }
)
class PojoValue {
    @Column("f_name")
    String firstName;

    @Column("l_name")
    String lastName;

    String str;
}

Table myTable = ignite.catalog().createCache(PojoKey.class, PojoValue.class);

KeyValueView<PojoKey, PojoValue> view =  myTable.keyValueView(PojoKey.class, PojoValue.class);

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)

Batched Execution Cancellation

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

New Method to Get Local Node

With this release, you can use the new ignite.cluster().localNode() method to quickly get the local embedded node.

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.

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';

Mapping Empty Values in COPY INTO Command

With this release, you can configure how empty values are mapped on import, and null values are mapped to on export. You do this by adding the null parameter and assigning a new value.

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

Cluster Topology Metrics

This release includes new cluster topology metrics, that provide information about node name, id and version, as well as cluster name, id, and number of nodes in the cluster. For more information about these sources, see Available Metrics.

Improved SSL Support

This release introduces support for SSL in Python DB API and ODBC Driver. You can now securely connect to your cluster from both.

To securely connect from python DB API, specify the ssl key file and certificate in the connection configuration:

pyignite_dbapi.connect(
	address='127.0.0.1',
	use_ssl=True,
	ssl_keyfile='<path_to_ssl_keyfile.pem>',
	ssl_certfile='<path_to_ssl_certfile.pem>'
)

For ODBC driver, specify it in the connection string:

DRIVER={Apache Ignite 3};ADDRESS=localhost:10800;SCHEMA=yourSchemaName;SSL_MODE=require;SSL_KEY_FILE=<path_to_ssl_keyfile.pem>;SSL_CERT_FILE=<path_to_ssl_certfile.pem>

Extended Metrics

This release includes multiple new metrics that can enhance monitoring your clusters:

New SQL thread pool metrics
New sql query execution metrics.
Extended data region metrics.
A new data center replication lag metric.

For a full list of metrics, see the Available Metrics.

Improved Monitoring

This release features multiple improvements to cluster monitoring:

New ClockSkewExceedingMaxClockSkew metric can be used to monitor clock drift.
A set of new compute events allows for easier monitoring of your distributed computing jobs.

Cumulative Improvements and Fixed Issues

The following improvements have been implemented in one of the releases between 9.1.0 and 9.1.8. If you are already using one of those releases, see the release notes for individual releases for the list of improvements.

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, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7

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.

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 7 days ago

Was this helpful?