Overview
The Skinny
In this blog post, we will discuss how to use the Tungsten Connector keep-alive feature to ensure long-running MySQL & MariaDB/Percona Server client sessions stay connected in a Tungsten Cluster.
This blog is related to our latest Continuent white paper: The Basic Guide to Proxies for MySQL Databases - please review this white paper if you're interested in the details!
Agenda
What's Here?
- Briefly explore how the Tungsten Connector works.
- Describe the Connector keep-alives - what are they and why do we use them?
- Discuss why the keep-alive feature is not available in Bridge mode and why.
- Examine how to tune the keep-alive feature in the Tungsten Connector.
Tungsten Connector: A Primer
A Very Brief Summary
The Tungsten Connector is an intelligent MySQL database proxy located between the application/database clients and the database servers.
The Tungsten Connector provides a single database endpoint to the application, and routes queries to the appropriate database server (i.e. Primary for writes, and Replicas for reads).
High-Availability
The most important function of the Connector is failover handling.
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.
When the cluster detects a failed Primary because the MySQL server port is no longer reachable, the Connectors are signaled and traffic is re-routed to the newly-elected Primary node.
Read-Scaling
Next is the ability to route MySQL queries based on various factors to provide read-scaling.
During the routing process, Tungsten Connector communicates with the Tungsten Manager to determine which database servers are the most up to date, along with their current role, so that the packets can be routed properly.
In the default Bridge mode, traffic is routed at the TCP layer, and read-only queries must be directed to a different port (normally 3306 for writes and 3307 for reads).
There are additional modes: Proxy/Basic, Proxy/Direct and Proxy/SmartScale. Queries are intercepted and inspected by the Connector in all three modes. The routing decisions are tunable based on configuration parameters.
For more detailed information about how the Tungsten Connector works, please read our blog post, "Experience the Power of the Tungsten Connector".
For a comparison of Routing methods, please see the documentation page.
Tungsten Connector: Keep-Alives
What Are Keep-Alives and Why Do We Use Them?
Connections to MySQL servers can be automatically timed-out by the database server according to the wait_timeout variable configured within MySQL.
To prevent these connections being automatically closed, the Connector can be configured to keep the sessions alive by submitting a simple SELECT 'KEEP_ALIVE'; statement periodically to ensure that the MySQL connection timeout is not reached. This prevents the session from ending prematurely.
The keep-alive feature was designed with Proxy mode in mind (Proxy/Basic, Proxy/Direct and Proxy/SmartScale). When using any Proxy mode, every single client session will create 2 mysql server-side connections: one for Writes and one for Reads.
If your application is read-intensive, the server-side Read-only connection gets updated often and is kept alive by MySQL. Under those conditions, the write connection is NOT being used, and so there is a risk that the MySQL server's wait_timeout will expire. If the session expires, the next write on the client side connection would get an error.
In response to the above scenario, the keep-alive feature was implemented.
Keep-alives by default are enabled and set to autodetect, which will compute suitable values based on the MySQL server wait_timeout value in order to be totally transparent to the application. This design will produce the exact same behavior as if the application were connected directly to the database server.
Keep-Alives and Bridge Mode
Why They Do Not Work Together?
The Connector Keep-alive feature is NOT compatible with Bridge mode.
In Bridge mode, the client session is directly connected to the MySQL server at the TCP level, literally forwarding the client's packet to the server. This means that closing connections is the responsibility of the MySQL server based on the configured wait_timeout value, not the Connector.
Summary
The Wrap-Up
In this blog post we discussed the basics of the Tungsten Connector, the Keep-alive feature and how to tune the values that control it.
To learn about Continuent solutions in general, check out our Products & Solutions page.
The Library
Please Read the Docs!
For more information about Tungsten Connector Keep-Alives, please visit our documentation.
Tungsten Clustering is the most flexible, performant global database layer available today - use it underlying your SaaS offering as a strong base upon which to grow your worldwide business!
Want to learn more or run a POC? Contact us.
Comments
Add new comment