Upgrading Data Grid
Data Grid Documentation
Abstract
Chapter 1. Red Hat Data Grid Copy linkLink copied to clipboard!
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.
1.1. Data Grid Documentation Copy linkLink copied to clipboard!
Documentation for Data Grid is available on the Red Hat customer portal.
1.2. Data Grid Downloads Copy linkLink copied to clipboard!
Access the Data Grid Software Downloads on the Red Hat customer portal.
You must have a Red Hat account to access and download Data Grid software.
Chapter 2. Migrating to Data Grid 8.0 Copy linkLink copied to clipboard!
Review changes in Data Grid 8.0 that affect migration from previous releases.
2.1. Data Grid 8.0 Server Copy linkLink copied to clipboard!
As of 8.0, Data Grid server is no longer based on Red Hat JBoss Enterprise Application Platform (EAP) and is re-designed to be lightweight and more secure with much faster start times.
Data Grid servers use $RHDG_HOME/server/conf/infinispan.xml for configuration.
Data store configuration
You configure how Data Grid stores your data through cache definitions. By default, Data Grid servers include a Cache Manager configuration that lets you create, configure, and manage your cache definitions.
In the preceding configuration, there are no cache definitions. When you start 8.0 server, it instantiates the default Cache Manager so you can create cache definitions at runtime through the CLI, REST API, or from remote Hot Rod clients.
Data Grid server no longer provides a domain mode as in previous versions that were based on EAP. However, Data Grid server provides a default configuration with clustering capabilities so your data is replicated across all nodes.
Server configuration
Data Grid 8.0 extends infinispan.xml with a server element that defines configuration specific to Data Grid servers.
- 1
- Creates a default public interface that uses the
127.0.0.1loopback address. - 2
- Creates a default socket binding that binds the public interface to port
11222. - 3
- Creates a socket binding for the Memcached connector. Note that the Memcached endpoint is now deprecated.
- 4
- Defines a default security realm that uses property files to define credentials and RBAC settings.
- 5
- Exposes the Hot Rod and REST endpoints at
127.0.0.1:11222.ImportantThe REST endpoint handles administrative operations that the Data Grid command line interface (CLI) and console use. For this reason, you should never disable the REST endpoint.
| 7.x | 8.x |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use custom UDP/TCP addresses as follows:
-Djgroups.udp.address=172.18.1.13-Djgroups.tcp.address=172.18.1.1Enable JMX as follows:
<cache-container name="default" statistics="true"> <jmx enabled="true" /> ...<cache-container name="default" statistics="true">1 <jmx enabled="true" />2 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Reference
2.2. Data Grid Caches Copy linkLink copied to clipboard!
Except for the Cache service on OpenShift, Data Grid provides empty cache containers by default. When you start Data Grid 8.0 it instantiates a Cache Manager so you can create caches at runtime.
In Data Grid 8.0, cache definitions that you create through the CacheContainerAdmin API are permanent to ensure that they survive cluster restarts.
.administration()
.withFlags(AdminFlag.VOLATILE)
.getOrCreateCache("myTemporaryCache", "org.infinispan.DIST_SYNC");
.administration()
.withFlags(AdminFlag.VOLATILE)
.getOrCreateCache("myTemporaryCache", "org.infinispan.DIST_SYNC");
AdminFlag.PERMANENT is enabled by default to ensure that cache definitions survive restarts. You must separately add persistent storage to Data Grid for data to survive restarts, for example:
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore()
.location("/tmp/myDataStore")
.maxEntries(5000);
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore()
.location("/tmp/myDataStore")
.maxEntries(5000);
Cache Configuration Templates
Get the list of cache configuration templates as follows:
Use
Tabauto-completion with the CLI:[//containers/default]> create cache --template=
[//containers/default]> create cache --template=Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the REST API:
GET 127.0.0.1:11222/rest/v2/cache-managers/default/cache-configs/templates
GET 127.0.0.1:11222/rest/v2/cache-managers/default/cache-configs/templatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. Creating Caches Copy linkLink copied to clipboard!
Add cache definitions to Data Grid to configure how it stores your data.
Library Mode
The following example initializes the Cache Manager and creates a cache definition named "myDistributedCache" that uses the distributed, synchronous cache mode:
GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder();
DefaultCacheManager cacheManager = new DefaultCacheManager(global.build());
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.clustering().cacheMode(CacheMode.DIST_SYNC);
cacheManager.defineConfiguration("myDistributedCache", builder.build());
GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder();
DefaultCacheManager cacheManager = new DefaultCacheManager(global.build());
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.clustering().cacheMode(CacheMode.DIST_SYNC);
cacheManager.defineConfiguration("myDistributedCache", builder.build());
You can also use the getOrCreate() method to create your cache definition or return it if it already exists, for example:
cacheManager.administration().getOrCreateCache("myDistributedCache", builder.build());
cacheManager.administration().getOrCreateCache("myDistributedCache", builder.build());
Data Grid Server
Remotely create caches at runtime as follows:
Use the CLI.
To create a cache named "myCache" with the
DIST_SYNCcache template, run the following:[//containers/default]> create cache --template=org.infinispan.DIST_SYNC name=myDistributedCache
[//containers/default]> create cache --template=org.infinispan.DIST_SYNC name=myDistributedCacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the REST API.
To create a cache named "myCache", use the following
POSTinvocation and include the cache definition in the request payload in XML or JSON format:POST /rest/v2/caches/myCache
POST /rest/v2/caches/myCacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use Hot Rod clients.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
For more examples of creating caches with a Hot Rod Java client, see the Data Grid tutorials.
2.4. Cache Health Status Copy linkLink copied to clipboard!
Data Grid now returns one of the following for cache health:
HEALTHY means a cache is operating as expected.HEALTHY_REBALANCING means a cache is in the rebalancing state but otherwise operating as expected.DEGRADED indicates a cache is not operating as expected and possibly requires troubleshooting.
2.5. Marshalling Capabilities Copy linkLink copied to clipboard!
As of this release, the default marshaller for Data Grid is ProtoStream, which marshalls data as Protocol Buffers, a language-neutral, backwards compatible format.
To use ProtoStream, Data Grid requires serialization contexts that contain:
-
.protoschemas that provide a structured representation of your Java objects as Protobuf message types. - Marshaller implementations to encode your Java objects to Protobuf format.
Data Grid provides direct integration with ProtoStream libraries and can generate everything you need to initialize serialization contexts.
Cache stores in previous versions of Data Grid store data in a binary format that is not compatible with ProtoStream marshallers. You must use the StoreMigrator utility to migrate your data.
-
Data Grid Library Mode does not include JBoss Marshalling by default. You must add the
infinispan-jboss-marshallingdependency to your classpath. Data Grid servers do support JBoss Marshalling but clients must declare the marshaller to use, as in the following Hot Rod client configuration:
.marshaller("org.infinispan.jboss.marshalling.core.JBossUserMarshaller");- Spring integration does not yet support the default ProtoStream marshaller. For this reason you should use the Java Serialization Marshaller.
- To use the Java Serialization Marshaller, you must add classes to the deserialization whitelist.
2.6. Data Grid Configuration Copy linkLink copied to clipboard!
New and Modified Elements and Attributes
-
stackadds support for inline JGroups stack definitions. -
stack.combineandstack.positionattributes let you override and modify JGroups stack definitions. -
metricslets you configure how Data Grid exports metrics that are compatible with the Eclipse MicroProfile Metrics API. -
context-initializerlets you specify aSerializationContextInitializerimplementation that initializes a Protostream-based marshaller for user types. -
key-transformerslets you register transformers that convert custom keys to String for indexing with Lucene. -
statisticsnow defaults to "false".
Deprecated Elements and Attributes
The following elements and attributes are now deprecated:
-
address-countattribute for theoff-heapelement. -
protocolattribute for thetransactionelement. -
duplicate-domainsattribute for thejmxelement. -
advanced-externalizer -
custom-interceptors -
state-transfer-executor -
transaction-protocol
Refer to the Configuration Schema for possible replacements or alternatives.
Removed Elements and Attributes
The following elements and attributes were deprecated in a previous release and are now removed:
-
deadlock-detection-spin -
compatibility -
write-skew -
versioning -
data-container -
eviction -
eviction-thread-policy
2.7. Persistence Copy linkLink copied to clipboard!
In comparison with some previous versions of Data Grid, such as 7.1, there are changes to cache store configurations. Cache store definitions must:
-
Be contained within
persistenceelements. -
Include an
xlmnsnamespace.
As of this release, cache store configuration:
-
Defaults to
segmented="true"if the cache store implementation supports segmentation. -
Removes the
singletonattribute for thestoreelement. Useshared=trueinstead.
JDBC String-Based cache stores use connections factories based on Agroal to connect to databases. It is no longer possible to use c3p0.properties and hikari.properties files.
Likewise, JDBC String-Based cache store configuration that use segmentation, which is now the default, must include the segmentColumnName and segmentColumnType parameters.
MySQL Example
PostgreSQL Example
2.8. REST API Copy linkLink copied to clipboard!
Previous versions of the Data Grid REST API were v1, which is now replaced by REST API v2.
The default context path is now 127.0.0.1:11222/rest/v2/. You must update any clients or scripts to use REST API v2.
Reference
2.9. Hot Rod Client Authentication Copy linkLink copied to clipboard!
Hot Rod clients now use SCRAM-SHA-512 as the default authentication mechanism instead of DIGEST-MD5.
If you use property security realms, you must use the PLAIN authentication mechanism.
2.10. Java Distributions Available in Maven Copy linkLink copied to clipboard!
Data Grid no longer provides Java artifacts outside the Maven repository, with the exception of the Data Grid server distribution. For information on adding required dependencies for the Data Grid Library, Hot Rod Java client, and utilities such as StoreMigrator, see the relevant documentation.
2.11. Red Hat JBoss Enterprise Application Platform (EAP) Modules Copy linkLink copied to clipboard!
Data Grid no longer provides modules for applications running on EAP. Instead, EAP will provide direct integration with Data Grid in a future release.
However, until EAP provides functionality for handling the infinispan subsystem, you must package Data Grid 8.0 artifacts in your EAP deployments.
2.12. Deprecated Features and Functionality Copy linkLink copied to clipboard!
Support for deprecated functionality is not available beyond the release in which it is deprecated.
Red Hat does not recommend including, enabling, or configuring deprecated functionality in new deployments.
2.12.1. Deprecations Copy linkLink copied to clipboard!
Data Grid 8.0 deprecates the following features and functionality:
Memcached Endpoint Connector
As of this release, Data Grid no longer supports the Memcached endpoint. The Memcached connector is deprecated and planned for removal in a future release.
If you have a use case or requirement for the Memcached connector, contact your Red Hat support team to discuss requirements for a future Data Grid implementation of the Memcached connector.
JBoss Marshalling
JBoss Marshalling is a Serialization-based marshalling library and was the default marshaller in previous Data Grid versions. You should not use serialization-based marshalling with Data Grid but instead use Protostream, which is a high-performance binary wire format that ensures backwards compatibility.
Externalizers
The following interfaces and annotations are now deprecated:
-
org.infinispan.commons.marshall.AdvancedExternalizer -
org.infinispan.commons.marshall.Externalizer -
@SerializeWith
Data Grid ignores AdvancedExternalizer implementations when persisting data unless you use JBoss Marshalling.
Total Order Transaction Protocol
The org.infinispan.transaction.TransactionProtocol#TOTAL_ORDER protocol is deprecated. Use the default 2PC protocol instead.
Lucene Directory
The functionality to use Data Grid as a shared, in-memory index for Hibernate Search queries is now deprecated.
Custom Interceptors
The functionality to create custom interceptors with the AdvancedCache interface is now deprecated.
2.12.2. Removed Features and Functionality Copy linkLink copied to clipboard!
Data Grid 8.0 no longer includes the following features and functionality that was either deprecated in a previous release or replaced with new components:
- Uberjars (replaced with Maven dependencies and individual JAR files)
- EAP Modules (replaced by the EAP Infinispan subsystem)
- Cassandra Cache Store
- Apache Spark Connector
- Apache Hadoop Connector
-
Apache Camel component:
jboss-datagrid-camel-libraryis replaced by thecamel-infinispancomponent in Red Hat Fuse 7.3 and later. - REST Cache Store
- REST API v1 (replaced by REST API v2)
- Compatibility Mode
- Distributed Execution
- CLI Cache Loader
- LevelDB Cache Store
-
infinispan-cloud(replaced by default configuration ininfinispan-core) -
org.infinispan.atomicpackage -
getBulk()methods in theRemoteCacheAPI for Hot Rod clients - JDBC PooledConnectionFactory via C3P0 and HikariCP connection pools
- OSGI support
-
infinispan.server.hotrod.workerThreadssystem property - JON Plugin
Chapter 3. Performing Rolling Upgrades for Data Grid Servers Copy linkLink copied to clipboard!
Perform rolling upgrades of your Data Grid clusters to change between versions without downtime or data loss. Rolling upgrades migrate both your Data Grid servers and your data to the target version over Hot Rod.
3.1. Setting Up Target Clusters Copy linkLink copied to clipboard!
Create a cluster that runs the target Data Grid version and uses a remote cache store to load data from the source cluster.
Prerequisites
- Install a Data Grid cluster with the target upgrade version.
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 specify port offsets to keep the target and source clusters separate.
Procedure
Add a
RemoteCacheStoreon the target cluster for each cache you want to migrate from the source cluster.Remote cache stores use the Hot Rod protocol to retrieve data from remote Data Grid clusters. When you add the remote cache store to the target cluster, it can lazily load data from the source cluster to handle client requests.
Switch clients over to the target cluster so it starts handling all requests.
- Update client configuration with the location of the target cluster.
- Restart clients.
3.1.1. Remote Cache Stores for Rolling Upgrades Copy linkLink copied to clipboard!
You must use specific remote cache store configuration to perform rolling upgrades, as follows:
- 1
- Disables passivation. Remote cache stores for rolling upgrades must disable passivation.
- 2
- Matches the name of a cache in the source cluster. Target clusters load data from this cache using the remote cache store.
- 3
- Matches the Hot Rod protocol version of the source cluster.
2.5is the minimum version and is suitable for any upgrade paths. You do not need to set another Hot Rod version. - 4
- Ensures that entries are wrapped in a suitable format for the Hot Rod protocol.
- 5
- Stores data in the remote cache store in raw format. This ensures that clients can use data directly from the remote cache store.
- 6
- Points to the location of the source cluster.
3.2. Synchronizing Data to Target Clusters Copy linkLink copied to clipboard!
When your target cluster is running and handling client requests using a remote cache store to load data on demand, you can synchronize data from the source cluster to the target cluster.
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 in your Data Grid configuration.
Procedure
Start the synchronization operation for each cache in your Data Grid configuration that you want to migrate to the target cluster.
Use the Data Grid REST API and invoke
GETrequests with the?action=sync- dataparameter. For example, to synchronize data in a cache named "myCache" from a source cluster to a target cluster, do the following:GET /v2/caches/myCache?action=sync-data
GET /v2/caches/myCache?action=sync-dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow When the operation completes, Data Grid responds with the total number of entries copied to the target cluster.
Alternatively, you can use JMX by invoking
synchronizeData(migratorName=hotrod)on theRollingUpgradeManagerMBean.Disconnect each node in the target cluster from the source cluster.
For example, to disconnect the "myCache" cache from the source cluster, invoke the following
GETrequest:GET /v2/caches/myCache?action=disconnect-source
GET /v2/caches/myCache?action=disconnect-sourceCopy to Clipboard Copied! Toggle word wrap Toggle overflow To use JMX, invoke
disconnectSource(migratorName=hotrod)on theRollingUpgradeManagerMBean.
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 4. Migrating Data Between Cache Stores Copy linkLink copied to clipboard!
Data Grid provides a Java utility for migrating persisted 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.
4.1. Cache Store Migrator Copy linkLink copied to clipboard!
Data Grid provides the StoreMigrator.java utility that recreates data for the latest Data Grid cache store implementations.
StoreMigrator takes a cache store from a previous version of Data Grid as source and uses a cache store implementation as target.
When you run StoreMigrator, it creates the target cache with the cache store type that you define using the EmbeddedCacheManager interface. StoreMigrator then loads entries from the source store into memory and then puts them into the target cache.
StoreMigrator 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 Single File cache store.
StoreMigrator cannot migrate data from segmented cache stores to:
- Non-segmented cache store.
- Segmented cache stores that have a different number of segments.
4.2. Getting the Store Migrator Copy linkLink copied to clipboard!
StoreMigrator is available as part of the Data Grid tools library, infinispan-tools, and is included in the Maven repository.
Procedure
Configure your
pom.xmlforStoreMigratoras follows:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. Configuring the Store Migrator Copy linkLink copied to clipboard!
Set properties for source and target cache stores in a migrator.properties file.
Procedure
-
Create a
migrator.propertiesfile. Configure the source cache store in
migrator.properties.Prepend all configuration properties with
source.as in the following example:source.type=SOFT_INDEX_FILE_STORE source.cache_name=myCache source.location=/path/to/source/sifs
source.type=SOFT_INDEX_FILE_STORE source.cache_name=myCache source.location=/path/to/source/sifsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Configure the target cache store in
migrator.properties.Prepend all configuration properties with
target.as in the following example:target.type=SINGLE_FILE_STORE target.cache_name=myCache target.location=/path/to/target/sfs.dat
target.type=SINGLE_FILE_STORE target.cache_name=myCache target.location=/path/to/target/sfs.datCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.1. Store Migrator Properties Copy linkLink copied to clipboard!
Configure source and target cache stores in a StoreMigrator properties.
| Property | Description | Required/Optional |
|---|---|---|
|
| Specifies the type of cache store type for a source or target.
| Required |
| Property | Description | Example Value | Required/Optional |
|---|---|---|---|
|
| Names the cache that the store backs. |
| Required |
|
| Specifies the number of segments for target cache stores that can use segmentation.
The number of segments must match In other words, the number of segments for a cache store must match the number of segments for the corresponding cache. If the number of segments is not the same, Data Grid cannot read data from the cache store. |
| Optional |
| Property | Description | Required/Optional |
|---|---|---|
|
| Specifies the dialect of the underlying database. | Required |
|
| Specifies the marshaller version for source cache stores. Set one of the following values:
*
*
* | Required for source stores only.
For example: |
|
| Specifies a custom marshaller class. | Required if using custom marshallers. |
|
|
Specifies a comma-separated list of custom | Optional |
|
| Specifies the JDBC connection URL. | Required |
|
| Specifies the class of the JDBC driver. | Required |
|
| Specifies a database username. | Required |
|
| Specifies a password for the database username. | Required |
|
| Sets the database major version. | Optional |
|
| Sets the database minor version. | Optional |
|
| Disables database upsert. | Optional |
|
| Specifies if table indexes are created. | Optional |
|
| Specifies additional prefixes for the table name. | Optional |
|
| Specifies the column name. | Required |
|
| Specifies the column type. | Required |
|
|
Specifies the | Optional |
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
| Property | Description | Required/Optional |
|---|---|---|
|
| Sets the database directory. | Required |
|
| 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
# 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
| Property | Description | Required/Optional |
|---|---|---|
|
|
Sets the directory that contains the cache store | 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
# 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
| Property | Description | Value |
|---|---|---|
| Required/Optional |
| Sets the database directory. |
| Required |
| 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
# 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
4.4. Migrating Cache Stores Copy linkLink copied to clipboard!
Run StoreMigrator to migrate data from one cache store to another.
Prerequisites
-
Get
infinispan-tools.jar. -
Create a
migrator.propertiesfile that configures the source and target cache stores.
Procedure
If you build
infinispan-tools.jarfrom source, do the following:-
Add
infinispan-tools.jarand dependencies for your source and target databases, such as JDBC drivers, to your classpath. -
Specify
migrator.propertiesfile as an argument forStoreMigrator.
-
Add
If you pull
infinispan-tools.jarfrom the Maven repository, run the following command:mvn exec:java