How Safe is Asynchronous Master-Master Setup?
•
0 likes•521 views
This document discusses the risks of using asynchronous master-master replication for MySQL databases and provides strategies for setting it up safely. It explains that having two nodes actively accepting writes can lead to conflicts like duplicate key errors. It recommends dividing writes across nodes by database, table, or row to avoid conflicts. The document also discusses using synchronous replication tools like Galera to ensure consistency across nodes at the cost of reduced performance.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to How Safe is Asynchronous Master-Master Setup?
Similar to How Safe is Asynchronous Master-Master Setup? (20)
More from Sveta Smirnova
More from Sveta Smirnova (20)
Recently uploaded
Recently uploaded (20)
How Safe is Asynchronous Master-Master Setup?
- 1. How Safe is Asynchronous Master-Master February, 01, 2020 Sveta Smirnova
- 2. • MySQL Support engineer • Author of • MySQL Troubleshooting • JSON UDF functions • FILTER clause for MySQL • Speaker • Percona Live, OOW, Fosdem, DevConf, HighLoad... Sveta Smirnova 2
- 3. •What Happens with Two Active Nodes? •Why to Write to Multiple Nodes? •Galera, PXC, InnoDB Cluster •How to Setup Safe Asynchronous Master-Master Table of Contents 3
- 4. Master Slave ← Initiates Asynchronous Built-In Replication 4
- 5. Master Slave ← Initiates ← Requests a packet Asynchronous Built-In Replication 4
- 6. Master Sends the packet → Slave ← Initiates ← Requests a packet Asynchronous Built-In Replication 4
- 7. Master Sends the packet → Slave ← Initiates ← Requests a packet ... ? Asynchronous Built-In Replication 4
- 8. What Happens with Two Active Nodes?
- 9. Node1 INSERT SET id=42 Node2 INSERT SET id=42 INSERT 6
- 10. Node1 INSERT SET id=42 Sends the update → Node2 INSERT SET id=42 ← Sends the update INSERT 6
- 11. Node1 INSERT SET id=42 Sends the update → Receives the update → Node2 INSERT SET id=42 ← Sends the update ← Receives the update INSERT 6
- 12. Node1 INSERT SET id=42 Sends the update → Receives the update → Duplicate key error! Node2 INSERT SET id=42 ← Sends the update ← Receives the update Duplicate key error! INSERT 6
- 13. Node1 DELETE WHERE id=42 Node2 DELETE WHERE id=42 DELETE 7
- 14. Node1 DELETE WHERE id=42 Sends the update → Node2 DELETE WHERE id=42 ← Sends the update DELETE 7
- 15. Node1 DELETE WHERE id=42 Sends the update → Receives the update → Node2 DELETE WHERE id=42 ← Sends the update ← Receives the update DELETE 7
- 16. Node1 DELETE WHERE id=42 Sends the update → Receives the update → Key not found error! Node2 DELETE WHERE id=42 ← Sends the update ← Receives the update Key not found error! DELETE 7
- 17. Node1 UPDATE SET i=42 Node2 UPDATE SET i=25 UPDATE 8
- 18. Node1 UPDATE SET i=42 Sends the update → Node2 UPDATE SET i=25 ← Sends the update UPDATE 8
- 19. Node1 UPDATE SET i=42 Sends the update → Receives the update → Node2 UPDATE SET i=25 ← Sends the update ← Receives the update UPDATE 8
- 20. Node1 UPDATE SET i=42 Sends the update → Receives the update → i=25 Node2 UPDATE SET i=25 ← Sends the update ← Receives the update i=42 UPDATE 8
- 21. Why to Write to Multiple Nodes?
- 22. • Each node for its own purpose Application 1 Application 2 Data Distribution 10
- 23. • Multiple machines for better scalability Node 1 Node 2 [Read] Scale 11
- 24. • Nodes in different geographical regions Belgium Brazil GEO Distribution 12
- 25. • Waits when the main master deads • Then accepts writes Active Hot Standby Hot Standby 13
- 26. Galera, PXC, InnoDB Cluster
- 27. Node1 UPDATE ... Node2,3,... Fully Synchronous Cluster 15
- 28. Node1 UPDATE ... Sends the packet → Node2,3,... Fully Synchronous Cluster 15
- 29. Node1 UPDATE ... Sends the packet → Waits Node2,3,... ← Receives the packet Fully Synchronous Cluster 15
- 30. Node1 UPDATE ... Sends the packet → Waits Waits Node2,3,... ← Receives the packet Applies changes Fully Synchronous Cluster 15
- 31. Node1 UPDATE ... Sends the packet → Waits Waits Waits Node2,3,... ← Receives the packet Applies changes ← Confirms Fully Synchronous Cluster 15
- 32. Node1 UPDATE ... Sends the packet → Waits Waits Waits Receives confirmation → Node2,3,... ← Receives the packet Applies changes ← Confirms Fully Synchronous Cluster 15
- 33. Node1 UPDATE ... Sends the packet → Waits Waits Waits Receives confirmation → Ready for new update Node2,3,... ← Receives the packet Applies changes ← Confirms Fully Synchronous Cluster 15
- 34. • Speed of the slowest member Synchronization Penalty 16
- 35. • Speed of the slowest member • Writes or reads should wait Synchronization Penalty 16
- 36. • Speed of the slowest member • Writes or reads should wait • Tunable Synchronization Penalty 16
- 37. • Speed of the slowest member • Writes or reads should wait • Tunable • Galera • wsrep sync wait • InnoDB Cluster • group replication consistency Synchronization Penalty 16
- 38. • Synchronization takes too much time • Nodes often disconnect GEO Replication is Painful 17
- 39. How to Setup Safe Asynchronous Master-Master
- 40. • Business logic • Databases • Tables • Rows Divide and Rule 19
- 41. • Each server writes to its own set of tables Node 1 Node 2 D1 D2 D3 D4 D1 D2 D3 D4 Databases and Tables 20
- 42. • Agreement on which rows Node 1 Node 2 Row 1 Row 2 Row 3 Row 4 Row 1 Row 2 Row 3 Row 4 Rows 21
- 43. • Agreement on which rows • E.g. AUTO INCREMENT • auto increment increment=NUMBER OF SERVERS • auto increment offset = server id • Custom index • Create your own unique pattern for the each node Rows 21
- 44. • Hot Standby • Easy to setup and maintain • Separating writes by database/table • Comparatively easy to setup and maintain • Separating writes by row • Should be used very carefully Conclusion 22
- 45. MySQL User Reference Manual Why MySQL Replication Fails, and How to... MySQL High Availability More information 23