The True Multi-Master
Galera Cluster for MariaDB is a true Multi-Master Cluster based on synchronous replication. It’s an easy-to-use, high-availability solution, which provides high system up-time, no data loss and scalability for future growth.
World’s Most Advanced Features and Un-Seen Benefits
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 Table.
- Transparent to Applications: Required no (or minimal changes) to the application.
- No Read and Write Splitting Needed.
- Easy to Use and Deploy.
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 solutions.
