Blog

This is the third post in a short series about Tungsten Clustering topologies. In this post we will highlight the key differences between Composite Active/Passive, Composite Active/Active (CAA), and the newly available Dynamic Active/Active topology. In short, DAA blends the simplicity of CAP with the automated continuous operations of CAA.

You’ve seen the recent news about AWS outages; enterprises have to think about where their physical AWS data centers are and treat them as a single point of failure. As such, enterprises running business-critical and mission-critical applications are accounting for geography of public cloud resources in their business-continuity plans. Learn about a solution for continuous operations for your MySQL database that’s a step above traditional MySQL Disaster Recovery (DR).

In this short post we will highlight the key differences between Multi-Site Active/Active (MSAA) and Composite Active/Active (CAA) topologies. The core principle behind an active/active topology is that you have more than one writable cluster. So why do we have more than one type of Active/Active topology?

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.

Remember what 2001 looked like from a technology point of view? In this vlog, the Founder and CEO of Continuent, industry veteran Eero Teerikorpi, tells the story of the beginning of Continuent, and the bold vision that got us here. Since 2001, Continuent has pioneered the need for cloud-savvy business-critical MySQL databases that are platform-agnostic, highly-available, and globally-scaling.

We are pleased to announce that Tungsten Clustering and Tungsten Replicator GA versions 6.1.16 are now available. Tungsten allows enterprises running business-critical MySQL database applications to cost-effectively achieve continuous global operations with commercial-grade high availability (HA), geographically redundant disaster recovery (DR) and geographically distributed active/active.

Recently, a Continuent customer asked: “What is your approach for scaling up MySQL clusters for a higher number of queries per second and larger data sets?” Scaling, like availability, is a multifaceted question. In this blog post we will detail and discuss the best practices for scaling Tungsten Clusters.

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.

Galera Cluster provides high availability and scalability for MySQL. While this provides high availability in a local region or site, it does not provide any provisions for disaster recovery (DR) or any multi-site deployment in general, so let’s explore how we could extend the functionality of Galera Cluster to deploy at geo-scale.

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.

The tungsten_merge_logs command is designed to aid troubleshooting by consolidating the various log files into one place (merged.log), ordered by time. There are many moving parts to a cluster and they are spread over multiple nodes (usually three). When there is an issue, the logs are the key resource to find out what is going on. The best practice is to gather the log files into one place and then read through them all. This can be difficult with many files on multiple nodes. For this reason, the `tungsten_merge_logs` tool was created.