Codership’s first Galera Cluster for MySQL webinar “hit a home run” in the world series of webinars.  One of the attendees said: “The Webinar was one of the best I have attended.  The fluff was minimized and the tech presentation hit a home run” .

Take a look Codership’s Galera Cluster® for MySQL Installation and Quick Start recorded webinar

http://galeracluster.com/videos/galera-cluster-installation-and-quick-start/

There will be other  Galera Cluster for MySQL webinars coming from the developers and experts of Galera Cluster, so stay tuned.

Galera, Galera Cluster and Galera Replication are registered trademarks of Codership.

Codership is pleased to announce the release of Galera Cluster 5.5.48 and 5.6.29 with Galera Replication library 3.15, implementing wsrep API version 25.

The library is now available as targeted packages and package repositories for a number of Linux distributions, including, RHEL, 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. The source repositories and bug tracking are now on http://www.github.com/codership .

This release incorporates all changes up to MySQL 5.5.48 and 5.6.29.

New features and notable fixes in Galera replication since last binary release by Codership (3.14):

• fixes for compiling on Alpha / HP PA / s390x architectures (codership/galera#389)
…

Codership is pleased to announce the release of Galera Cluster 5.5.47 and 5.6.28 with Galera Replication library 3.14, implementing wsrep API version 25.

The library is now available as targeted packages and package repositories for a number of Linux distributions, including, RHEL, 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. The source repositories and bug tracking are now on http://www.github.com/codership .

This release incorporates all changes up to MySQL 5.5.47 and 5.6.28.

New features and notable fixes in Galera replication since last binary release by Codership (3.13):

• use system ASIO library when compiling, if available (codership/galera#367)
…

The results in the survey were very favourable to Galera Cluster providing high availability for MySQL and OpenStack components. Galera Cluster with MariaDB received second place, Galera with MySQL fifth place and Galera with Percona Server (Percona XtraDB Cluster) sixth place. Altogether Galera Cluster with three different MySQL variants is clearly the most popular database high availability solution for OpenStack users.

This survey report analyzes respondents who completed or updated the survey during a two-week window in September 2015, and questions represent some modifications from prior surveys in keeping with the evolution of the OpenStack platform. This survey represents a snapshot of 1,315 users and 352 deployments, provided voluntarily. The User Survey is not a market survey and does not express …

Codership is pleased to announce the release of Galera Cluster 5.5.46 and 5.6.27 with Galera Replication library 3.13, implementing wsrep API version 25.

Galera Cluster is now available as targeted packages and package repositories for a number of Linux distributions, including Ubuntu, Red Hat, 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:

• security fix for the LogJam issue. The key length used for creating Diffie-Hellman keys has been increased to 2,048 bits.
• a …

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 …