Galera

Instead of contributing back to the original project, and in that way benefitting the project as a whole, Percona takes over smaller open-source projects (such as Galera) and larger open source projects (MySQL, MongoDB), then adds some small enhancements (especially when compared to the work done by the original developers), slaps its own name on it and proceeds to make some negative comments against those who have done the hardest work.

This blog is about open source MySQL clustering software, specifically Codership’s Galera Cluster and Percona’s fork of that, XtraDB Cluster. If you are considering using Galera, please use the original version, or please use the version by MariaDB, which is actively supporting the Galera team.

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.

A telco company recently came to us looking for an improvement to their Galera deployment. Their two main complaints were the unplanned downtime forced by Galera Cluster [aka MariaDB Cluster or Percona XtraDB Cluster], and the lack of reliable geo-scale deployment. 

Continuent showed them how our solution, Tungsten Clustering, provides maximum MySQL uptime and is built for geo-scale (active/passive and active/active) MySQL deployments.

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.

Real time database replication is a must for clustering and other key business purposes, like reporting. There are a number of replication technologies available for MySQL, and some are even bundled into various solutions. When choosing a replication methodology, it is paramount to understand just how the data moves from source to target. In this blog post, we will examine how asynchronous, synchronous, and "semi-synchronous" replication behave when used for clustering. Also, we will explore how replication affects database performance and data availability.

This is the first in a series of blog articles that will discuss the changing landscape of open source and money. Or more specifically open source databases and money. And even more specifically MySQL and its all variants (AWS Aurora, MariaDB, Percona Server, RDS/MySQL) and money...In general, there are the following type of companies in the MySQL commercial ecosystem, in order of total annual revenue and addressable market size.