Upgrading Data Grid


Red Hat Data Grid 8.5

Upgrade Data Grid to 8.5

Red Hat Customer Content Services

Abstract

Upgrade Data Grid clusters from one 8.x version to another. You can perform rolling upgrades to avoid downtime or offline upgrades during which Data Grid converts data for compatibility.

Red Hat Data Grid

Data Grid is a high-performance, distributed in-memory data store.

Schemaless data structure
Flexibility to store different objects as key-value pairs.
Grid-based data storage
Designed to distribute and replicate data across clusters.
Elastic scaling
Dynamically adjust the number of nodes to meet demand without service disruption.
Data interoperability
Store, retrieve, and query data in the grid from different endpoints.

Data Grid documentation

Documentation for Data Grid is available on the Red Hat customer portal.

Data Grid downloads

Access the Data Grid Software Downloads on the Red Hat customer portal.

Note

You must have a Red Hat account to access and download Data Grid software.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Chapter 1. Data Grid 8 upgrade notes

Review the details in this section before upgrading from one Data Grid 8 version to another.

1.1. Upgrading to Data Grid 8.5

Read the following information to ensure a successful upgrade from previous versions of Data Grid 8 to 8.5.

Removals
  • The Kryo and Protostuff marshallers have been removed.
  • Extended statistics module has been removed.
  • JCache CDI is no longer supported.
  • Spring 5.x and Spring Boot 2.x are no longer supported.
  • Red Hat JBoss EAP modules are no longer provided.
Change of package for classes

The following classes have been moved to different packages:

  • org.infinispan.util.TimeoutException has been moved to org.infinispan.commons.TimeoutException
  • org.infinispan.util.concurrent.IsolationLevel has been moved to org.infinispan.configuration.IsolationLevel
Classes, methods, and properties removal

The following methods and properties have been removed:

  • All: Parsing of configuration files with schema < 10.0
  • Commons: Start.priority and Stop.priority
  • Core: AdvancedCache.with(ClassLoader), AdvancedCache.getEvictionManager(), AdvancedCache.getAsyncInterceptorChain(), AdvancedCache.getComponentRegistry()
  • Core: AnyScopeComponentFactory.construct(Class)
  • Core: Cache.getListeners()
  • Core: ConfigurationBuilder.classLoader(), ConfigurationBuilder.customInterceptors()
  • Core: DataRehashedEvent.getUnionConsistentHash()
  • Core: EmbeddedCacheManager.getListeners(), EmbeddedCacheManager.getTransport(), EmbeddedCacheManager.removeCache(String), EmbeddedCacheManager.getGlobalComponentRegistry()
  • Core: FlagAffectedCommand.setFlags, FlagAffedctedCommand.addFlags, FlagAffectedCommand.hasFlag
  • Core: IntCacheStream.filterKeySegments(Set<Integer>)
  • Core: JMXStatisticsConfiguration
  • Core: GlobalConfiguration.DEFAULT_MARSHALL_VERSION
  • Core; LocalizedCacheTopology.getDistributionForSegment(int)
  • Core: NamedComponentFactory
  • Core: PersistenceUtil.loadAndStoreInDataContainer
  • Core: TopologyChangedEvent.getConsistentHashAtStart() and TopologyChangedEvent.getConsistentHashAtEnd()
  • Core: Transport.invokeRemotely() Transport.waitForView() Transport.backupRemotely() AbstractTransport
  • Core: ValueMatcher.nonExistentEntryCanMatch
  • Core: WriteCommand.updateStatusFromRemoteResponse
  • Core: state transfer pool
  • Counters: SyncStrongCounter and SyncWeakCounter
  • Hot Rod client: org.infinispan.client.hotrod.marshall.ProtoStreamMarshaller
  • Server and clients: keystore certificate password
  • RocksDB Store: expiry queue size
  • Remote Store: transport factory and maxIdle
Metrics

The JGroups and cross-site metrics names change when names-as-tags is set to true, where the cluster’s name and the site’s name are no longer present in the metrics name but as a tag.

As an example, when you set names-as-tags to false, metrics are named based on the channel, resulting in multiple metrics for the same purpose:

# TYPE vendor_jgroups_xsite_frag4_get_number_of_sent_fragments gauge
# HELP vendor_jgroups_xsite_frag4_get_number_of_sent_fragments Number of sent fragments
vendor_jgroups_xsite_frag4_get_number_of_sent_fragments{cluster="xsite",node="..."} 0.0
# TYPE vendor_jgroups_cluster_frag4_get_number_of_sent_fragments gauge
# HELP vendor_jgroups_cluster_frag4_get_number_of_sent_fragments Number of sent fragments
vendor_jgroups_cluster_frag4_get_number_of_sent_fragments{cluster="cluster",node="..."} 2.0

When you set names-as-tags to true, metrics are simplified, and cluster and site names appear as tags:

# TYPE vendor_jgroups_frag4_get_number_of_sent_fragments gauge
# HELP vendor_jgroups_frag4_get_number_of_sent_fragments Number of sent fragments
vendor_jgroups_frag4_get_number_of_sent_fragments{cache_manager="default",cluster="xsite",node="..."} 0.0
vendor_jgroups_frag4_get_number_of_sent_fragments{cache_manager="default",cluster="cluster",node="..."} 2.0
SecurityManager

Aligning with the deprecation for removal of the SecurityManager in Java Development Kit (JDK) 17, integration with a SecurityManager is no longer supported.

Jakarta and Java EE
  • Data Grid has been updated to use jakarta.* packages only.
  • If you require the legacy javax.* packages, you should use Data Grid 8.4.x.
  • The transitional *-jakarta jars, which included both jakarta.* and javax.* packages, have been removed.
Hot Rod client defaults

Data Grid introduced changes to the properties of the Hot Rod client.

ssl_hostname_validation

A new property, ssl_hostname_validation with a default value of true has been added. This property enables TLS hostname validation based on RFC 2818.

Additionally, setting the sni_host_name is now required when hostname validation is enabled.

Table 1.1. Default property changes
PropertyData Grid 8.5Previous versions

connect_timeout

2000 ms / 2 seconds

60000 ms / 60 seconds

socket_timeout

2000 ms / 2 seconds

60000 ms / 60 seconds

max_retries

3

10

min_evictable_idle_time

180000 ms / 3 minutes

1800000 ms / 30 minutes

sasl_mechanism

SCRAM-SHA-512

SCRAM-SHA-256

Data Grid 8.5 introduces the following changes to search.

Indexing
  • The property attribute has been removed.
  • The auto-config attribute has been removed.
  • The index attribute has been removed.
Indexing annotations
  • The Hibernate Search 5 annotations are no longer supported.
  • @ProtoDoc annotation is now deprecated.
Security

The PrincipalRoleMapper now applies only to groups instead of both groups and user principals. Use the cache-manager.security.authorization.group-only-mapping=false configuration to use the old behavior.

For more information about the PrincipalRoleMapper API, see Role and permission mappers.

Scattered cache removal

The scattered cache mode has been removed. Use distributed caches instead. For information about cache modes, see Cache modes.

Global State

By default, Data Grid will not start if a dangling lock file is found in the persistent global state indicating an unclean shutdown. You can change the default behavior by configuring the global state unclean-shutdown-action setting. For more information, see Global persistent location.

Persistence

The default value for availability-interval has been increased to 30 seconds. The previous default was 1 second.

Soft-index file stores

To calculate the number of segments, only the number of cache segments is used instead of using index segment configuration, as was done earlier.

RESP endpoint

Data Grid 8.5 introduces the following changes to the RESP endpoint:

  • The RESP endpoint cache now requires the key storage media type to be application/octet-stream.
  • You can apply default expiration to the cache configuration used by the RESP endpoint.
Client listeners remove events propagation

To support the changes around the new includeOldValue method on CacheEventConverter, client listeners remove events will now be propagated even if the event does not remove a value.

Note

Remove events do not include any values by default

NearCache SPI update

The previous NearCache SPI had an issue with concurrent updates wherein a stale entry could get stored in the near cache. NearCache SPI has been updated to address this issue.

Upgrade from 8.1 at a minimum

If you are upgrading from 8.0, you must first upgrade to 8.1. Persistent data in Data Grid 8.0 is not binary compatible with later versions. To overcome this incompatibility issue, Data Grid 8.2 and later automatically converts existing persistent cache stores from Data Grid 8.1 at cluster startup. However, Data Grid does not convert cache stores from Data Grid 8.0.

Chapter 2. Performing rolling upgrades for Data Grid Server clusters

Perform rolling upgrades of your Data Grid clusters to change between versions without downtime or data loss and migrate data over the Hot Rod protocol.

2.1. Setting up target Data Grid clusters

Create a cluster that uses the Data Grid version to which you plan to upgrade and then connect the source cluster to the target cluster using a remote cache store.

Prerequisites

  • Install Data Grid Server nodes with the desired version for your target cluster.
Important

Ensure the network properties for the target cluster do not overlap with those for the source cluster. You should specify unique names for the target and source clusters in the JGroups transport configuration. Depending on your environment you can also use different network interfaces and port offsets to separate the target and source clusters.

Procedure

  1. Create a remote cache store configuration, in JSON format, that allows the target cluster to connect to the source cluster.

    Remote cache stores on the target cluster use the Hot Rod protocol to retrieve data from the source cluster.

    {
      "remote-store": {
        "cache": "myCache",
        "shared": true,
        "raw-values": true,
        "security": {
          "authentication": {
            "digest": {
              "username": "username",
              "password": "changeme",
              "realm": "default"
            }
          }
        },
        "remote-server": [
          {
            "host": "127.0.0.1",
            "port": 12222
          }
        ]
      }
    }
  2. Use the Data Grid Command Line Interface (CLI) or REST API to add the remote cache store configuration to the target cluster so it can connect to the source cluster.

    • CLI: Use the migrate cluster connect command on the target cluster.

      [//containers/default]> migrate cluster connect -c myCache --file=remote-store.json
    • REST API: Invoke a POST request that includes the remote store configuration in the payload with the rolling-upgrade/source-connection method.

      POST /rest/v2/caches/myCache/rolling-upgrade/source-connection
  3. Repeat the preceding step for each cache that you want to migrate.
  4. Switch clients over to the target cluster, so it starts handling all requests.

    1. Update client configuration with the location of the target cluster.
    2. Restart clients.
Important

If you need to migrate Indexed caches you must first migrate the internal ___protobuf_metadata cache so that the .proto schemas defined on the source cluster will also be present on the target cluster.

2.2. Synchronizing data to target clusters

When you set up a target Data Grid cluster and connect it to a source cluster, the target cluster can handle client requests using a remote cache store and load data on demand. To completely migrate data to the target cluster, so you can decommission the source cluster, you can synchronize data. This operation reads data from the source cluster and writes it to the target cluster. Data migrates to all nodes in the target cluster in parallel, with each node receiving a subset of the data. You must perform the synchronization for each cache that you want to migrate to the target cluster.

Prerequisites

  • Set up a target cluster with the appropriate Data Grid version.

Procedure

  1. Start synchronizing each cache that you want to migrate to the target cluster with the Data Grid Command Line Interface (CLI) or REST API.

    • CLI: Use the migrate cluster synchronize command.

      migrate cluster synchronize -c myCache
    • REST API: Use the ?action=sync-data parameter with a POST request.

      POST /rest/v2/caches/myCache?action=sync-data

      When the operation completes, Data Grid responds with the total number of entries copied to the target cluster.

  2. Disconnect each node in the target cluster from the source cluster.

    • CLI: Use the migrate cluster disconnect command.

      migrate cluster disconnect -c myCache
    • REST API: Invoke a DELETE request.

      DELETE /rest/v2/caches/myCache/rolling-upgrade/source-connection

Next steps

After you synchronize all data from the source cluster, the rolling upgrade process is complete. You can now decommission the source cluster.

Chapter 3. Migrating data between cache stores

Data Grid provides a Java utility for migrating persistent data between cache stores.

In the case of upgrading Data Grid, functional differences between major versions do not allow backwards compatibility between cache stores. You can use StoreMigrator to convert your data so that it is compatible with the target version.

For example, upgrading to Data Grid 8.0 changes the default marshaller to Protostream. In previous Data Grid versions, cache stores use a binary format that is not compatible with the changes to marshalling. This means that Data Grid 8.0 cannot read from cache stores with previous Data Grid versions.

In other cases Data Grid versions deprecate or remove cache store implementations, such as JDBC Mixed and Binary stores. You can use StoreMigrator in these cases to convert to different cache store implementations.

3.1. Cache store migrator

Data Grid provides the CLI migrate store command that recreates data for the latest Data Grid cache store implementations.

The store migrator takes a cache store from a previous version of Data Grid as source and uses a cache store implementation as target.

When you run the store migrator, it creates the target cache with the cache store type that you define using the EmbeddedCacheManager interface. The store migrator then loads entries from the source store into memory and then puts them into the target cache.

The store migrator also lets you migrate data from one type of cache store to another. For example, you can migrate from a JDBC string-based cache store to a SIFS cache store.

Important

The store migrator cannot migrate data from segmented cache stores to:

  • Non-segmented cache store.
  • Segmented cache stores that have a different number of segments.

3.2. Configuring the cache store migrator

Use the migrator.properties file to configure properties for source and target cache stores.

Procedure

  1. Create a migrator.properties file.
  2. Configure properties for source and target cache store using the migrator.properties file.

    1. Add the source. prefix to all configuration properties for the source cache store.

      Example source cache store

      source.type=SOFT_INDEX_FILE_STORE
      source.cache_name=myCache
      source.location=/path/to/source/sifs
      source.version=<version>

      Important

      For migrating data from segmented cache stores, you must also configure the number of segments using the source.segment_count property. The number of segments must match clustering.hash.numSegments in your Data Grid configuration. If the number of segments for a cache store does not match the number of segments for the corresponding cache, Data Grid cannot read data from the cache store.

    2. Add the target. prefix to all configuration properties for the target cache store.

      Example target cache store

      target.type=SINGLE_FILE_STORE
      target.cache_name=myCache
      target.location=/path/to/target/sfs.dat

3.2.1. Configuration properties for the cache store migrator

Configure source and target cache stores in a StoreMigrator properties.

Table 3.1. Cache Store Type Property
PropertyDescriptionRequired/Optional

type

Specifies the type of cache store for a source or target cache store.

.type=JDBC_STRING

.type=JDBC_BINARY

.type=JDBC_MIXED

.type=LEVELDB

.type=ROCKSDB

.type=SINGLE_FILE_STORE

.type=SOFT_INDEX_FILE_STORE

.type=JDBC_MIXED

Required

Table 3.2. Common Properties
PropertyDescriptionExample ValueRequired/Optional

cache_name

The name of the cache that you want to back up.

.cache_name=myCache

Required

segment_count

The number of segments for target cache stores that can use segmentation.

The number of segments must match clustering.hash.numSegments in the Data Grid configuration. If the number of segments for a cache store does not match the number of segments for the corresponding cache, Data Grid cannot read data from the cache store.

.segment_count=256

Optional

marshaller.class

Specifies a custom marshaller class.

Required if using custom marshallers.

marshaller.allow-list.classes

Specifies a comma-separated list of fully qualified class names that are allowed to be deserialized.

Optional

marshaller.allow-list.regexps

Specifies a comma-separated list of regular expressions that determine which classes are allowed be deserialized.

Optional

marshaller.externalizers

Specifies a comma-separated list of custom AdvancedExternalizer implementations to load in this format: [id]:<Externalizer class>

Optional

Table 3.3. JDBC Properties
PropertyDescriptionRequired/Optional

dialect

Specifies the dialect of the underlying database.

Required

version

Specifies the marshaller version for source cache stores.
Set one of the following values:

* 8 for Data Grid 7.2.x

* 9 for Data Grid 7.3.x

* 10 for Data Grid 8.0.x

* 11 for Data Grid 8.1.x

* 12 for Data Grid 8.2.x

* 13 for Data Grid 8.3.x

Required for source stores only.

connection_pool.connection_url

Specifies the JDBC connection URL.

Required

connection_pool.driver_class

Specifies the class of the JDBC driver.

Required

connection_pool.username

Specifies a database username.

Required

connection_pool.password

Specifies a password for the database username.

Required

db.disable_upsert

Disables database upsert.

Optional

db.disable_indexing

Specifies if table indexes are created.

Optional

table.string.table_name_prefix

Specifies additional prefixes for the table name.

Optional

table.string.<id|data|timestamp>.name

Specifies the column name.

Required

table.string.<id|data|timestamp>.type

Specifies the column type.

Required

key_to_string_mapper

Specifies the TwoWayKey2StringMapper class.

Optional

Note

To migrate from Binary cache stores in older Data Grid versions, change table.string.* to table.binary.\* in the following properties:

  • source.table.binary.table_name_prefix
  • source.table.binary.<id\|data\|timestamp>.name
  • source.table.binary.<id\|data\|timestamp>.type
# Example configuration for migrating to a JDBC String-Based cache store
target.type=STRING
target.cache_name=myCache
target.dialect=POSTGRES
target.marshaller.class=org.infinispan.commons.marshall.JavaSerializationMarshaller
target.marshaller.allow-list.classes=org.example.Person,org.example.Animal
target.marshaller.allow-list.regexps="org.another.example.*"
target.marshaller.externalizers=25:Externalizer1,org.example.Externalizer2
target.connection_pool.connection_url=jdbc:postgresql:postgres
target.connection_pool.driver_class=org.postrgesql.Driver
target.connection_pool.username=postgres
target.connection_pool.password=redhat
target.db.disable_upsert=false
target.db.disable_indexing=false
target.table.string.table_name_prefix=tablePrefix
target.table.string.id.name=id_column
target.table.string.data.name=datum_column
target.table.string.timestamp.name=timestamp_column
target.table.string.id.type=VARCHAR
target.table.string.data.type=bytea
target.table.string.timestamp.type=BIGINT
target.key_to_string_mapper=org.infinispan.persistence.keymappers. DefaultTwoWayKey2StringMapper
Table 3.4. RocksDB Properties
PropertyDescriptionRequired/Optional

location

Sets the database directory.

Required

compression

Specifies the compression type to use.

Optional

# Example configuration for migrating from a RocksDB cache store.
source.type=ROCKSDB
source.cache_name=myCache
source.location=/path/to/rocksdb/database
source.compression=SNAPPY
Table 3.5. SingleFileStore Properties
PropertyDescriptionRequired/Optional

location

Sets the directory that contains the cache store .dat file.

Required

# Example configuration for migrating to a Single File cache store.
target.type=SINGLE_FILE_STORE
target.cache_name=myCache
target.location=/path/to/sfs.dat
Table 3.6. SoftIndexFileStore Properties
PropertyDescriptionValue

Required/Optional

location

Sets the database directory.

Required

index_location

Sets the database index directory.

# Example configuration for migrating to a Soft-Index File cache store.
target.type=SOFT_INDEX_FILE_STORE
target.cache_name=myCache
target.location=path/to/sifs/database
target.location=path/to/sifs/index

3.3. Migrating Data Grid cache stores

Run the store migrator to migrate data from one cache store to another.

Prerequisites

  • Get the Data Grid CLI.
  • Create a migrator.properties file that configures the source and target cache stores.

Procedure

  • Run the migrate store -p /path/to/migrator.properties CLI command

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.