Core group coordinator
Every core group has a coordinator that manages high availability activities between the core group members. The coordinator manages the failover of highly available singleton services and distributes live server state data to interested core group members. The coordinator uses some CPU and memory (JVM heap) resources to perform these tasks. In some configurations, the amount of resources that the coordinator uses might be large.
The coordinator workload can be divided over multiple coordinator instances. Each instance runs on a different core group member and is assigned a portion of the overall coordination workload. Dividing the workload across multiple coordinator instances enables us to share the associated resource costs across machines. The coordinator function remains highly available, regardless of how its workload is divided or assigned to core group members.
Coordinator election
When a core group member starts or stops, the View Synchrony Protocol installs a new view. The view consists of the core group members connected and cooperating. Whenever a new view is installed, it might be necessary to redivide the coordinator workload among the core group members. For example, a core group member hosting a coordinator instance might fail and the high availability manager must elect a replacement coordinator.
Informational messages, similar to the following message, are logged in the SystemOut.log file when a particular core group member is elected as a coordinator:
- HMGR0206I: The coordinator is an active coordinator for core group DefaultCoreGroup
Messages, similar to the following message, are logged if a core group member is no longer an elected coordinator:
- HMGR0207I: The coordinator was previously an active coordinator for core group DefaultCoreGroup but has lost leadership.
Remember that coordinator election occurs whenever the view changes. Electing a new coordinator uses a lot of resources because this process causes increased network traffic and CPU consumption. Specifying a preferred coordinator server, whenever practical, helps eliminate the need to make frequent coordinator changes.
Multiple coordinators
The core group configuration data contains a field in which users can specify the number of coordinators. The default is 1. This default value is sufficient for most installations and applications. Use multiple coordinators when the core group member selected as the coordinator uses noticeably more memory or CPU than similar core group members. In addition, some software products that heavily use the high availability framework instruct you to increase the number of coordinators.
Preferred servers
When we configure a core group, we can specify the core group members the high availability manager should use as coordinators, if they are available. Preferred coordinator servers should be core group processes that are cycled as infrequently as possible. The preferred coordinator servers should also be hosted on machines with excess capacity.
Specifying preferred coordinator servers is a good practice. When coordinators are elected during a view change, the high availability manager checks for a list of preferred servers. If there is a list, the high availability manager selects a server from that list as the coordinator. If there is no list, the high availability manager selects the view member with the lexically lowest name as the coordinator, which incurs some overhead if it causes the coordinator to move.
Related: