Partitions support migration to different nodes without requiring system downtime. Partition migration is initiated using an administrator or an API on the current active node for the partition. The following changes can be made to a partition definition:
Change the priority of the node list, including the active node.
Add new nodes to the node list
Remove nodes from the node list
Update partition properties.
When the partition migration is initiated all object data is copied as required to support the updated partition definition, this may include changing the active node for the partition.
For example, these steps will the migrate the active node from A to C for partition P:
Node C defines partition P with a node list of C, B.
Node C enables the partition and partition P migrates to node C.
When the partition migration is complete, partition P is now active on node C with node B still the replica. Node A is no longer hosting this partition.
It is also possible to force replication to all replica nodes during a partition migration by setting the force replication property when initiating partition migration. Setting the force replication property will cause all replica nodes to be resynchronized with the active node during partition migration. In general forcing replication is not required since replica nodes resynchronize with the active node when partitions are defined and enabled on the replica node.