7.1. Tungsten Manager Introduction
Content Being Written
This section of the documentation is currently being produced
and may be incomplete and/or subject to change.
The Tungsten Manager is responsible for monitoring and managing a Continuent
Tungsten dataservice. The manager has a number of control and supervisory
roles for the operation of the cluster, and acts both as a control and a
central information source for the status and health of the dataservice as a
Primarily, the Tungsten Manager handles the following tasks:
Monitors the replication status of each datasource within the cluster.
Communicates and updates Tungsten Connector with information about the
status of each datasource. In the event of a change of status,
Tungsten Connectors are notified so that queries can be redirected
Manages all the individual components of the system. Using the Java JMX
system the manager is able to directly control the different components
to change status, control the replication process, and
Checks to determine the availability of datasources by using either the
system ping protocol (default), or using the Echo
TCP/IP protocol on port 7 to determine whether a host is available. The
configuration of the protocol to be used can be made by adjusting the
manager properties. For more information, see
Section B.2.2.3, “Host Availability Checks”.
Includes an advanced rules engine. The rule engine is used to respond to
different events within the cluster and perform the necessary operations
to keep the dataservice in optimal working state. During any change in
status, whether user-selected or automatically triggered due to a
failure, the rules are used to make decisions about whether to restart
services, swap masters, or reconfigure connectors.
In order to be able to avoid split brain, a cluster needs an odd number of
members such that if there is a network partition, there's always a chance
that a majority of the members are in one of the network partitions. If
there is not a majority, it's not possible to establish a quorum and the
partition with the master, and no majority, will end up with a shunned
master until such time a quorum is established.
To operate with an even number of database nodes, a witness node is
required, preferably an active witness, since the dynamics of establishing a
quorum are more likely to succeed with an active witness than with a passive