The Tungsten Connector is an intelligent MySQL proxy that provides key high-availability and read-scaling features. This includes the ability to route MySQL queries by inspecting them in-flight.
Make It Smarter: Tuning MySQL Client Request Routing for Tungsten Connector
Over the past few days we have been working with a number of customers on the best way to handle Triggers within their MySQL environment when combined with Tungsten Replicator. This new blog dives head first into the minefield of Triggers and Replication.
Read our white paper on Tungsten Clustering for MySQL, MariaDB and Percona Server. Tungsten Clustering allows enterprises running business-critical database applications to cost-effectively achieve continuous operations on a global scale.
In this blog post, we explore the correct way to implement bi-directional Tungsten Replication between AWS Aurora and Tungsten Clustering for MySQL databases.
Part of the power of Tungsten Clustering for MySQL / MariaDB is the ability to perform true zero-downtime maintenance, allowing client applications full access to the database layer, while taking out individual nodes for maintenance and upgrades. In this blog post we cover various types of maintenance scenarios, the best practices associated with each type of action, and the key steps to ensure the highest availability.
The power of Tungsten Clustering for MySQL / MariaDB is its built-in intelligent MySQL proxy, known as the Tungsten Connector. The Connector has built-in read-write splitting capabilities, and it is also possible to configure different algorithms which select the appropriate slave (i.e. Round-Robin or Lowest-Latency).
The replicator is a critical piece of the Tungsten Clustering solution for MySQL / MariaDB, as well as its own stand-alone data replication product. Automatic recovery enables the replicator to go back online in the event of a transient failure. In this blog, we discuss how to enable Autorecovery.
Database Proxies provide a single entry point into MySQL for the calling client applications. Proxies are wonderful tools to handle various situations like a master role switch to another node for maintenance, or for transparency with read and write connections. However, when the time comes to perform the switch action, all of the calling clients have been funneled through the proxy, so identification of the calling host from the database itself becomes difficult.
How to move the Relay role to another node in a Composite Tungsten Cluster
Tungsten Clustering provides high availability, disaster recovery, and a host of other benefits for MySQL / MariaDB / Percona Server databases. In this blog post we will explore some of the shell aliases I use every day to administer various Tungsten Clusters.
Where are the logs for a Tungsten Cluster and which are the proper log files to monitor if I do a master role switch to another node?
