Blog

We are pleased to announce that Tungsten Clustering and Tungsten Replicator GA versions 6.1.19 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.

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.

We are pleased to announce that Tungsten Clustering and Tungsten Replicator GA version 6.1.18 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.

In this blog, we discuss Galera Cluster and synchronous versus asynchronous replication. We also discuss some of the differences between Galera Cluster and Tungsten Cluster rooted in this difference in foundation. And how Tungsten has served a critical niche - mission-critical, geo-distributed, highly-performant MySQL applications - for a long time.

Transaction History Log (THL) files are the core of Tungsten Replication, containing the actual MySQL write events that are replicated to the replicas. These files can take up considerable amounts of disk space, making them of interest for housekeeping operations to limit the consumption and ultimately, the cost. This blog post will walk you through THL management, along with the new command `tpm purge-thl` which helps automate the process when THL needs to be removed prior to the automatic rotation window.

Performance tuning any system provides more speed for the same hardware spend, gives the end-user a better, faster experience and typically reduces the stress on staff all around. Security tuning locks down critical data to prevent unauthorized access. Today we will explore both the security and performance enhancements available for the Tungsten Replicator THL sub-system as of version 7.x.

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.

This blog is about troubleshooting failed DDL across all Replicas in a composite active/active (CAA) Tungsten Cluster. The issue was resolved by setting a more permissive SQL_MODE, then locating and cleaning the bad data with proper NULLs before re-issuing the ALTER TABLE.

Tungsten Replicator is the most advanced heterogeneous real-time data replication solution for MySQL, MariaDB & Percona Server, including Amazon RDS MySQL and Amazon Aurora. It provides high-performance and improved replication functionality over the native MySQL replication solution and into a range of target databases.

This latest post on MySQL replication follows the ones we did on Amazon Redshift & Amazon Aurora; naturally, we had to cover Amazon RDS as well and so we look here at how to easily and securely replicate from MySQL to Amazon RDS (and vice versa).

We often hear that asynchronous replication creates a possible data loss window, thus it is not an acceptable solution for certain types of applications.

Yes, this is true. In theory, that is. 

In practice, we have developed the Tungsten Cluster solution to the point that it really does not happen in real life. Please read this blog to understand why not!

Application performance and MySQL database responsiveness is always high priority for highly-available, business-critical use cases. That’s why Tungsten Clustering offers features and options to tune for maximum performance, such as Parallel Apply. When does Parallel Apply work best? What are the limitations? To find out, read this blog from MySQL industry vet, Eric M. Stone, the COO of Continuent!