This document summarizes migrating from MySQL replication to Galera Cluster. It describes Galera Cluster as providing synchronous multi-master replication with automatic failover. The migration procedure involves converting an existing asynchronous slave to Galera, building up the Galera Cluster to the desired size, switching readers and writers over to the cluster, and then deactivating the original asynchronous replication. Key benefits of Galera Cluster include strong consistency, high availability, and ability to join new nodes automatically.

1. Migrating from MySQL Replication
to Galera Cluster
Philip Stoev
Codership Oy

2. 2
Codership
Established 2007 (Galera development started).
Production version 2009
3 co-founder engineers:
Seppo Jaakola, CEO, Teemu Ollakka, CTO, Alex Yurchenko, architect
Team have developed three MySQL cluster software earlier.
Based on: http://www.dsn.jhu.edu/~yairamir/Yair_phd.pdf
http://www.inf.usi.ch/faculty/pedone/Paper/199x/These-2090-Pedone.pdf
Product: Galera Cluster for MySQL, open source
Thousands of users in e-commerce, telecom, gaming, insurance, betting, healthcare,
media, marketing, advertising, travel, universities, software-as-service, Paas, Iaas, etc
Galera Cluster is included and will be included in Linux and OpenStack distros

3. 3
Galera Cluster variants
API
MySQL
Coderhips’s Galera Replication plugin
API
Percona
Server
API
MariaDB
merge
merge
Percona calls Galera
Percona XtraDB Cluster
Galera Cluster for MySQL by Codership
MariaDB calls Galera
MariaDB Galera Cluster or
MariaDB Enterprise Cluster

4. Agenda
• A very quick overview of Galera Cluster
• Compare asynchronous to synchronous replication
• Demonstrate a migration with no downtime

5. Galera Cluster Overview
Synchronous
– each transaction is immediately replicated on all nodes at commit
– no stale slaves
Multi-Master
– read from and write to any node
– automatic transaction conflict detection
Replication
– a copy of the entire dataset is available on all nodes
– new nodes can join automatically
For MySQL
– based on a modified version of MySQL (5.5, 5.6 with 5.7 coming up)
– InnoDB storage engine

6. And more …
• Recovers from node failures within seconds
• Data consistency protections
– avoids reading stale data
– prevents unsafe data modifications
• WAN support
– nodes can be on different continents
– end-to-end encryption
– optimized communication with least latency

7. Synchronous Replication
Galera replication is synchronous
• Replication happens at COMMIT time:
– network delays can slow down the commit
– but disk I/O can be avoided
• Virtually no slave lag:
– nodes can be behind only by a
very small number of transactions
– cluster will be throttled if a node falls behind
– options are available for less strict operation

8. Multi-Master
Every Galera node can process any database update
• Conflicts are detected at COMMIT time
– application must be able to detect the error and retry whole
transaction
• Instant fail-over
– no need for an external procedure to promote new master
• Any load-balancer can be used
– Codership provides GLB, which works at the TCP level
– some language Connectors can do it internally

9. Monitoring and Configuration
• Entire Galera configuration is in my.cnf
– CHANGE MASTER is not used
– master.info, relay-log.info, etc. are not used
• SHOW SLAVE STATUS is not used
– SHOW STATUS LIKE ‘wsrep_%’ provides status information
• Important status variables:
– wsrep_cluster_status
– wsrep_flow_control_paused

10. Galera And The Binary Log
• Galera uses row-based binary log events for replication
– binlog_format=ROW is required
– wsrep-forced-binlog-format=ROW can also be useful
• But Galera does not use binary log files
– log-bin is not necessary unless binlog files are needed for
some other purpose, such as point-in-time backup
– log-slave-updates ensures that all updates made on any
node are reflected in the binlog files or all nodes
– relay log is not used

11. Adding New Nodes
Galera takes care of the details:
• No need to manually ship data files
– Galera supports taking a non-blocking
snapshot from existing node via XtraBackup
• No need to manually track positions or perform replay
– Galera will fetch and replay whatever data is required
– node will not answer queries unless it is fully up to date

12. Hybrid Operation
• Galera Cluster can be a slave to traditional replication
– all updates from the async master are replicated
to all Galera nodes
– very useful during migrations
• Galera can be a master to async replication
– so you can have special-purpose slaves
(non-InnoDB, time-delayed, etc.)
– log_slave_updates must be set

13. Migration Procedure
1. Convert an existing async slave to Galera
2. Build up the cluster to the desired size
3. Switch readers to read from the cluster
4. Switch writers to write to the cluster
5. Deactivate the async replication altogether

14. Setup
• At start: • At end:
node 1
node 2
node 3
writes
reads
async
master
async
slave
async
slave
Writes
async
master
async
slave
reads

15. Questions
• Please use the Question/Chat box in the GoToWebinar
panel

16. Thank You
http://www.galeracluster.com
Discussion group:
codership-team@googlegroups.com