Tungsten Clustering contains many tools to monitor your cluster, and today we will look at a new one - the `tungsten_get_status` command, included with Tungsten versions 6.1.19+ and 7.0.2+. This tool was created in response to a customer request for a simple script that could display the status of all nodes cluster-wide for any topology from a single place. The status includes the datasource and replicator layers along with the policy for each cluster.
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.
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.
