Webinar slides: Introducing Galera 3.0 - Now supporting MySQL 5.6

7,529
-1

Published on

You'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks. The benefits are clear; a globally distributed MySQL setup across regions to deliver Severalnines availability and real-time responsiveness.

Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:

Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera

Published in: Technology, Travel
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,529
On Slideshare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Webinar slides: Introducing Galera 3.0 - Now supporting MySQL 5.6

  1. 1. Galera Cluster Release 3.0 New Features Seppo Jaakola Codership
  2. 2. Agenda ● Galera Cluster Release History ● Release 3.0 New Features ● ● ● ● WAN Replication 5.6 GTID Support MySQL Replication Support Galera Project www.codership.com 2
  3. 3. 20 Galera Replication Plugin Releases since 2009 www.codership.com 3
  4. 4. 35 Galera Cluster for MySQL Releases since 2009 www.codership.com 4
  5. 5. Galera Cluster 2.0 read & write read & write read & write Read & write access to any node Client can connect to any node There can be several nodes MySQL MySQL MySQL Galera Replication Replication is synchronous www.codership.com 5
  6. 6. Galera Cluster 2.0 read & write read & write read & write Multi-master cluster looks like one big database with multiple entry points a MySQL www.codership.com 6
  7. 7. Galera Cluster 2.0 ➢ Synchronous multi-master cluster ➢ no data loss ➢ no slave lag ➢ no slave failover ➢ For MySQL/InnoDB ➢ 3 or more nodes needed for HA ➢ No single point of failure www.codership.com 7
  8. 8. Galera Cluster 2.0 ➢ Good Performance Optimistic concurrency control ➢ Parallel Replication ➢ Optimized Group Communication ➢ ➢ 99.99% transparent ➢ InnoDB look & feel ➢ Automatic node joining ➢ Works in LAN / WAN / Cloud www.codership.com 8
  9. 9. Galera Cluster 3.0
  10. 10. Galera 3.0 Galera Cluster 3.0 in beta test cycle atm Having focus in: WAN replication – Asynchronous replication topologies – www.codership.com 10
  11. 11. Galera 3.0 Featuring: ● MySQL 5.6 Support ● Optimization for WAN replication ● ● Asynchronous replication topologies ● ● ● Async replication can be interleaved with Galera replication Support for MySQL 5.6 GTID New write set key format ● ● ● Cluster can be divided in segments based on location Makes certification faster A step towards huge transaction support A number of bug fixes and minor improvements www.codership.com 11
  12. 12. MySQL 5.6 Support
  13. 13. MySQL 5.6 Support Galera Cluster 3.0 has support both for MySQL 5.5 and 5.6 versions From Galera perspective, it does not matter much what the DBMS is like, as long as it supports transactions. In MySQL 5.6, interesting new features are: – MySQL GTID – InnoDB full text search – Overall performance improvements www.codership.com 13
  14. 14. MySQL 5.6 Support We will also support MariaDB 10, work is ongoing Percona XtraDB Cluster will also have 5.6 based version coming soon www.codership.com 14
  15. 15. MySQL 5.6 Support Support for MySQL 5.1 is dropped Future releases are for MySQL 5.5 and 5.6 only Release builds now also for FreeBSD www.codership.com 15
  16. 16. WAN Replication
  17. 17. WAN Replication 2.0 Galera 3.0 has new replication mode, which is optimized for WAN networks (or any network with high latencies in general) But, let's first take a look how Galera 2.0 replication looks between data centers www.codership.com 17
  18. 18. WAN Replication 2.0 A-1 A-2 B-1 A-3 B-2 Data center A ● B-3 Data center B All point-to-point connections will be needed for replication www.codership.com 18
  19. 19. WAN Replication 2.0 A-1 A-2 B-1 A-3 B-2 Data center A ● B-3 Data center B All point-to-point connections will be needed for replication www.codership.com 19
  20. 20. WAN Replication 2.0 A-1 A-2 B-1 A-3 B-2 Data center A ● ● B-3 Data center B All point-to-point connections will be needed for replication I said ALL www.codership.com 20
  21. 21. WAN Replication 2.0 Due to using all point-to-point connections, the transaction latency is dictated by the longest latency in the cluster replication mesh Despite of this anomaly, Galera Cluster 2.0 and earlier have been widely used in WAN environments www.codership.com 21
  22. 22. WAN Replication 3.0 A-1 A-2 B-1 A-3 B-2 Data center A ● ● B-3 Data center B Replication between cluster segments go over one link only Replication events will be distributed within each segment p2p www.codership.com 22
  23. 23. WAN Replication 3.0 A-1 A-2 B-1 A-3 B-2 Data center A ● ● ● B-3 Data center B Replication between segments go over one link only Replication events will be distributed within each segment p2p Segment gateways can change per transaction www.codership.com 23
  24. 24. WAN Replication 3.0 commit A-1 B-1 WS A-2 A-3 B-2 Data center A B-3 Data center B www.codership.com 24
  25. 25. WAN Replication 3.0 A-1 WS B-1 WS WS A-2 A-3 B-2 Data center A B-3 Data center B www.codership.com 25
  26. 26. WAN Replication 3.0 A-1 WS B-1 WS A-2 WS A-3 WS B-2 Data center A B-3 Data center B www.codership.com 26
  27. 27. WAN Replication 3.0 Define cluster segments up front, by node location gmcast.segment = 1..255 www.codership.com 27
  28. 28. WAN replication ● Works fine ● Use higher timeouts ● No impact on reads ● No impact within a transaction ● adds 100-300 ms to commit latency ● No major impact on tps ● Quorum between data centers – 3 data centers – Weighted quorum calculation – Garbd arbitrator 28
  29. 29. MySQL Replication Topologies
  30. 30. Galera + MySQL Replication Galera Cluster can operate both as MySQL master and MySQL slave ● ● MySQL master fail over in Galera Cluster has been challenging until now MySQL Slave operation has performance bottleneck Galera 3.0 solves both these problems www.codership.com 31
  31. 31. Galera as MySQL Slave Galera Cluster can operate as MySQL slave in two ways: 1.MySQL master is like client connection to Galera node (version 2 and 3) 2.MySQL replication events will be delivered as pre-ordered events interleaved in Galera replication (new version 3 feature) www.codership.com 33
  32. 32. Galera as MySQL Slave MySQL master MySQL replication Node 1 slave Node 3 Node 2 a www.codership.com 34
  33. 33. MySQL Slave through Galera Replication MySQL replication Slave processing Query processing Commit processing Write set population WS WS replication WS Certification Commit www.codership.com 35
  34. 34. MySQL Slave through Galera Replication MySQL replication Slave processing Query processing Commit processing Write set population WS WS replication WS Certification Commit www.codership.com 36
  35. 35. Async Replication Bottleneck ● As MySQL replication events are treated as regular client transactions, they must go through Galera replication pipeline at commit time ● … and this adds some delay before commit ● MySQL replication is single threaded Galera node will not apply replication events as fast as native MySQL Slave ● MySQL 5.6 “parallel replication” can help – But only, f you have several schemas – MySQL 5.7 and MariaDB 10 will have proper parallel replication www.codership.com 37
  36. 36. MySQL Replication Bundling ● ● ● Replication events can be bundled to commit as a single group Less waiting for replication synchronization wsrep_mysql_replication_bundle=n – ● Groups n mysql replication transactions in one large transaction Helps with the latency, you can go up to 5K trx/sec www.codership.com 38
  37. 37. 3.0 Pre-ordered Replication
  38. 38. Pre-ordered replication MySQL replication Preordered replication Slave processing Query processing Commit M replication G G www.codership.com 40
  39. 39. Pre-ordered Replication ● ● ● ● MySQL replication stream constitutes partial order, which can be interleaved with cluster replication SQL slave thread broadcasts MySQL replication events before applying them Galera replication does not slow down SQL slave thread Note, we expect MySQL replication stream to be conflict free www.codership.com 41
  40. 40. Pre-ordered Replication MySQL master1 MySQL replication G-1 Node 2 M-5 Node1 MySQL slave Galera Replication G-2 G-4 M-3 Node 3 www.codership.com 42
  41. 41. Pre-ordered Replication ● ● Galera nodes will receive and apply MySQL replication events in same order and interleaved with local Galera replication events If MySQL replication has conflicts with Galera events, node will do emergency shutdown ● ● A better approach for dealing with conflicts is under works The usual multi-master conflict scenarios apply here ● ● ● Delete conflict Update conflict Uniqueness conflict www.codership.com 43
  42. 42. MySQL Replication – Multi Source MySQL master1 MySQL replication MySQL master2 Node1 MySQL slave Galera Replication Node2 MySQL slave MySQL replication Node3 MySQL master MySQL replication MySQL www.codership.com slave 44
  43. 43. MySQL Replication – Multi Source Works with both MySQL replication strategies ● “Slave through Galera Replication”, provides certification for MySQL masters – ● Consistency is guaranteed “pre-ordered Replication”, is high speed but requires consistency guarantee from application www.codership.com 45
  44. 44. MySQL 5.6 GTID Support
  45. 45. GTID Support MySQL 5.6 introduces global transaction identifier (GTID), which can greatly ease up the MySQL replication master fail over In Galera Cluster, all nodes will generate different binlog files ● ● Binlog events are same and in same order, but binlog file offsets may vary Galera community has developed miracles to cope with this, it is amazing what a single line of perl code can do www.codership.com 47
  46. 46. Galera Binlogging Node 1 Node 2 Insert into t0... Insert into t0... Mysqld-bin.00007 Mysqld-bin.00008 www.codership.com 48
  47. 47. GTID Support Galera will preserve the MySQL GTID events both in “galera replicated mysql slave” and “pre-ordered replication” methods. Galera nodes will generate Galera Cluster GTID for Mysql replication. MySQL slaves will see the Galera Cluster as one MySQL master Master fail over in Galera Cluster can happen by using the GTID www.codership.com 49
  48. 48. Galera Binlogging Node 1 mysql-GTID-1 Insert into t0... Mysqld-bin.00007 Node 2 mysql-GTID-1 Insert into t0... Mysqld-bin.00008 www.codership.com 50
  49. 49. Galera Binlogging Node 1 mysql-GTID-1 Insert into t0... Node 2 mysql-GTID-1 Insert into t0... mysql-GTID-1 mysql-GTID-1 Mysqld-bin.00007 Mysqld-bin.00008 GTID for Cluster events www.codership.com 51
  50. 50. Certification Key Optimization
  51. 51. Certification Keys Write set contains references for all affected primary, unique and foreign keys These affected keys are also stored in certification index maintained in each node to find out possible multi-master conflicts www.codership.com 53
  52. 52. Certification Key Keys Write set Write set Binlog events Certification index Galera 2.0 Keys Binlog events Certification index Galera 3.0 www.codership.com 54
  53. 53. Certification Keys Galera 3.0 has refactored these key representations so that same compact format can be used in write set and certification index Memory footprint is minimal for each key and fixed length Certification check runs faster on the new format More and larger transactions can run simultaneously without memory issues www.codership.com 55
  54. 54. Huge Transaction Support Key format refactoring is one step forward in huge transaction support However, more work remains for achieving that: ● We still populate the full write set in main memory, so each single transaction must fit in the available RAM LOAD DATA transaction can be split in a series of 10K row transactions wsrep_load_data_splitting = ON | OFF www.codership.com 56
  55. 55. Galera Project
  56. 56. Galera Project ● Galera Cluster for MySQL ● ● ● ● ● 6 years development based on MySQL server community edition Fully open source Active community ~3 releases per year ● ● ● Latest GA release 2.7 Major release 3.0 beta 3.* and 4.0 series in the works www.codership.com 58
  57. 57. Galera Clusters MySQL Community edition www.codership.com 59
  58. 58. Galera Clusters MySQL Community edition WSREP API Galera Replication plugin www.codership.com 60
  59. 59. Galera Clusters Galera Cluster for MySQL MySQL Community edition WSREP API Galera Replication plugin www.codership.com 61
  60. 60. Galera Clusters Galera Cluster for MySQL Percona Server fork MySQL Community edition fork MariaDB WSREP API Galera Replication plugin www.codership.com 62
  61. 61. Galera Clusters Galera Cluster for MySQL Percona Server WSREP API MySQL MariaDB Community edition merge WSREP API merge WSREP API Galera Replication plugin www.codership.com 63
  62. 62. Galera Clusters Percona XtraDB Cluster Galera Cluster for MySQL Percona Server WSREP API MySQL MariaDB Community edition merge WSREP API MariaDB Galera Cluster merge WSREP API Galera Replication plugin www.codership.com 64
  63. 63. End of Part One Please post questions in chat window

×