Galera webinar migration to galera cluster from my sql async replication
Download as PPT, PDF1 like554 views
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.
Galera webinar migration to galera cluster from my sql async replication
- 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