Blog

How the Continuent Proxy selects database cluster nodes for executing read operations.

This is the fifth blog in our ‘High Noon’ comparison series in which we look at the main solutions for MySQL high availability, disaster recovery and geographic distribution. Here we focus on highly available, geo-scale, multi-region MySQL for mission-critical sites and apps with Oracle’s InnoDB Cluster as compared to MySQL clusters with Continuent Tungsten, the only complete, fully-integrated clustering solution for MySQL - on-premises, in the cloud, hybrid-cloud or multi-cloud.

In this short blog post, we examine the impact that setting the Tungsten cluster policy to Maintenance has on the cluster behavior, and specifically the impact on the Tungsten Connector.

This is the next in our ‘High Noon’ comparison series in which we look at the main solutions for MySQL high availability, disaster recovery and geographic distribution. Here we focus on highly available, geo-scale, multi-region MySQL for mission-critical sites and apps with Microsoft Azure Database for MySQL as compared to native MySQL, MariaDB clusters with Continuent Tungsten in the cloud, hybrid-cloud, multi-cloud or on-premises.

In this second post on real-time data replication from MySQL, MariaDB or Percona Server we’re looking at PostgreSQL replication, for example with one practical application using a POD style deployment with MySQL.

This is the next blog in our ‘High Noon’ comparison series in which we look at the main solutions for MySQL high availability, disaster recovery and geographic distribution. Here we focus on highly available, geo-scale, multi-region MySQL for mission-critical sites and apps with Google Cloud (GCP) for MySQL as compared to MySQL, MariaDB clusters with Continuent Tungsten, the only complete, fully-integrated clustering solution for MySQL - on-premises, in the cloud, hybrid-cloud or multi-cloud.

Following the most recent releases of the Tungsten Cluster and Tungsten Replicator AMIs, we’ve recorded two getting started videos with some handy tips and tricks on how the AMIs work, how to avail of them … and how to get started with them!

This blog was written in response to a question about the differences between a 3-node MySQL cluster and a 2-node-plus-a-witness MySQL cluster for MySQL high availability (HA).

This is the second blog in our ‘High Noon’ comparison series in which we look at the main solutions for MySQL high availability, disaster recovery and geographic distribution. Here we focus on highly available, geo-scale, multi-region MySQL for mission-critical sites and apps with Codership’s Galera and its variants (MariaDB Galera and Percona XtraDB Cluster) as compared to MySQL clusters with Continuent Tungsten, the only complete, fully-integrated solution for highly-available MySQL clustering solution - for any version of MySQL, MariaDB, and Percona Server - on-premises, in the cloud, hybrid-cloud or multi-cloud.

This blog discusses Asynchronous versus Synchronous MySQL replication for MySQL clustering. Synchronous replication is viewed as the ‘holy grail’ of clustering. But unfortunately, when something is too good to be true, it often is. Before the Tungsten cluster solution Continuent built two synchronous replication cluster solutions (m/cluster, uni/cluster), but we abandoned those for good reasons.

This is the first blog in our ‘High Noon’ comparison series in which we look at the alternative solutions for MySQL high availability, disaster recovery and geographic-distribution. We focus on highly available, geo-scale, multi-region MySQL for business critical applications as directly compared to Amazon Aurora. Tungsten Clustering makes it easy to deploy and manage highly available MySQL clusters with any version of MySQL, MariaDB, and Percona Server for MySQL on-premises, in the cloud, hybrid-cloud or multi-cloud.

Performing MySQL schema changes often requires downtime for applications. In this blog, we cover two ways we can perform MySQL schema changes without risking downtime or other MySQL data problems. In this real-life customer example, we perform a schema change to modify the column data type from varchar(20) to varchar(50) on approx. 35 tables from 3GB to 10GB in size. Two of the tables are partitioned, and one of them is about 100GB combining all partitions for that table.