Table of Contents
So far in this book we have mostly discussed electable and secondary nodes, which are by definition nodes that have access to a JE ReplicatedEnvironment. However, replication groups can include any number of nodes that have no access to the JE replicated environment in use by the replication group.
These type of nodes without environments are called monitor nodes. The point of a monitor node is to allow a process to have some understanding of the replication group's structure such as which node is the Master and what nodes belong to the group as Replicas. Monitor nodes also have the ability to know when certain events have happened in the replication group, such as when a new Master is elected or when new nodes are added to, or removed from, the group.
There are many uses for Monitor nodes, starting with the ability to write processes that monitor the current status of your HA application. But another, arguably more interesting, use for Monitor nodes is for request routing. As we have explained earlier in this book, Replicas can only service read-only requests; all write requests must occur on the Master. However, Replicas are only capable of noticing that they have been asked to process a write request. At most, out of the box, they can complain about it by throwing a ReplicaWriteException, and then completely rejecting the request.
One way to handle this problem is by writing an request router that sits on your network between the data nodes and your clients. This router can send write requests to the Master, and read requests to the Replicas. A robust example of this sort of thing could also perform load balancing across the various Replicas, so that no one Replica becomes swamped by too many read requests.
You implement Monitor nodes using the Monitor class. The
Monitor class allows you to obtain
information about the replication group, such as its name,
where the Master is, and other such information. The
Monitor class also allows you to run an
event listener that can alert you to changes in the composition
of the replication group.
You instantiate a Monitor class object
in much the same way as you instantiate a
ReplicatedEnvironment class object. It is necessary to give
the node a name, to indicate that it is a Monitor node, to
identify the node's host and port information, and to identify
helper hosts. You use a MonitorConfig object to do these
things.
Once the Monitor object has been
instantiated, it must be registered at least once with the
Master so that the replication group will know to keep the node
informed about changes in the group composition. (Subsequent
attempts to register the node are simply ignored by the
Master.) You use the Monitor.register() method to register a
Monitor node with a Master.
For example:
// Initialize the monitor node config
MonitorConfig config = new MonitorConfig();
config.setGroupName("MyRepGroupName");
config.setNodeName("mon1");
config.setNodeHostPort("monhost1.acme.com:7000");
config.setHelperHosts("node1.acme.com:5000,node2.acme.com:5000");
Monitor monitor = new Monitor(config);
// If the monitor has not been registered as a member of the
// group, register it now. register() returns the current node
// that is the master.
ReplicationNode currentMaster = monitor.register();