top of page

Galera Cluster for MYSQL & MariaDB The True Multi-Master

World’s Most Advanced Features and Un-Seen Benefits

galera_replication1.png
  • 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

Detection and automatic Eviction of Unreliable Nodes

Topology-aware Replication.

Transaction is sent to each datacenter only once

Traffic Encryption

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

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)

bottom of page