Customers often ask where they should install their MySQL, MariaDB, or Percona MySQL database proxies for high availability clusters, and how many. What is optimal for you may not be the right configuration for everyone. However there are some best practices we’ll discuss in this basic blog about deploying MySQL database proxies.
This blog provides basic information about business-critical application to database connections; my team focuses on MySQL, MariaDB, and Percona Server for MySQL on Linux/Unix that’s infrastructure-agnostic (on-prem, VM, hybrid-cloud, cloud, multi-cloud, etc.).
Make It Smarter: Tuning MySQL Client Request Routing for Tungsten Connector
The power of Tungsten Clustering for MySQL / MariaDB is its built-in intelligent MySQL proxy, known as the Tungsten Connector. The Connector has built-in read-write splitting capabilities, and it is also possible to configure different algorithms which select the appropriate slave (i.e. Round-Robin or Lowest-Latency).
When deploying Tungsten Clustering for MySQL / MariaDB / Percona Server, we always recommend an odd number of Manager nodes in each cluster. Let's take a look at how having an odd number of Managers helps keep a Tungsten Cluster functioning and avoids data corruption scenarios (i.e. "split brain").
You already know about the Tungsten Connector which is the "secret sauce" that routes your application database traffic to the appropriate MySQL data source of your cluster. Have you ever wondered how the Connector keeps track of the cluster configuration? How it always knows which host is the master (or masters in a Composite Multimaster topology), and which are slaves?
