...

It might happen that some nodes were down (or were segmented from the main cluster segment) while the CMG repair was happening.

If a node is down and it needs to be migrated, it is preferred to use the ‘cold migration’ procedure [this was criticized on the PDC, so this is postponed].

Migrating running nodes

The user issues the ‘cluster migrate’ command via the CLI specifying --old-cluster-node and --new-cluster-node.

...

Migrating a stopped node (‘cold migration’)

[This was criticized on the PDC, so this feature is postponed]

If a node is stoppedIf some nodes are stopped and need to be migrated, it’s preferred to use this procedure instead of starting the node and then using the procedure for running nodes as this decreases the risk of a client writing something to the node before it gets migrated.

The user passes the following command line arguments on start:

• --migrate-target=<any-node-of-new-cluster>
• --migrate-cluster-id=<new-cluster-id>

If they are provided, the node changes the cluster ID it uses for the handshake procedure (just for this launch, it’s not persisted) before starting the networking, then obtains the cluster state from the --migrate-target, then forms a ClusterResetMessage, saves it to the Vault and restartsstart and migrate them one by one. This minimizes potential problems with clients accessing a node that was started just to be migrated.

Restarting a node

We will add a mechanism to restart a node in-process (that is, without stopping the current process and starting another one). IgniteServer already contains a reference to an IgniteImpl. The restart will stop the existing IgniteImpl and start another one, swapping the reference value.

...

1. IEP-77: Node Join Protocol and Initialization for Ignite 3
2. IEP-126: Table/zone disaster recovery

Tickets

// TODO