This blog provides basic information about business-critical connections (not the type you have on Linkedin), but application and 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.).
What qualifies me to talk about this? I am a Customer Success Manager serving some happy companies like Adobe, CARFAX, Corelogic, Garmin, Riot Games and VMware where my team provides MySQL continuity, geo-scale solutions and enterprise level 24/7 support, safeguarding billions of dollars of combined revenue. To say the least, our solutions have been tested through-and-through, and Continuent engineers have continuously innovated in the MySQL space for almost twenty years. As a commercial supporter of the open source ecosystem, Continuent aims to be an objective, unbiased resource, so anyone who asks us for help may get the best out of native MySQL, MariaDB or Percona Server.
Now that we’re clear on what type of connections we’re talking about, let’s discuss apps that must be always-on.
As you know, downtime is unacceptable for applications that serve multiple time zones or have mission-critical reasons for remaining available 24/7/365. For applications such as SaaS, E-commerce, Financial Services, there is no good time for a scheduled maintenance update (as you face with most MySQL deployments and AWS Aurora), and never a good time for an unexpected outage! These apps also tend to place very high value on application performance, data integrity and security, and geographically-distributed scalability. That’s why these DevOps and Database teams set up real-time replication to multiple database servers, configured in clusters.
In the most basic scenario, connections may be made directly between the application and the Primary database server in a 3-node MySQL cluster (three, for no single point of failure and to get quorum in split-brain events), like this:
Challenges with this configuration include:
- Spotty connections - lost, broken connections due to changes or failures in the database infrastructure.
- Manual labor, often at odd hours - if one or more of your servers fails, then the system must be reconfigured manually. If replication between database servers was broken, there’s a headache.
- Not scalable - operationally for administrators, nor resource-wise due to inability to route reads and writes to different database servers.
- Not performant - An inefficient use of compute resources and inability to scale is likely to degrade performance during heavy traffic.
You may choose to re-write your application so you can read from Replicas in the cluster, like this:
However, the major challenges remain, due to rigidity and lack of resilience. Changes and updates to the database layer can still result in lost connections. Application servers must be manually updated to direct queries to alternative servers. The load balancing is inflexible (hard-coded, not intelligent and dynamic), so the value-added is not optimal, and it’s a nightmare to serve multiple applications simultaneously.
The solution to these problems is to abstract the database layer from the application layer using a MySQL database proxy; this is explained in this webinar by the original author of Tungsten Proxy, aka “the Connector” part of Tungsten Clustering solutions, Continuent’s VP of Engineering, Gilles Rayrat: Intro to Database Proxies: Why do we need a Proxy in the first place? Smarter Proxies are better!
As Gilles explains, with an intelligent proxy, the application sees the cluster of database servers as one database:
The proxy makes it easy to serve multiple apps with no application changes needed for intelligent load balancing, automated failover, and a host of other benefits; one major being you will not run the risk of breaking replication when your application(s) are configured incorrectly or changed (eg. Rolling out a new release? No worries!):
I work with customers using Tungsten solutions and they appreciate the modular and flexible design; as your needs evolve, you may easily add more nodes, add more clusters, or add clusters in different places. With no application changes, no downtime, and no replication headaches, because of the Proxy communicating with the cluster brains, aka “Tungsten Manager,” customers may easily add and manage clusters:
- To cloud, for hybrid-cloud capabilities (Disaster-Recovery-as-a-Service and Scalability).
- In specific regions, to bring the database closer to a new growing user base (Performance).
- Within specific borders, for governmental compliance, leveraging filters (Rules and Regulations).
But none of this would be possible without the intelligent proxy layer. In fact, Tungsten is the only MySQL proxy capable of being Active/Active aware: that is, it’s compatible with a cluster of clusters (or composite cluster as we like to call it) where two or more Primary sites can accept writes and replicate to/from each other.
To summarize, some benefits of using an intelligent database proxy include:
- Continuous Operations - by automatically routing connections to an available server when one fails.
- Transparency and Simplicity - applications don’t have to know the underlying database topology.
- Load Balancing - scalability and efficiency gained by splitting reads/writes in the most optimal fashion. This is configurable in many different ways depending on your needs.
- Ease of Management - changes to the databases, including failures, role changes, and expansion or removal of servers from the dataservice do not require any modification to the application or manual labor.
- Observability - greater data and insight over connections to the database system no matter how complex your underlying topology is. This allows you to test and tune your configurations to optimize for performance and predictability.
If you have questions or would like to learn more, feel free to reach out on our website or connect with me on Linkedin! Hope the reads of this blog are as enjoyable as the writes! :)
Comments
Add new comment