Bridge mode is now the default connector routing method if no other
routing method is explicitly stated. The bridge-mode does not use the
user.map file which reflects other changes to take
a more secure default deployment. A warning will be displayed during the
validation process to tell you if bridge-mode is being enabled. It will
not be enabled in the following cases:

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.

Figure 6.6. Tungsten Connector routing architecture

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 user.map,
connecting string, or within individual supplied statements. The settings
are processed in the order shown below; later setting override earlier
settings.

For example, selecting the SQL routing method defines the default
behavior. Specifying the QoS in the user.map file
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
settings.

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.

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.