In this blog we take a look at how you can use Tungsten Replicator to replicate data from multiple sources, and merge into a single target using 3 simple yet effective filters.
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!
This blog post looks at the ins and outs of Amazon Aurora replication and how to best go about that; including all the details you need to replicate to and from Aurora with the Tungsten Replicator AMI.
Amazon Redshift has been providing scalable, quick-to-access analytics platforms for many years, but the question remains: how do you get the data from your existing datastore into Redshift for processing? This blog looks at that question by providing some background information on Redshift replication as well as details on how to easily replicate from MySQL to Redshift.
It’s Hadoop’s 15th birthday and we’re looking at how to easily replicate from MySQL to Hadoop and why in this blog on real-time big data analytics.
