|Developing with Pivotal GemFire / Partitioned Regions|
In a distributed system with minimal contention to the concurrent threads reading or updating from the members, you can use rebalancing to dynamically increase or decrease your data and processing capacity.
For efficiency, when starting multiple members, trigger the rebalance a single time, after you have added all members.
gfsh>rebalanceOptionally, you can specify regions to include or exclude from rebalancing, specify a time-out for the rebalance operation or just simulate a rebalance operation. Type help rebalance or see rebalance for more information.
ResourceManager manager = cache.getResourceManager(); RebalanceOperation op = manager.createRebalanceFactory().start(); //Wait until the rebalance is complete and then get the results RebalanceResults results = op.getResults(); //These are some of the details we can get about the run from the API System.out.println("Took " + results.getTotalTime() + " milliseconds\n"); System.out.println("Transfered " + results.getTotalBucketTransferBytes()+ "bytes\n");
ResourceManager manager = cache.getResourceManager(); RebalanceOperation op = manager.createRebalanceFactory().simulate(); RebalanceResults results = op.getResults(); System.out.println("Rebalance would transfer " + results.getTotalBucketTransferBytes() +" bytes "); System.out.println(" and create " + results.getTotalBucketCreatesCompleted() + " buckets.\n");
The rebalancing operation runs asynchronously.
As a general rule, rebalancing is performed on one partitioned region at a time. For regions that have co-located data, the rebalancing works on the regions as a group, maintaining the data co-location between the regions.
You can continue to use your partitioned regions normally while rebalancing is in progress. Read operations, write operations, and function executions continue while data is moving. If a function is executing on a local data set, you may see a performance degradation if that data moves to another host during function execution. Future function invocations are routed to the correct member.
GemFire tries to ensure that each member has the same percentage of its available space used for each partitioned region. The percentage is configured in the partition-attributes local-max-memory setting.
You typically want to trigger rebalancing when capacity is increased or reduced through member startup, shut down or failure.