Galera - Synchronous Multi-Master Replication Cluster for MySQL/InnoDB

Galera features

Galera provides the following 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 row level replication
• Direct client connections
• Drop-in replacement for native MySQL

Galera benefits

Benefits using Galera Replication:

• High Availability
• No slave lag
• No lost transactions
• No more data inconsistency
• Smaller client latencies
• Read scalability and write throughput improvement (3 times and more, depending on your workload<)

Notes about Galera

Some notes about Galera the synchronous Replication for MySQL:

• Synchronous true multi-master MySQL/Galera Replication can substitute MySQL Cluster, asynchronous MySQL Master-Master Replication and Schooner.
• Galera is sometimes seen as competitor of MySQL Cluster with the big advantage of using the general purpose Storage Engine InnoDB.
• Galera does NOT need binary logging enabled but can.
• Galera can be used as Master for normal asynchronous MySQL Replication. For this binary logging has to be enabled and log_slave_updates has to be switched on. (How is a "channel failover" done when this specific master node dies?)
• For caching the Binlog Events Galera used the MySQL Transaction Cache (IO_CACHE) where it grabs the Binlog Events during commit time. Binlog Events do not have to be written to disk.
• The MySQL Transaction Cache (IO_CACHE) behaves like mmap (however mmap behaves?) with disk part for buffering too large transactions. (When it is on disk we have a possible I/O bottleneck under high load?)
• There is a small delay replicating Events to the Replication Group (sounds like asynchronous). This delay comes from the group communication layer. The packets must be sent to the other nodes an it takes certain time. However delay is minimal.
• Hot-spots (for example Queues, Counters or Sequences) in Galera are non optimal for performance. This is the case when a single row is modified by several transaction concurrently (for example counters). This causes transactions which must be rolled back. This is eats performance.