Blog

What are some strategies for improving performance when applying to a MySQL target database with Tungsten Replicator?

This post covers some standard Nagios checks that would help keep your Tungsten cluster nodes running MySQL / MariaDB / Percona Server healthy.

Your MySQL database cluster contains your most business-critical data; in this post, we discuss how to ensure proper performance under load.

In this blog post we will define what a split-brain scenario means in a MySQL database cluster, and then explore how a Tungsten MySQL database cluster reacts to a split-brain situation.

In this blog post, we will discuss how to use the Tungsten Connector keep-alive feature to ensure long-running MySQL & MariaDB/Percona Server client sessions stay connected in a Tungsten Cluster.

While the MySQL Auto-Reconnect feature is both handy and interesting, it has to be used with great care, along with an understanding of the behavioral implications and side effects. In this blog post we will discuss some of the risks of using the MySQL driver Auto-Reconnect feature, and what happens when the Tungsten Connector internal version of it is enabled.

The Question

Recently, a customer asked us:

Why would heavy disk IO cause the Tungsten Manager and not MySQL to be starved of resources?

For example, we saw the following in the Manager log file tmsvc.log:

It is always a good idea to be mindful of open ports on your hosts, since they can be used by bad actors to gain access to your systems. For this reason, it is often desirable to prevent outside connections to the port whenever possible to prevent intrusions. For security purposes (and possibly PCI compliance), the Tungsten Connector proxy has the ability to bind to localhost/127.0.0.1 instead of listening on all available IP addresses via 0.0.0.0.

When Tungsten Replicator extracts data, the information that has been extracted is written down into the Tungsten History Log, or THL.

In this blog, part of a series of “Recently a Customer Asked” posts for Tungsten University, we explore the reason for the occasional Tungsten Replicator OFFLINE:ERROR state when applying to AWS Redshift, along with possible steps to compensate for the issue.

This blog post discusses the Tungsten Replicator and how latency is calculated when extracting events on a Primary, and when applying events to the Replicas. We also examine what latency is, and the two different types of latency that we track - how to interpret them and how they differ.

In this blog post, we explore the new support for running Tungsten Dashboard via Docker containers. This method allows for a rapid configuration of the GUI. We describe the docker method of installing the Tungsten Dashboard using a pre-defined Docker container provided by Continuent containing Apache, PHP, HAProxy and the Dashboard.