Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Galera webinar migration to galera cluster from my sql async replication

303 views

Published on

Presenation provides the practical aspects of migrating a database setup based on traditional asynchronous replication to multi-master Galera Cluster. We will discuss the benefits Galera provides and how traditional replication settings, architecture and practices can be converted to Galera Cluster. We will show the steps that are needed to perform the migration with limited or no downtime.

Published in: Software
  • Be the first to comment

Galera webinar migration to galera cluster from my sql async replication

  1. 1. Migrating from MySQL Replication to Galera Cluster Philip Stoev Codership Oy
  2. 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. 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. 4. Agenda • A very quick overview of Galera Cluster • Compare asynchronous to synchronous replication • Demonstrate a migration with no downtime
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Questions • Please use the Question/Chat box in the GoToWebinar panel
  16. 16. Thank You http://www.galeracluster.com Discussion group: codership-team@googlegroups.com

×