Using Member Groups
Pivotal GemFire allows you to organize your cluster members into logical member groups.
The use of member groups in Pivotal GemFire is optional. The benefit of using member groups is the ability to coordinate certain operations on members based on logical group membership. For example, by defining and using member groups you can:
- Alter a subset of configuration properties for a specific member or members. See alter runtime in
- Perform certain disk operations like disk-store compaction across a member group. See Disk Store Commands for a list of commands.
- Manage specific indexes or regions across all members of a group.
- Start and stop multi-site (WAN) services such as gateway senders and gateway receivers across a member group.
- Deploy or undeploy JAR applications on all members in a group.
- Execute functions on all members of a specific group.
You define group names in the
groups property of your member’s
gemfire.properties file or upon member startup in
Any roles defined in the currently existing
roles property will now be considered a group. If you wish to add membership roles to your cluster, you should add them as member groups in the
groups property. The
roles property has been deprecated in favor of using the
To add a member to a group, add the name of a member group to the
gemfire.properties file of the member prior to startup or you can start up a member in
gfsh and pass in the
--groups argument at startup time.
A single member can belong to more than one group.
Member groups can also be used to organize members from either a client’s perspective or from a peer member’s perspective. See Organizing Peers into Logical Member Groups and Organizing Servers Into Logical Member Groups for more information. On the client side, you can supply the member group name when configuring a client’s connection pool. Use the <pool server-group> element in the client’s cache.xml.