Migrating Data from IMDG 3.12.x

The first step is to setup the 3.12.x cluster. You can also use your existing 3.12.x clusters. The members of the 3.12.x cluster should have a minor version of at least 3.12 (any patch version). You need to setup WAN replication between the 3.12.x and 5.x clusters as stated in the 3rd step below.

Next, setup a 4.x or 5.x cluster. It must have at least one migration member and all other (plain) members should be 5.x. The migration member can also be a "lite" member while the other plain members need not be. Making the migration member a "lite" member will also simplify further migration steps. The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation rate on the source cluster, the WAN tuning parameters, the resources given to the 5.x cluster members, the load on the 5.x cluster that isn’t related to the migration process, if migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.

Add WAN replication between the two clusters. As always, this can be done using the static configuration and can be added dynamically. The key point is that the 3.12.x cluster needs to replicate only to the migration members of the 5.x cluster. Other plain members are unable to process messages from 3.12.x members and WAN replication must not replicate to these members. Other than that, the WAN replication configuration on the 3.12.x cluster is the same as any other WAN replication towards a 3.12.x cluster and no special configuration is needed. See also the WAN Replication section for the details.

After the clusters have been started and WAN replication has been added, you can use WAN sync for IMap or wait until enough entries have been replicated in case of IMap or ICache.

After enough data has been replicated to the 5.x cluster, you can shut down the 3.12.x cluster. You can check if your map data is in sync by using merkle tree sync with the caveat that in some edge cases, the merkle tree consistency check may indicate that the clusters are out-of-sync while in reality they are actually in-sync. In other cases, once WAN sync completes successfully and if there are no errors, the map data should be synchronized. See Limitations and Known Issues section for more information when using merkle trees for consistency checks.

Finally, you can shut down the 5.x migration members, or do a rolling restart of these members to plain members. If your 5.x cluster was comprised entirely out of migration members, you must do a rolling restart of the entire cluster. At this point, the 5.x cluster has only plain members. You can also continue using this cluster or continue onto rolling upgrade to 5.x, for instance.

The first step is to set up the 5.x cluster. You can also use an existing 5.x cluster. You need to set up WAN replication between the 5.x cluster and the 3.12.x cluster but this will be described soon.

Next, set up a 3.12.x cluster. It must have at least one migration member and all other (plain) members should have a version of 3.12 (any patch level). The migration member can also be a "lite" member while other plain members need not be. Making the migration member a "lite" member will also simplify further migration steps. The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation rate on the source cluster, the WAN tuning parameters, the resources given to the 3.12.x cluster members, the load on the 3.12.x cluster which isn’t related to the migration process, if migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.

Set up WAN replication between the two clusters. As always, this can be done using static configuration and can be added dynamically. The key point is that the 5.0 cluster needs to replicate only to the migration members of the 3.12.x cluster. Other plain members are unable to process messages from 5.x members and WAN replication must not replicate to these members. Other than that, the WAN replication configuration on the 5.x cluster is the same as any other WAN replication towards a 5.x cluster and no special configuration is needed.

After the clusters have been started and WAN replication has been added, you can use WAN sync for IMap or wait until enough entries have been replicated in case of IMap or ICache.You can check if your map data is in sync by using merkle tree sync with the caveat that in some edge cases, the merkle tree consistency check may indicate that the clusters are out-of-sync while in reality they are actually in-sync. In other cases, once WAN sync completes successfully and if there are no errors, the map data should be synchronized. See Limitations and Known Issues section for more information when using merkle trees for consistency checks.

After enough data has been replicated to the 3.12.x cluster, you can shut down the 5.x cluster.

Finally, you can simply shut down the 3.12.x migration members or do a rolling restart of these members to plain members. If your 3.12.x cluster was comprised entirely out of migration members, you must do a rolling restart of the entire cluster. At this point, the 3.12.x cluster has only plain members.

The first step is to set up the 3.12.x and 5.x clusters. You can also use existing clusters. Each of these clusters must have at least one migration member. The migration member can also be a "lite" member while other plain members need not be. Making the migration member a "lite" member also simplifies further migration steps. Other plain members of the 3.12/4.x cluster can be of any patch version. The exact ratio of migration and plain members depends on your environment. In some cases, it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters, such as the map and cache mutation rate on the source cluster, the WAN tuning parameters, the resources given to the cluster members, the load on the clusters which isn’t related to the migration process, if migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.

Setup WAN replication between the two clusters. As always, this can be done using static configuration and can be added dynamically. The key point is that both clusters need to replicate only to the migration members and not to the plain ones as they are unable to process messages from the members of another major version. Other than that, the WAN replication configuration is the same as any other regular WAN replication towards clusters of the same major version and no special configuration is needed.

After the clusters have been started and WAN replication has been added, you can use WAN sync for IMap or wait until enough entries have been replicated in case of IMap or ICache. You can check if your map data is in sync by using merkle tree sync with the caveat that in some edge cases, the merkle tree consistency check may indicate that the clusters are out-of-sync while in reality they are actually in-sync. In other cases, once WAN sync completes successfully and if there are no errors, the map data should be synchronized. See Limitations and Known Issues section for more information when using merkle trees for consistency checks.

After enough data has been replicated, you can shut down either of the clusters and afterwards shut down the remaining migration members or do a rolling restart of these members to plain members. If any of the clusters that you are keeping is comprised entirely out of migration members, you will need to do a rolling restart of the entire cluster.

If you are connecting members of different major versions, the recipient/target of the connection must be a migration member and not a plain member.

If a cluster contains a migration member, it may also contain plain members but with the added restriction that 4.x plain members should be at least 4.0.2 and at most 4.2 (any patch version). The 3.12.x plain members can be of any patch version. Once migration has finished and migration members have been shut down, this restriction is lifted.

If the cluster is a source/active/sender cluster replicating towards another cluster of another major version, the source cluster must be of the minor versions 3.12 and 5.x. The patch level is irrelevant, unless the source cluster is also a target cluster for another WAN replication, where must adhere to the first two rules.