Bridge mode is 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:
The
--connector-smartscaleoption is set totrue.The
user.mapfile contains@hostoptionentries.The
--property=selective.rwsplittingconnector option is set totrue.
Bridge mode eliminates the need to create or define users and passwords
within the user.map file. Instead, the connector acts
as a router connecting the network sockets between client application and
MySQL servers.
Bridge mode provides a simpler method for connecting clients to MySQL, but with reduced facilities, as outlined in the table below:
| Feature | Proxy Mode | Bridge Mode |
|---|---|---|
| Primary/Replica Selection | Yes | Yes |
| Switch/Failover | Yes | Yes |
| Automatic Read/Write Splitting | Yes | No |
| Application-based Read/Write Splitting | Yes | Yes |
| Seamless Reconnects | Yes | No |
| Data Source Selection | Current data source is checked to confirm latency and affinity | Pass-through |
| Session KeepAlive | Yes | No |
Bridge mode connections operate as follows:
Client opens network connection to Connector
Connector allocates a network buffer for the client network connection to the database server
Connector opens a network connection to a database server based on the connection parameters (Primary/Replica selection)
Connector allocates a network buffer for the database server to the client application
Connector directly attaches the network sockets sockets together
Because the network sockets between the two sides are connected directly together, the following behavior applies to bridge mode connections:
User authentication is handled directly by the database server, rather than through the
user.mapfile.In the event of a failover or switch of the database servers, all active connections to the affected servers are closed.
Smartscale and packet inspection to provide read/write splitting are not supported, since the Connector does not access individual packet data.
One key difference is in how Replica latency checking is handled:
In Bridge mode, the latency is checked at connection time, then you will stick to the Replica for the connection lifetime (which can be shortened if the Replica goes offline).
In Proxy mode, the latency is re-evaluated before each transaction, which can bring the connection to another Replica if the latency becomes too high during the life of the connection.
If you have long-lasting read-only connections that should not read from stale Replicas, then use Proxy mode.
If your connection lifetime is short (i.e make/break - one transaction then disconnect), or your application is not sensitive to reasonably outdated data for reads, then use Bridge mode and its optional read-only port.
To enable Bridge Mode, the
--connector-bridge-mode option to
tpm must be set to
true:
Click the link below to switch examples between Staging and INI methods...
shell>tpm query stagingtungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141 shell>echo The staging USER is `tpm query staging| cut -d: -f1 | cut -d@ -f1`The staging USER is tungsten shell>echo The staging HOST is `tpm query staging| cut -d: -f1 | cut -d@ -f2`The staging HOST is db1 shell>echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141 shell>ssh {STAGING_USER}@{STAGING_HOST}shell>cd {STAGING_DIRECTORY}
shell> ./tools/tpm configure alpha \
--connector-bridge-mode=true
Run the tpm command to update the software with the Staging-based configuration:
shell> ./tools/tpm updateFor information about making updates when using a Staging-method deployment, please see Section 10.3.7, “Configuration Changes from a Staging Directory”.
shell> vi /etc/tungsten/tungsten.ini[alpha]
...
connector-bridge-mode=true
Run the tpm command to update the software with the INI-based configuration:
shell>tpm query stagingtungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141 shell>echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141 shell>cd {STAGING_DIRECTORY}shell>./tools/tpm update
For information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
The default value is true, i.e.
use the connector in bridge mode.
Bridge Mode can also be used with read-only database servers and affinity if required.
In addition to enabling and disabling Bridge Mode, the size of the
buffer can also be set by using the
bridgeServerToClientBufferSize
and
bridgeClientToServerBufferSize
parameters. This configures the size of the buffer used to hold packet
data before the packet is forwarded.
The default size is 262144 bytes (256KB).
A buffer is opened in each direction for each connection made to the connector when operating in bridge mode.
The total memory allocated can be calculated using the formula:
(connections * (bridgeClientToServerBufferSize + bridgeServerToClientBufferSize)
For example, with the default settings, 20 simultaneous connections will require 10MB of RAM to service the buffers. With the default connector heap size the Connector should be able to handle up to 500 simultaneous connections.