Partition definitions can be changed at any time on a running system without impacting application availability. These changes include:
This class of changes is called partition migration because they may cause object data to be moved between nodes. The rest of this section shows an example of adding a new replica node to a partition to demonstrate partition migration.
The following steps are required to add a new replica node to an existing partition.
Migrate the partition to add the replica node.
Partitions can be automatically modified by the application
or manually by the administrator. Figure 6.12, “Migrating a partition”
shows the definition of Partition 1 being migrated to
add a new asynchronous replica node C. The partition
migration dialog is accessed from the partition details screen. In
addition to changing the active and replica nodes for a partition, these
partition properties can be set in the migration partition dialog:
Replica Nodes - Whether to force synchronization or not of replica nodes during a migration.
Objects per Transaction - Number of objects to migrate per transaction.
Number of Threads - Number of threads to use for object migration.
Sparse Audit Node List - Verify node list if migrating a sparse partition.
Replica Audit - Replica node audit to be used during the migration.
![[Note]](images/note.png) | |
These partitions properties are only used for this migration. They do not override the partition properties set when the partition was defined. |
When the dialog is submitted, the partition definition is updated in
the cluster and object data is copied from the current active node
(A) to the new replica C.
Partition migration can also be triggered using this command. This command must be executed on the current active node for the partition.
administrator servicename=A migrate partition name="XX" activenode=A replicas=B,C replicatypes=synchronous,asynchronous