Investigation run by Marco Tusa

CONCLUSIONS

MySQL/Galera was able to outperform Aurora in all tests — by execution time, number of transactions, and volumes of rows managed. Also, scaling up the Aurora instance did not have the impact I was expecting. Actually it was still not able to match the EC2 MySQL/Galera performance, with less memory and CPUs.

In light of the tests, the recommendations consider different factors to answer the question, “Which is the best tool for the job?” If HA and very low failover time are the major factors, MySQL with Galera is the right choice”.

READ THE FULL STORY AND INVESTIGATION

Introduction

The purpose of this article is to describe how Galera Cluster multi-master replication provides high availability for MySQL beyond simply replicating all updates to multiple nodes.

High availability has multiple dimensions, such as being able to detect and tolerate failures in individual components and be able to recover quickly. We will discuss the different failure modes that can happen in a cluster and how Galera facilitates the detection and recovery from each situation.

Your load balancer and application may be governed by different timeouts and recovery mechanisms, but an operational Galera Cluster will provide a stable foundation to recover the rest of your infrastructure in case of a widespread outage.

Failures of Individual Nodes

Synchronous replication requires the participation of all nodes but a Galera Cluster will detect and automatically remove a node that has gone down within …

This post was written by Seppo Jaakola, CEO of Codership.

There appears to be great misunderstanding as to what MySQL transaction isolation levels Galera CLuster actually supports and how. This blog post tries to give answer to those uncertainties.

Galera Cluster provides SNAPSHOT ISOLATION between transactions running on separate cluster nodes. Transactions running on the same node are isolated by whatever was configured as the transaction isolation level in the MySQL configuration. So, if you have configured the default REPEATABLE READ isolation, transactions issued on the same node will behave under REPEATABLE READ semantics. However, for transactions issued on separate cluster nodes, the ‘first committer wins’ rule of SNAPSHOT ISOLATION is provided, and this will fix the lost update problem that generally hurts REPEATABLE READ isolation.

Therefore, it is not safe for the application to rely on SNAPSHOT …

Codership is pleased to announce the release of Galera Cluster 5.5.42 and 5.6.25 with Galera Replication library 3.12, implementing wsrep API version 25.

Galera Cluster is now available as targeted packages and package repositories for a number of Linux distributions, including Ubuntu, Debian, Fedora, CentOS, OpenSUSE and SLES. Obtaining packages using a package repository removes the need to download individual files and facilitates the deployment and upgrade of Galera nodes.

This and future releases will be available from http://www.galeracluster.com, while previous releases remain available on LaunchPad. The source repositories and bug tracking are now on http://www.github.com/codership.

New features and notable changes in Galera Cluster and the Galera library:

• Various forms of FLUSH that are replicated in traditional MySQL async replication are now also replicated in Galera under TOI …

Introduction

A question frequently asked is how much latency does Galera have in geo-distributed environments. After all, snail mail can also be used for database replication, but the latency will not be acceptable.

Let’s see how Galera performs.

A Two-Datacenter Setup

We start by creating a two-node cluster using a pair of Amazon EC2 regions that are as far apart Internet-wise as it gets – Sydney and São Paulo. The underwater cable maps do not show a direct link between Australia and South America.

The ICMP round-trip time between the two regions is a steady 316 ms:

root@ip-172-31-4-77:/home/ubuntu# ping ec2-54-94-217-199.sa-east-1.compute.amazonaws.com
PING ec2-54-94-217-199.sa-east-1.compute.amazonaws.com (54.94.217.199) 56(84) bytes of data.
64 bytes from ec2-54-94-217-199.sa-east-1.compute.amazonaws.com …

Introduction

With Galera you can construct database clusters where each node is located in a different physical or even geographical location. In this blog post we will show some of the benefits from having such a geo-distributed cluster and the specific Galera features that enable practical replication across WAN links.

Benefits From Geo-Distribution

Geo-distribution allows database to break out from the single data center, which opens a whole new approach to redundancy and performance.

Increased Redundancy

Having database nodes in various geographic locations increases redundancy considerably, so that a local power failure or network outage can not possibly affect all nodes in the cluster. Outages that affect multiple availability zones within a single facility are not unheard of, but Galera allows you to go beyond the availability zones and have a truly multi-datacenter database cluster.

…

Galera Cluster has the ability to add new nodes to the cluster by handling internally the transfer of the entire dataset to the new node. The same procedure, called State Snapshot Transfer (SST), applies to nodes that are rejoining the cluster after being down for a longer period of time.

A lot of operations happen during SST and there are various things that could go wrong. This article describes how to configure our server optimally for SST and how to debug any issues that arise.

The Basics

Let’s first consider all the items that play a role in the preparation and configuration of SST.

Selecting an SST Method

Galera Cluster supports several different methods for performing SST so, before adding a new node, it is worth examining the alternatives:

• rsync is the default method and requires the least amount of setup. Its disadvantage is that the donor node remains locked for all …

If you are using Galera Cluster in multi-master mode, you will most likely run into transaction conflicts if two clients attempt to modify the same row at the same time. Such conflicts are reported a deadlock errors to the application.

Legacy applications are frequently unable to handle transaction conflicts properly and may not provide sufficient information to debug the source of the problem.

If the wsrep_log_conflicts option is set, Galera can output all the information about transaction conflicts that is available to it to the error log. As it is a dynamic option, you can enable it while the server is running, collect some entries for examination, and disable it to avoid filling up the log.

Decoding the Output

The output from wsrep_log_conflicts may look a bit intimidating at first, but in fact contains a lot of information that can be used to pin-point the offending application, module or SQL operation. The …

Relational databases are ubiquitous in OpenStack: practically every OpenStack service stores its critical metadata in a database, and the MySQL family of databases is the de-facto standard for OpenStack relational data storage. The need for high availability for these relational datastores is obvious. Galera is the default multi-master strongly-consistent replication facility for highly-available relational data in OpenStack. In this webinar, we are joined by independent OpenStack expert Florian Haas to illustrate the ins and outs of Galera for OpenStack.

Speaker bio: Florian Haas is an open source software specialist, experienced technical consultant, seasoned training instructor, and frequent public speaker. He has spoken at conferences like LinuxCon, OSCON, linux.conf.au, the OpenStack Summit, the MySQL Conference and Expo, and countless user and meetup groups across the globe.

Duration: 60 minutes

…

Introduction

The Galera Cluster Juju Charm was recently released, and it is now possible to start scalable Galera Clusters using the Juju deployment framework on the public or private cloud (OpenStack, Amazon, Azure and bare metal are all supported). All the logic required to fire up Galera is encapsulated in the Charm, which is a small package of scripts and configuration files that is automatically downloaded and added to your environment.

Installing and Configuring Juju

The Juju client is available for Ubuntu, OSX and Windows. Installing it is a matter of adding its dedicated package repository:

$ sudo add-apt-repository ppa:juju/stable
$ sudo apt-get update && sudo apt-get install juju-core

Then run

$ juju generate-config

in order to create the Juju configuration file, ~/.juju/environments.yaml, which you can then edit for your particular cloud …