6.6. Connector Operational States
During operation, the connector goes through a number of different states
and state transition during specific events. The default mode is the
Online state, where the
connector operates as configured.
During operation, all configured connectors within the dataservice remain
in contact with the manager, see Section 6.7, “Connector/Manager Interface” for
Supported states by the Connector are:
The Connector operates as configured, redirecting connections to the
corresponding master or slave.
In this state, the connector will continue as normal allowing existing
connections to continue until the
is reached. New connections are paused.
When the connector enters the offline state, the connector terminates
all connections, and blocks all new connections.
The state of a connector can be modified by using the
router command within
cctrl. This can be used to manually place the connector
into online or offline states. For example, to put a connector online the
full host and process ID must be used:
router connector@host1 online
Wildcards can be used to enable or disable all the hosts. For example, to
place all connectors online:
router * online
AUTOMATIC policy mode,
connectors will automatically be placed online if they have entered the
OFFLINE state automatically
as part of a failover. If the routers have been manually placed offline,
routers must be manually placed back online.
While in the
the connector behaves and alters it's operation according to the following
states and events:
6.6.1. Connections During Automatic Failure/Failover
When an automatic failure or failover is identified, for example when
the dataservice is in the
AUTOMATIC policy mode, and the
master is automatically switched to a new host, the following sequence
All connections to the failed datasource are terminated immediately.
This ensures that running transactions or operations are terminated
by the database server.
Connections to clients will remain open and be reconnected
transparently, providing they are not within a transaction. For more
Section 6.6.3, “Connections During Connection Failures”.
Only if there is a problem with the connection or an I/O error will
the problem be forwarded to the clients.
As with a direct database connection, the client application should
handle the reconnection to the Connector, which will be then be
redirected to the corresponding master or slave datasource.
6.6.2. Connections During Manual Switch/Failover
When a manual failure has been initiated, for example, during a
datasource shun, or
switch operation has been
initiated, the Connector follows this sequence:
New connection attempts to the failed datasource are suspended; this
gives the impression of a 'hung' connection that must be managed by
the client application through the normal timeout procedure.
Existing connections to the datasource are terminated under two
As the connections are naturally closed.
Open connections are forcibly disconnected after the timeout
specified by the
parameter. By default, this is 5 seconds. To eliminate waiting,
parameter can be set to
Once either condition has been met, any remaining connections are
New connections (including re-connections) are enabled, and will be
routed to the appropriate master or slave.
Client applications should be configured to reconnect to the connector
with an interval larger than the disconnect timeout within the
connector. This will ensure that the client reconnects when the
connector is able to accept the new connection.
6.6.3. Connections During Connection Failures
In the event of a connection failure between a running datasource and
the connector, and providing the connection is deemed idle, the
connector will transparently reconnect to the failed datasource when the
following conditions have been met:
The connection is not executing any requests.
The connection is not in the middle of a transaction.
No temporary tables have been created during this connection.
If all three conditions are met, a new connection will be opened.
Connections between the client and the connector will be unaffected.
This option is enabled by default. To disable transparent reconnections,
option to tpm during installation.
The Connector attempts to emulate and effectively represent any errors
raised by the datasource to which the connector has routed the client
The Tungsten Connector uses the Tanuki Java Service Wrapper to manage
the running process. If the Connector process fails, the service
wrapper will automatically restart it. If the connector fails
repeatedly, attempts to restart will be stopped. The status and
reason for these failures can be tracked by examining the
connector.log log file.
Connected client applications will be terminated, but should be able
to reconnect once the Connector has been restarted.
Database errors, including invalid statements, operations, or
security failures, will be represented identically by the Connector
to any clients.