Definition
If a group gets split for some reasons (e.g. network partition), this protocol merges the subgroups back into one group. It is only run by the coordinator (the oldest member in a cluster), and periodically multicasts its presence. If another coordinator (for the same group) receives this message, it will initiate a merge process. Note that this merges subgroups {A,B} and {C,D,E} back into {A,B,C,D,E}, but it does not merge state. The app has to handle the callback to merge state.
Configuration Example
<MERGE2 min_interval="5000" max_interval="10000" ></MERGE2>
Configuration Parameters
| Name | Description |
|---|---|
| id | Give the protocol a different ID if needed so we can have multiple instances of it in the same stack |
| inconsistent_view_threshold | Number of inconsistent views with only 1 coord after a MERGE event is sent up |
| level | Sets the logger level (see javadocs) |
| max_interval | Maximum time in ms between runs to discover other clusters |
| min_interval | Minimum time in msbetween runs to discover other clusters |
| name | Give the protocol a different name if needed so we can have multiple instances of it in the same stack |
| stats | Determines whether to collect statistics (and expose them via JMX). Default is true |
See also Protocol Configuration Common Parameters.
Notes
MERGE2 and TCPPING
If MERGE2 is used in conjunction with TCPPING, the attribute must contain all the nodes that could potentially be merged back, in order for the merge process to work properly. Otherwise, the merge process would not merge all the nodes even though Shunning is disabled. Alternatively use MPING, which is commonly used with TCP to provide multicast member discovery capabilities, instead of TCPPING to avoid having to specify all the nodes.
Selection of Coordinator Following Merge
Following a merge, the coordinator of the merged group can shift from the typical case of "the coordinator is the member who has been up the longest." During the merge process, the coordinators of the various subgroups need to reach a common decision as to who the new coordinator is. In order to ensure a consistent result, each coordinator combines the addresses of all the members in a list and then sorts the list. The first member in the sorted list becomes the coordinator. The sort order is determined by how the address implements the interface. The JGroups compare based on the and then the port. So, take a hypothetical case where two machines were running, with one machine running three separate cluster members and the other two members. If communication between the machines were cut, the following subgroups would form:
{192.168.0.99:7802,192.168.0.99:7801} and {192.168.0.100:7801,192.168.0.100:7803,192.168.0.100:7802}
Following the merge, the new view would be:
{192.168.0.99:7801,192.168.0.99:7802,192.168.0.100:7801,192.168.0.100:7802,192.168.0.100:7803}
with 192.168.0.99:7801 as coordinator.
Comments