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.
When it comes to zero downtime, proxies are the first line components of a cluster. In order to achieve High Availability (HA) for MySQL, MariaDB and Percona Server, a commonly deployed setup consists of configuring load balancers (hardware or software) on top of those proxies.
This blog explains why the Tungsten rollback error exists and why it's important.
In this blog post we will discuss how the managed cross-site replication streams work in a Composite Multi-Master Tungsten Cluster for MySQL, MariaDB and Percona Server.
What are some reasons and strategies for performance tuning Tungsten Replicator when applying to a MySQL target database?
This blog covers INI vs Staging configurations for Secure Shell.
In this blog post we will discuss how to best integrate various Continuent-bundled cluster monitoring solutions with PagerDuty (pagerduty.com), a popular alerting service.
When deploying Tungsten Clustering for MySQL / MariaDB / Percona Server, we always recommend an odd number of Manager nodes in each cluster. Let's take a look at how having an odd number of Managers helps keep a Tungsten Cluster functioning and avoids data corruption scenarios (i.e. "split brain").
When Tungsten Replicator extracts data, the information that has been extracted is written down into the Tungsten History Log, or THL.
You already know about the Tungsten Connector which is the "secret sauce" that routes your application database traffic to the appropriate MySQL data source of your cluster. Have you ever wondered how the Connector keeps track of the cluster configuration? How it always knows which host is the master (or masters in a Composite Multimaster topology), and which are slaves?
