Tungsten Replicator is a powerful tool with many great features, and today we will look at a new one - the ability to Pause and Resume a replication service. Until now, the only way to stop a replication stream was to take the service offline, and put it back online when it is needed again. The online process involves a number of internal steps and overhead, and if there are many THL files on disk, it could take some time to index them all before the service can come fully online. To remove the overhead of the startup time, the new pause/resume feature was developed for the Replicator, and is accessed via the `trepctl` command.
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.
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!
