header-2

Technology behind
Galera Cluster

galera_replication

Galera Replication

  • Galera replication happens at transaction commit time, by broadcasting transaction write set to the cluster for applying
  • Client connects directly to the DBMS and experiences close to native DBMS behavior
  • wsrep API (write set replication API), defines the interface between Galera replication and the DBMS

 

 

Synchronous vs. Asynchronous Replication

The basic difference between synchronous and asynchronous replication is that “synchronous” guarantees that if changes happened on one node of the cluster, they happened on other nodes “synchronously”. “Asynchronous” gives no guarantees about the delay between applying changes on “master” node and the propagation of changes to “slave” nodes. The delay can be short or long – it is a matter of luck. This also implies that if master node crashes, some of the latest changes may be lost.

 

Theoretically synchronous replication has a number of advantages over asynchronous:

 

  • it is always highly available (there is no data loss when one of the nodes crashes, and data replicas are always consistent)
  • transactions can be executed on all nodes in parallel.
  • it can guarantee causality across the whole cluster (SELECT S issued after transaction T will always see the effects of transaction even if it is executed on another node)

 

However in practice synchronous database replication was traditionally implemented via the so-called “2-phase commit” or distributed locking which proved to be very slow. Low performance and complexity of implementation of synchronous replication led to a situation where asynchronous replication remains the dominant means for database performance scalability and availability. Widely adopted open-source databases such as MySQL or PostgreSQL offer only asynchronous replication solution.

 

Certification Based Replication Method

An alternative approach to synchronous database replication using Group Communication and transaction ordering techniques was suggested by a number of researchers (e.g. Database State Machine Approach and Don’t Be Lazy, Be Consistent) and prototype implementations have shown a lot of promise. We combined our experience in synchronous database replication and the latest research in the field to create Galera Replication Toolkit.

Galera replication is a highly transparent and scalable synchronous replication solution for application clustering to achieve high availability and improved performance. Galera-based clusters are:

 

  • Highly available
  • Highly transparent
  • Highly scalable (near linear scalability may be reached depending on the application)

 

Generic Replication Library

Galera replication functionality is implemented as shared library and can be linked with any transaction processing system, which implements the wsrep API hooks. Galera replication library is a protocol stack providing functionality for preparing, replicating and applying of transaction write sets. It consists of:

 

  • wsrep API specifies the interface – responsibilities for DBMS and replication provider
  • wsrep hooks is the wsrep integration in the DBMS engine.
  • Galera provider implements the wsrep API for Galera library
  • certification layer takes care of preparing write sets and performing certification
  • replication manages replication protocol and provides total ordering capabilities
  • GCS framework provides plugin architecture for group communication systems
  • many gcs implementations can be adapted, we have experimented with spread and our in-house implementations: vsbes and gemini

White papers

white_papers

White paper

Minimizing downtime and maximizing elasticity with Galera Cluster for MySQL

Online services today face 3 requirements that are driving the choice of a database clustering solution: 1) The need for continuous operations and greater level of high availability than was traditionally needed, 2) ability to scale-out when service popularity grows – jumps of 20 times overnight increase or more are common, 3) ability to scale-in minimizes infrastructure costs when running on cloud technology.

 

Increasingly, the cost of downtime can be measured directly as lost revenue per second. Studies have estimated that businesses lose $5000 per minute, or $500,000 per outage due to service downtime. Inability to scale-out when needed will similarly incur lost business transactions – often at the very moment when there was a unique opportunity to grow the business!

 

Read the whitepaper here from the link below!

 

Minimizing downtime and maximizing elasticity with Galera Cluster for MySQL


Benchmarks

We have tested each Galera for MySQL release with several DBMS performance benchmarks. Here is a collection of recent most prominent results.

 

 

Codership Benchmarks

 

Benchmark Release Platform Results
sysbench 2.0 Amazon EC2 sysbench in EC2 cluster benchmarking Galera Cluster against MySQL Cluster (NDB) : results
sysbench 0.8pre Amazon EC2 sysbench in EC2 cluster WAN topology, MariaDB/Galera nodes: results
sysbench 0.8pre Amazon EC2 sysbench in EC2 cluster WAN topology, MariaDB/Galera nodes: results
sysbench 0.8pre Amazon EC2 sysbench in EC2 cluster, MariaDB/Galera nodes: results
mysqlslap insert 0.7pre 4 core Xeon 3.4GHz 100% insert benchmark on 1-3 node 64bit 4core servers: results
sysbench 0.6 EC2 large instances Summary of test results with sysbench oltp mode benchmark against 1-4 node Amazon EC2 large instance cluster: sysbench on EC2
sysbench Demo-1 HP Proliant servers Summary of test results with sysbench oltp mode benchmark against 1-4 node physical HP Proliant server cluster: sysbench results
sqlgen Demo-1 HP Proliant servers Summary of test results with sqlgen benchmark against 1-4 node physical HP Proliant server cluster in RBR replication level: sqlgen results
dbt2 Demo-1 Amazon EC2 Summary of test results with dbt2 (TPC-C like) benchmark against 1-4 node cluster in Amazon EC2 cloud: dbt2 results
Drupal benchmark Demo-2 Amazon EC2 Summary of test results with Drupal benchmark against 1-4 node cluster in Amazon EC2 cloud: Drupal results

 

 

Community Benchmarks

 

Author The Test
Henrik Ingo CPU bound test
Henrik Ingo about parallel applying effect
Henrik Ingo diskbound load test
Henrik Ingo diskbound load 2 test
Vadim Tkachenko wsrep overhead test
Erkan Yanar Galera vs semisynch replication
Erkan Yanar Galera Replacing MySQL Replication
Erkan Yanar 4-Node Cluster Perfomance Test

Videos & presentations

MariaDB, the Backward Compatible Branch of MySQL(R) Database Server

Galera Cluster by Henrik Ingo at SkySQL roadshow in Hamburg 2013