This is the second post in a series of MySQL case study blogs. It discusses a SaaS provider dealing with sensitive medical data and their need to be able to quickly deploy clusters in AWS and recover from multi-zone AWS outages.
This is the second post in a series of MySQL case study blogs. It discusses a SaaS provider dealing with sensitive medical data and their need to be able to quickly deploy clusters in AWS and recover from multi-zone AWS outages.
Part of the power of Tungsten Clustering for MySQL / MariaDB is the ability to perform true zero-downtime maintenance, allowing client applications full access to the database layer, while taking out individual nodes for maintenance and upgrades. In this blog post we cover various types of maintenance scenarios, the best practices associated with each type of action, and the key steps to ensure the highest availability.
How to move the Relay role to another node in a Composite Tungsten Cluster
Performing schema changes often requires extended downtime for applications. This is due to MySQL needing to rebuild tables for common schema change operations. Tools like pt-online-schema-change have been written to try to overcome the downtime associated with schema changes, however they are complex and put a high load on the database.
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").
One important way to protect your MySQL / MariaDB / Percona Server data is to keep your Tungsten Clustering software up-to-date; but how can you achieve this with zero-downtime?
The Tungsten Replicator is an extraordinarily powerful and flexible tool capable of moving vast volumes of data from source to target.
Think about it - your global, cloud-based application needs to be online and available for the business to run. Downtime is to be avoided like the plague. Perhaps you even have multiple cloud providers to span.
How do we create a database service layer that handles all kinds of failures?
Achieving software upgrades without downtime is a challenge that few software products can handle, or even try to. Tungsten Clustering is one that can!
Think about it - your application needs to be online and available for the business to run. Downtime is to be avoided like the plague. The buzz is all about five nines of uptime.
How do we as systems architects, DBAs and sysadmins create an environment where routine maintenance is not a thing to be feared and put off, but embraced to allow for proper and needed updates and upgrades to take place?