Configure Member Join Redundancy Recovery for a Partitioned Region
Configure whether and how redundancy is recovered in a partition region after a member joins.
|startup-recovery-delay partition attribute||Effect following a member join|
|-1||No automatic recovery of redundancy after a new member comes online. If you use this and the default
|long greater than or equal to 0||Number of milliseconds to wait after a member joins before before recovering redundancy. The default is 0 (zero), which causes immediate redundancy recovery whenever a new partitioned region host joins.|
Setting this to a value higher than the default of 0 allows multiple new members to join before redundancy recovery kicks in. With the multiple members present during recovery, the system will spread redundancy recovery among them. With no delay, if multiple members are started in close succession, the system may choose only the first member started for most or all of the redundancy recovery.
Note: Satisfying redundancy is not the same as adding capacity. If redundancy is satisfied, new members do not take buckets until you invoke a rebalance.
With parallel recovery introduced in version 8.2, redundancy may be recovered more quickly than in previous versions. For this reason, it is even more important to configure
startup-recovery-delay to an appropriate value if you intend to restart multiple members at once. Set
startup-recovery-delay to a value that ensures all members are up and available before redundancy recovery kicks in.
Set join redundancy recovery using one of the following:
// Wait 5 seconds after a new member joins before // recovering redundancy <region name="PR1"> <region-attributes refid="PARTITION"> <partition-attributes startup-recovery-delay="5000"/> </region-attributes> </region>
PartitionAttributes pa = new PartitionAttributesFactory().setStartupRecoveryDelay(5000).create();
gfsh>create region --name="PR1" --type=PARTITION --startup-recovery-delay=5000