Blog

Cloud-based managed MySQL data services have become popular choices for businesses. While these services offer advantages, they also come with a host of drawbacks that can impact performance, control, and costs. This post explores these key drawbacks in detail and compares those to Tungsten Clustering running in the cloud, also multi-cloud, hybrid-cloud and on-premises.

MySQL has evolved significantly since its inception in 1995, becoming one of the most reliable and widely used open-source database solutions globally. Continuent has been instrumental in driving this evolution.

We are excited to announce the release of Tungsten Cluster & Tungsten Replicator v7.1.3, featuring new command enhancements, Ruby 3.2 support, and improved tools for better usability and stability. Additionally, several bug fixes address issues with command-line tools and monitoring.

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.

This blog post outlines our Continuent Tungsten pricing model for Tungsten Cluster software subscriptions and related 24/7 support.

AWS may reboot your Aurora database. What is the impact?

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.