Depending on your application, high availability (HA) may be a requirement for your organization. If you’re running a banking system or POS terminal, or your business leverages critical 5G networking that people rely on, you would never want an outage to affect your business. We make achieving HA easy with MariaDB Enterprise Server and MariaDB MaxScale, our advanced database proxy.
I recently took a deep dive into MaxScale, demonstrating how to configure it and walking through all the benefits organizations can expect from this powerful tool. I covered:
- An overview of MaxScale’s architecture
- Near-instantaneous automatic failover with MaxScale
- Security features
- Customized scalability options
- Easy-to-use user interface
In this blog, I’ll recap how MaxScale changes the game for database administrators and developers alike.
An Overview of MaxScale’s Architecture
MaxScale has a robust set of features and tools that make it an essential part of every MariaDB Enterprise architecture design. One of MaxScale’s core functions is to insulate client applications from backend database architecture. This means that developers can build applications without needing to know about the database’s backend topography. It also ensures that operations teams and database administrators (DBAs) can make changes without impacting application uptime or requiring complex and time-consuming application configuration changes. MaxScale is an integral part of a high availability architecture design, as it is optimized to keep failovers and scaling transparent to the application.
Primary and Replica Databases
The current recommended MariaDB Enterprise Server environment includes one primary database and at least two replicas. A total of at least three database nodes is crucial design architecture, as three databases allow for one to be taken offline for maintenance and upgrades without leaving your primary node exposed to a single point of failure.
MaxScale can facilitate automatic failover between these different databases. In addition, MaxScale’s features allow for rolling upgrades to be performed on backend databases transparently to the application layer without impacting performance. (More on both of these abilities in the following sections).
MaxScale Nodes and Cooperative Locking
To avoid single points of failure, it’s best practice to include at least two MaxScale nodes that can facilitate application requests. This setup ensures that the environment will continue running smoothly, even if one MaxScale node stops working. MaxScale also includes cooperative locking, which assigns a “primary orchestrator” role to one of the MaxScale instances and keeps the nodes running without conflict.
MaxScale connects to the application with a JDBC connector that requires minimal configuration. This connector can treat the MaxScale nodes as sequential, using one and failing over to the other if the primary goes down, or as load balanced, distributing application connections across both nodes.
MariaDB JDBC Connector/J MaxScale Failover
One of the most essential features built into MaxScale is its zero-interruption automatic failover. MaxScale automatically reassigns the primary role to a replica if the primary database goes down. This switch happens near-instantaneously, ensuring application users don’t experience downtime or failures.
To further insulate the application from any of this backend activity, MaxScale also offers other features for zero interruption. Here are additional features that can be enabled to kick in as soon as an automatic failover occurs to provide a seamless, transparent transition to the new primary:
- Connection migration: MaxScale will migrate the backend connection to the new primary, preventing any failure, disconnect, or retry from being issued to the application.
- Session restore: MaxScale will restore the session to its previous state on the new primary. Without this feature, the session would need to be recreated by the application.
- Transaction replay: MaxScale will replay the transactions on the new primary if the automatic failover occurs mid-transaction. This is a critical feature if the application was in mid-transaction when a failure occurs. MaxScale will handle replaying the transaction so no data is lost with a rollback, and the application will not receive an error to handle.
Tune into my webcast to see a full demo of the automatic failover process.
Delivering Comprehensive Enterprise Performance Capabilities
MaxScale includes several features for scaling your environment without impacting uptime. It uses a few key features to ensure that scaling up or down does not affect user experience or cause complications for your database admin team.
A few of these key features include:
- Read-write splitting that scales reads seamlessly, making the database architecture appear as a single database to the application
- SQL-aware load balancing that distributes traffic across multiple databases
- Flexible architecture options to align with your unique business needs with MariaDB Server for transactions (default is the InnoDB storage engine), MariaDB Server for analytics (using the ColumnStore storage engine) or MariaDB Galera Cluster (multimaster clustering)
- Integrations with Kafka (streaming), Redis (caching) and MongoDB (NoSQL translation)
Unlike other proxies, you don’t need to piecemeal third-party tools or write RegEx to turn on these features. They are built into MaxScale and can be easily configured.
Intuitive User Interface
MaxScale also includes a powerful GUI interface that makes it easy to visualize and change database architecture.
A few of the actions that admins can perform with the GUI interface include:
- Viewing a visual map of configuration and cluster architecture
- Digging into the database’s log archive
- Making manual changes to queries
- Drilling down and editing configurations
Dive into the Full MaxScale Webinar
If you want to learn more about MaxScale and see how this powerful MariaDB Enterprise Server offering works firsthand, you won’t want to miss the entire webcast. Sign up to watch it on demand today.