Deployment

Customers often use AWS to deploy MySQL or MariaDB Tungsten Clusters. This blog is about changing an AWS instance type from t2.large to t3.large specifically on Amazon Linux 1. It contains the steps to follow when changing AWS instance families to use enhanced networking.

Migrating from Galera to Tungsten Clustering is easy with the tools provided by Tungsten Clustering. Because replication happens in the background, applications can stay online with a quick cutover to Tungsten Clustering when ready.

Customers often ask where they should install their MySQL, MariaDB, or Percona MySQL database proxies for high availability clusters, and how many. What is optimal for you may not be the right configuration for everyone. However there are some best practices we’ll discuss in this basic blog about deploying MySQL database proxies.

This blog article discusses why and how we use Ansible (automation tool for pre-configuring MySQL servers) for Tungsten purposes at Continuent, including a step by step description on how to use Ansible (including source code).

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").

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?

This blog discusses some of the ways you can configure your MySQL / MariaDB / Percona Server slaves using Tungsten Clustering.