Data Center Replication from GridGain 8
In certain environments, downtime associated with migrating data between GridGain versions cannot be afforded. For these scenarios, GridGain provides a one-way data migration tool based on GridGain 8 Data Center Replication. Data can be copied to your GridGain 9 cluster as if it was a GridGain 8 cluster running in a different data center, and afterwards the load can be seamlessly transferred to the GridGain 9 cluster.
Prerequisites
As Data Center Replication is only available in GridGain 8 Enterprise and Ultimate editions, you need to have the corresponding license to start replication process.
Before starting replication, you need to create an empty table the data will be written to. You will be able to manually configure what cache fields correspond to what table columns. If not specified, fields will be matched to columns with the same name.
Additionally, you must have created the nullable drVersion column of the VARBINARY data type in the target GridGain 9 table. This column will be used to store information about data center replication process and can be safely deleted once replication is no longer required. You cannot start replication without this column.
Limitations
The replication process between GridGain 8 and GridGain 9 has the following limitations:
-
There are differences in GridGain 9 and GridGain 8 support for data types. Make sure data is mapped to columns of equivalent types.
-
Only one-way replication from the master GridGain 8 to a replica GridGain 9 cluster is supported. Consequently, only active-passive replication is supported for this scenario.
-
You cannot transfer data to the GridGain 9 cluster by using full state transfer over snapshot.
-
Data can only be transferred from a single GridGain 8 cluster at a time.
-
GridGain 9 cluster being already under load may cause some data from the transfer being overwritten by new data. It is recommended to only transmit data to clusters not under load.
Conflict Resolution
In most scenarios, there should be no conflicts, as data should be copied to a fresh cluster. However, in some scenarios, there still may be conflicts. These are resolved as follows:
-
Any data from GridGain 9 cluster has priority and will not be overwritten.
-
If the same row already exists in the table, newly transferred data will always overwrite old data.
Failure Scenarios
If the replication is stopped for any reason, when it is restarted, full state transfer will be performed first, followed by incremental updates once data is fully synchronized.
Configuring Replication
Configuring replication to GridGain 9 cluster on GridGain 8 side is not different from configuring replication to GridGain 8 cluster. On GridGain 9 side, you need to start a connector tool that converts data from GridGain 8 and transfers it to GridGain 9.
Tombstone time-to-live, configured by using the tombstoneTtl configuration property, on receiving side must be same or greater than on sending side. By default, the same value is used in GridGain 8 and GridGain 9 (30 minutes).
Make sure to note the ID of the data center the master cluster is running in. This ID will be used in connector configuration to filter incoming connections.
Starting Connector Tool
To start the connector tool, use the start.sh script. You can provide the configuration for the script by using the config-path parameter and specifying the path to the Connector Configuration.
start.sh --config-path etc/example.confConnector Configuration
The connector configuration files should be using the HOCON format. Here is an example of configuration:
dr-service-config: {
cacheMapping: [
{
cache: "cache1",
table: "table1",
fields: [
{ field: "_key", column: "ID" },
{ field: "field1", column: "C1" },
{ field: "field2", column: "C2" }
]
}
]
clientConfiguration: {
serverEndpoints: [ "127.0.0.1:10800" ]
}
drReceiverConfiguration{
dataCenterId: 1,
inboundPort: 9090
}
}
The following fields are available:
| Property | Default | Description |
|---|---|---|
|
The name of the GridGain 8 cache on the master cluster. |
|
|
The name of the GridGain 9 table on the replica cluster. |
|
|
The array denoting the mapping of cache fields to table columns. |
|
|
The case-sensitive name of the source cache field to get data from. |
|
|
The case-sensitive name of the target column to write data to. |
|
|
The list of addresses of GridGain 9 nodes with configured client connectors. |
|
|
The port that the master GridGain 8 cluster will use to perform replication. |
|
|
The ID of the master GridGain 8 cluster’s datacenter. Only connections from this data center will be allowed. |
Starting Replication
Once the client connector is started, it will behave in the same way as a replica GridGain 8 cluster. Start replication as described in the GridGain 8 documentation.
Stopping Connector Tool
Once data replication is no longer needed (for example, the load was shifted to GridGain 9 cluster), stop the replication process on the GridGain 8 master cluster and then use the stop.sh script to stop the connector.
stop.sh© 2025 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.