| --- |
| title: Using Member Groups |
| --- |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <%=vars.product_name_long%> allows you to organize your cluster members into logical member groups. |
| |
| The use of member groups in <%=vars.product_name_long%> 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](../../tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) in `gfsh`. |
| - Perform certain disk operations like disk-store compaction across a member group. See [Disk Store Commands](../../tools_modules/gfsh/quick_ref_commands_by_area.html#topic_1ACC91B493EE446E89EC7DBFBBAE00EA) 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 `gfsh`. |
| |
| **Note:** |
| 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 `groups` property. |
| |
| 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](../../topologies_and_comm/p2p_configuration/configuring_peer_member_groups.html) and [Organizing Servers Into Logical Member Groups](../../topologies_and_comm/cs_configuration/configure_servers_into_logical_groups.html) 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. |
| |
| |