mysql-multi-master-state-of-art-2013-04-24_0

Recommendations

Info

Eventually Consistent Design • MySQL servers are completely independent • Replication provides multi-way links • Transfer is asynchronous • Links can be down for days or weeks if required • It is the application’s responsibility to ensure there are no con"icts ©Continuent 2013 40
Asynchronous Multi-Master in Action SFO Replicator LAX Service sfo Service lax Service nyc Service sfo Service sfo Service lax Service nyc NYC Service lax Service nyc Replicator Best practice: Do not log slave updates ©Continuent 2013 41
Page 1 and 2: State of the Art for MySQL Multi-Ma
Page 3 and 4: Why Do We Care About Multi-Master?
Page 5 and 6: Consistency In a Single DBMS Transa
Page 7 and 8: Ensuring Distributed Consistency Tr
Page 9 and 10: Communication Implies Latency Trans
Page 11 and 12: MySQL Native Replication (Aka the b
Page 13 and 14: Row vs. Statement Replication • S
Page 15 and 16: Auto-Increment Key O!sets • Set d
Page 17 and 18: MySQL Multi-Master Topologies Maste
Page 19 and 20: MySQL Cluster ©Continuent 2012 19
Page 21 and 22: MySQL Cluster Cross-Site Topology T
Page 23 and 24: MySQL Cluster Summary • Allows ac
Page 25 and 26: How It Works: Group Communication S
Page 27 and 28: New Node Start-Up and SST (Initiali
Page 29 and 30: Optimistic Locking in Action (galer
Page 31 and 32: Galera Replication Performance Sysb
Page 33 and 34: Fixing Broken Nodes • IST (= incr
Page 35 and 36: Galera Summary • Big plus #1: sim
Page 37 and 38: How It Works: Eventual Consistency
Page 39: Tungsten Replication Service Pipeli
Page 43 and 44: Failure Handling • Replication st
Page 45 and 46: Connect to Master when Slave Fails
Page 47 and 48: Wide Range of Topologies All Master
Page 49 and 50: What Will Be in Next Year’s Talk?
Page 51 and 52: Better Programming Models Planes th
Page 53: 560 S. Winchester Blvd., Suite 500

mysql-multi-master-state-of-art-2013-04-24_0

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?