The Tungsten Connector is a service that sits between your application
server and your MySQL database. The connector routes connections from your
application servers to the datasources within the cluster, automatically
distributing and redirecting queries to each datasource according to load
balancing and availability requirements.
The primary goal of Tungsten Connector is to effectively route and redirect
queries between the master and slave datasources within the cluster.
Client applications talk to the connector, while the connector determines
where the packets should really go, depending on the scaling and
availability. Using a connector in this way effectively hides the
complexities of the cluster size and configuration, allowing your cluster
to grow and shrink without interrupting your client application
connectivity. Client applications remain connected even though the number,
configuration and orientation of the slaves within the cluster may change.
During failover or system maintenance Tungsten Connector takes information
from Tungsten Manager to determine which hosts are up and available, and
redirects queries only to those servers that are online within the
For load balancing, Tungsten Connector supports a number of different
solutions for redirecting queries to the different datasources within the
network. Solutions are either based on explicit routing, or an implied or
automatic read/write splitting mode where data is automatically
distributed between master hosts (writes) and slave hosts (reads).
Basic read/write splitting uses packet inspection to determine whether a
query is a read operation (
or a write (
DELETE). The actual selection
mechanism can be fine tuned using the different modes according to your
The supported modes are:
Port Based Routing
Port based routing employs a second port on the connector host. All
connections to this port are sent to an available slave.
Direct reads uses the read/write splitting model, but directs read
queries to dedicated read-only connections on the slave. No attempt is
made to determine which host may have the most up to date version of
the data. Connections are pooled between the connector and
datasources, and this results in very fast execution.
With SmartScale, data is automatically distributed among the
datasources using read/write splitting. Where possible, the connector
selects read queries by determining how up to date the slave is, and
using a specific session model to determine which host is up to date
according to the session and replication status information. Session
identification can be through predefined session types or user-defined
Host Based Routing
Explicit host based routing uses different IP addresses on datasources
to identify whether the operation should be directed to a master or a
slave. Each connector is configured with two IP addresses, connecting
to one IP address triggers the connection to be routed to the current
master, while connecting to the second IP routes queries to a slave.
SQL Based Routing
SQL based routing employs packet inspection to identify key strings
within the query to determine where the packets should be routed.
These core read/write splitting modes can also be explicitly overridden at
a user or host level to allow your application maximum flexibility.