Migrating from MySQL Replicationto Galera Cluster

Philip StoevCodership Oy

2

CodershipEstablished 2007 (Galera development started). Production version 2009 3 co-founder engineers:Seppo Jaakola, CEO, Teemu Ollakka, CTO, Alex Yurchenko, architectTeam have developed three MySQL cluster software earlier.

Based on: http://www.dsn.jhu.edu/~yairamir/Yair_phd.pdfhttp://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

Galera Cluster variants

API

MySQL

Coderhips’s Galera Replication plugin

API

PerconaServer

API

MariaDB

mergemerge

Percona calls Galera Percona XtraDB Cluster

Galera Cluster for MySQL by CodershipMariaDB calls Galera MariaDB Galera Cluster or MariaDB Enterprise Cluster

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

Galera Cluster OverviewSynchronous

– 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

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

Synchronous ReplicationGalera 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

Multi-MasterEvery 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

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 

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

Adding New NodesGalera takes care of the details:• No need to manually ship data files

– Galera supports taking a non-blockingsnapshot 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

Hybrid Operation• Galera Cluster can be a slave to traditional replication

– all updates from the async master are replicatedto 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

Migration Procedure1. Convert an existing async slave to Galera2. Build up the cluster to the desired size3. Switch readers to read from the cluster4. Switch writers to write to the cluster5. Deactivate the async replication altogether

Setup• At start: • At end:

node 1

node 2

node 3

writes

reads

asyncmaster

asyncslave

asyncslave

Writes

asyncmaster

asyncslave

reads

Questions

• Please use the Question/Chat box in the GoToWebinar panel

Thank You

http://www.galeracluster.com

Discussion group:

codership-team@googlegroups.com