Tungsten Clustering allows for many types of maintenance to happen with no downtime at all. This blog post will explore how to upgrade the actual MySQL Server on all cluster nodes with zero downtime.
In this post we will explore a new command in v7.0.1, tpm report. The purpose of tpm report is to provide easy access to all of the settings that pertain to a specific topic. Since Security is a high priority at Continuent, the current default (and only) topic is the Security stance. The tpm report command will evolve and grow over time. This first version is Continuent’s way of providing as much transparency about Tungsten Cluster Security as possible.
So we’ve established how important backups are, RTO, RPO, and how you can be a hero by having backups that align with business objectives. We just need to pick a good backup tool(s) to take backups of your MySQL database. Databases evolve, grow, and business needs change. That’s why it is important to constantly reevaluate your backup strategy, because what worked last year may not be appropriate this year in terms of RPO/RTO, retention, or costs.
As system administrators, we are called upon to be responsible for a vast quantity of discrete subsystems, each with its own set of operating rules. When starting and stopping any subsystem, it is the best practice to do so gracefully whenever possible to ensure data integrity. In this blog post, we detail the best practices for stopping and starting a Tungsten Cluster.
In this blog post we examine in depth how to best provision one MySQL database cluster node from another using rsync. Since there are many possible ways to handle provisioning by rsync, we will do multiple posts on the topic, starting with the most basic - both the source and target database nodes are fully offline for the duration of the rsync. While this is not an ideal scenario because two nodes are down at once, it does allow one replica to be provisioned from another replica when all else fails.
Recently a customer asked, “Are there any issues with running a specific node with parallel apply enabled, and the rest of the nodes using a single stream (parallel disabled)? Just curious because that would be easiest for A/B testing of the replication effects.” Firstly, the answer is yes, you may certainly enable Parallel Apply on a single node within a Tungsten Cluster.
In this blog post we explore the implications and best practices for using Parallel Apply in this way.
“How can I simulate a failure of the Active half of an Active/Passive Cluster to test the Failover to the Passive half?”
In this blog post we explore the best practices for simulating a failure of the Active cluster in an Active/Passive Composite Cluster.
Standards allow modern systems to advance, and the REST specification is one very important example.
Since this post is about the Tungsten API in specific, let me simply say this - a RESTful API adheres to six principles: Client-server, stateless, cacheable, uniform interface, layered system and optionally code on demand. As part of the watchability/monitoring goal, our upcoming version 7.0.0 includes a proper RESTful API - what we call APIv2. This API will be fully documented and public.
This blog is about testing time and test suites management. “Battle-tested” is the Continuent Tungsten QA (Quality Assurance) guarantee. Continuent Tungsten is a clustering and replication solution for MySQL and MariaDB used by some of the largest MySQL estates to achieve continuous MySQL operations, locally and globally (HA, DR and Geo Distribution). Besides the stellar support team, and fully-integrated components, customers say: “Stability,” and, “Tungsten just works.”
Performing MySQL schema changes often requires downtime for applications. In this blog, we cover two ways we can perform MySQL schema changes without risking downtime or other MySQL data problems. In this real-life customer example, we perform a schema change to modify the column data type from varchar(20) to varchar(50) on approx. 35 tables from 3GB to 10GB in size. Two of the tables are partitioned, and one of them is about 100GB combining all partitions for that table.
“We don’t take backups, we use replication instead.” If you happen to agree with this statement, I urge you to continue reading. But even if you think you have a good backup plan, I still urge you to continue reading. Taking backups is usually not one of the most exciting parts of the job, but it might be the part that saves your company from a catastrophe. So, let’s make a plan!
There are a number of MySQL HA solutions around. But there really is only one solution that Does MySQL HA Right!
