6.1. Connector/Application Basics
Within any typical database deployment there will be two primary
Within a typical basic database deployment clients and application servers
will connect directly to databases, as shown in
Figure 6.2, “Basic MySQL/Application Connectivity”.
Figure 6.2. Basic MySQL/Application Connectivity
The problem with this deployment model is that it is not able to cope with
changes or problems. If one or more of your database servers fails, then
the application servers must be reconfigured individually to point to an
alternative server. In addition, when considering scalability, there is no
provision for redirecting reads and writes to masters or slaves.
In an advanced application deployment, individual servers may have been
configured to connect to masters and slaves and configured your
application to talk directly to the master and/or slaves within the
database infrastructure to handle the scalability offered by using
replication (Figure 6.3, “Advanced MySQL/Application Connectivity”). For
this to work the application must have been modified and be read/write
aware, and it must have been configured to manually connect to the
different databases according to the operation being performed.
Figure 6.3. Advanced MySQL/Application Connectivity
Although this handles the read/write splitting, enabling servers to write
to the master and read from one or more slaves, changes to this
architecture and structure are not handled. If the master fails,
application servers must be manually updated to direct their queries to an
When deploying Tungsten Clustering the connector takes over the role of primary
connection from your application to the database server, and it handles
the redirection of requests to the appropriate database server. Depending
on your application configuration and architecture, the connector can be
used in two ways:
As a complete solution for redirecting queries between the master and
slave hosts within a dataservice, including HA events.
As an HA solution redirecting queries to the master and slaves within
a dataservice, but with application driven master/slave selection.
When deploying your application with Tungsten Clustering through
Tungsten Connector, the application server connectivity is through the
connector. The connector takes on the role of primary connection for all
requests, while routing and distributing those requests to the active
datasources within the dataservice.
Figure 6.4. Using Tungsten Connector for MySQL/Application Connectivity
The Tungsten Connector is located between the clients and the database
servers, providing a single connection point, while routing queries to the
database servers. In the event of a failure, the Tungsten Connector can
automatically route queries away from the failed server and towards
servers that are still operating. During the routing process,
Tungsten Connector communicates with the Tungsten Manager to determine which
datasources are the most up to date, and their current role so that the
packets can be routed properly.
Because the connectivity is between the application service and the
Tungsten Connector, the connection to the Tungsten Connector remains constant.
Changes to the datasources, including failures, role changes, and
expansion or removal of datasources from the dataservice do not require
any modification of the application configuration or operation.
Figure 6.5. Tungsten Connector during a failed datasource
For example, in Figure 6.5, “Tungsten Connector during a failed datasource”, the
slave datasource has failed. While this would break the connection between
the Tungsten Connector and the datasource, the connection between the
application and Tungsten Connector remains available, and Tungsten Connector
will re-route queries to an available datasource without reconfiguring the
application server connectivity.
6.1.1. Connector Control Flow
The Connector makes a TCP connection to any available Manager, then all
command-and-control traffic uses that channel. The Manager never
initiates a connection to the Connector.
When there is a state change (i.e. shun, welcome, failover, etc.), the
Manager will communicate to the Connector over the exisiting channel.
The Connector will re-establish a channel to an available Manager if the
Manager it is connected to is stopped or lost.