Tungsten Connector routes connections between client connections and datasources using a number of different routing methods. These routing methods affect how client applications and datasources are connected to each other, and control the level of inspection by Tungsten Connector of the connections and statements as they pass through the connector service.
The Tungsten Connector works with Tungsten Manager to automatically route clients connected to the connector to an appropriate server, balancing the load when communicating with slaves. The different methods are involved in effective read/write splitting, i.e. the ability to correctly route requests to the masters or slaves within the network according to the type of operation being performed by the client. This can be performed automatically, or manually, or through a series of specific configurable routing methods.
Routing selection is made by the connector based on the availability
information using a combination of different settings and parameters. Each
level overrides or augments the previous level, and each can be specified
in different locations, such as the
connecting string, or within individual supplied statements. The settings
are processed in the order shown below; later setting override earlier
For example, selecting the SQL routing method defines the default
behavior. Specifying the QoS in the
supercedes the SQL routing; setting QoS in a comment before the SQL
statement supercedes the user and default behavior. Specifying an affinity
in the comments overrides both the user and default configuration
Selected routing method, see Section 6.3.1, “Connector Routing Methods”
Quality of Service (QoS) specification, see Section 6.3.2, “Connector Quality of Service (QoS) Selection”
Load balancer selection (implied by QoS), see Section 6.3.3, “Connector Load Balancers”
Slave latency, including optional maximum latency setting, see Section 6.3.4, “Specifying Required Latency”
Affinity specification, see Section 6.3.5, “Setting Host Affinity and Direct Reads”
These different routing configurations can be selected according to the global configuration, and customization at different points in the communication channel. For example, SQL-based routing configures basic load-balancing, but allows SQL comments to be used to change the default QoS mode and affinity.
|SQL statement||Yes (with SQL routing enabled)||Yes (with SQL routing enabled)||No||No|
At all times, the connector uses the current status of the MySQL servers to make decisions about where queries and connections should be routed. Changes to the master, and availability or accessibility of individual dataservers will always be taken into account when routing the queries. For information on what happens if failure occurs during an operation or transaction, see Section 6.6, “Connector Operational States”.
The routing methods can either involve direct reads, SmartScale, host-based routing, or SQL inspection-based routing to redirect reads and writes to the appropriate server. In addition to these implied routing methods, clients can also specifically select which host to communicate with through the use of tags and options provided through the connection string.
The selection of a datasource occurs at the point the client connects, and this datasource connection choice remains in effect until the client disconnects, unless a failover or switch occurs.