GALERA CLUSTER FOR MYSQL AND MARIADB
THE TRUE MULTI-MASTER

Download
Galera Cluster

Benchmark in data loss protection

Galera Cluster for MySQL is  a true Multimaster Cluster based on synchronous replication. Galera Cluster is an easy-to-use, high-availability solution, which provides high system uptime, no data loss and scalability for future growth.

 

World’s most advanced features

  • Synchronous replication
  • Active-active multi-master topology
  • Read and write to any cluster node
  • Automatic membership control, failed nodes drop from the cluster
  • Automatic node joining
  • True parallel replication, on row level
  • Direct client connections, native MySQL look & feel

Un-seen benefits

  • No slave lag
  • No lost transactions
  • Both read and write scalability
  • Smaller client latencies

 

Read about technology behind Galera Cluster >

 

World’s Most Advanced Features and Un-Seen Benefits

  • True Multi-master,  Active-Active Cluster Read and write to any node at any time.
  • Synchronous Replication No slave lag, no data is lost at node crash.
  • Tightly Coupled All nodes hold the same state. No diverged data between nodes allowed.
  • Multi-threaded Slave For better performance. For any workload.
  • No Master-Slave Failover Operations or Use of VIP.
  • Hot Standby No downtime during failover (since there is no failover).
  • Automatic Node Provisioning No need to manually back up the database and copy it to the new node.
  • Supports InnoDB.
  • Transparent to Applications Required no (or minimal changes) to the application.
  • No Read and Write Splitting Needed.
  • Easy to Use and Deploy

Cloud Implementations with Galera Cluster

An additional benefit of Galera Cluster is good cloud support. Automatic node provisioning makes elastic scale-out and scale-in operations painless. Galera Cluster has been proven to perform extremely well in the cloud, such as when using multiple small node instances, across multiple data centers—AWS zones, for example—or even over Wider Area Networks.

  • Optimized Network Protocol.Packets exchanged over WAN only at transaction commit time
  • Topology-aware Replication. Transaction is sent to each datacenter only once
  • Traffic Encryption
  • Detection and automatic Eviction of Unreliable Nodes

Read More about Database 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

Read More about WSREP API

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’s 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.

Read More about Synchronous vs. Asynchronous Replication

Certification Based Replication Method

The main idea in certification-based replication is that a transaction executes conventionally until it reaches the commit point, assuming there is no conflict. This is called optimistic execution.

When the client issues a COMMIT command, but before the actual commit occurs, all changes made to the database by the transaction and primary keys of the changed rows are collected into a write-set. The database then sends this write-set to all the other nodes.

The write-set then undergoes a deterministic certification test, using the primary keys. This is done on each node in the cluster, including the node that originates the write-set. It determines whether or not the node can apply the write-set.

If the certification test fails, the node drops the write-set and the cluster rolls back the original transaction. If the test succeeds, the transaction commits and the write-set is applied to the rest of the cluster.

Read More about Certification Based Replication

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

Use cases

Use case

Read Master

Traditional MySQL master-slave topology, but with Galera all “slave” nodes are capable masters at all times, it is just the application who treats them as slaves. Galera replication can guarantee 0 slave lag for such installations and due to parallel slave applying, much better throughput for the cluster.

Use case

Write scalability

Distributing writes across the cluster will harness the CPU power in slave nodes for better use to process client write transactions. Due to the row based replication method, only changes made during a client transaction will be replicated and applying such a transaction in slave applier is much faster than the processing of the original transaction. Therefore the cluster can distribute the heavy client transaction processing across many master nodes and this yields in better write transaction throughput overall.
 

Use case

WAN Clustering

Synchronous replication works fine over the WAN network. There will be a delay, which is proportional to the network round trip time (RTT), but it only affects the commit operation.

Use case

Disaster Recovery

Disaster recovery is a sub-class of WAN replication. Here one data center is passive and only receives replication events, but does not process any client transactions. Such a remote data center will be up to date at all times and no data loss can happen. During recovery, the spare site is just nominated as primary and application can continue as normal with a minimal fail over delay.

Use case

Latency Eraser

With WAN replication topology, cluster nodes can be located close to cilents.Therefore all read & write operations will be super fast with the local node connection. The RTT related delay will be experienced only at commit time, and even then it can be generally accepted by end user, usually the kill-joy for end user experiences is the slow browsing response time, and read operations are as fast as they possibly can be.

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