Mysql Replication 4 Idiots

2,055 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
2,055
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
57
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mysql Replication 4 Idiots

  1. 1. MySQL Replication <ul><li>What </li></ul><ul><li>Why </li></ul><ul><li>Coolness (ie, tips) </li></ul><ul><li>Craziness (ie, pitfalls) </li></ul><ul><li>Gettin' fancy </li></ul><ul><li>Samples: nice things/bad things that can happen </li></ul><ul><li>Dos and Don'ts </li></ul><ul><li>Why not? </li></ul><ul><li>Summary </li></ul>
  2. 2. What is MySQL Replication? <ul><li>Super simple, easy, efficient way to replay updates on (potentially multiple) other MySQL database server instances </li></ul><ul><li>Features: </li></ul><ul><ul><li>Typically one master </li></ul></ul><ul><ul><li>One or more slaves </li></ul></ul><ul><ul><li>Single binary log feed </li></ul></ul><ul><ul><li>Slaves pull updates </li></ul></ul>
  3. 3. Why Replicate? <ul><li>Redundancy </li></ul><ul><li>Backups </li></ul><ul><li>“Load balancing” queries </li></ul><ul><li>Experimental/transition </li></ul>
  4. 4. Coolness <ul><li>Make your backups totally transparent to users </li></ul><ul><li>Create redundancy (ie, “cold swappability”) for your entire MySQL database infrastructure (potentially) </li></ul><ul><li>Ease load on congested database servers with load balanced queries to multiple slaves (may require code changes) </li></ul><ul><li>Make smooth transitions/upgrades/cutovers </li></ul><ul><li>Can be HETEROGENEOUS! Versatility. </li></ul>
  5. 5. Craziness <ul><li>Sudden “threshold” bugs crash replication, requiring immediate patch </li></ul><ul><li>Not all updates can be safely replayed! </li></ul><ul><ul><li>Famous example: “INSERT DELAYED” </li></ul></ul><ul><ul><li>Heterogeneous master/slave problems </li></ul></ul><ul><li>No way to initially sync databases separately on the same slave </li></ul><ul><li>No free snapshot tools for some storage engines </li></ul>
  6. 6. Gettin' fancy
  7. 7. Nice things <ul><li>Save your binary logs on a backup server; you can roll a point-in-time snapshot forward to arbitrary future points in time, using mysqlbinlog </li></ul><ul><li>Daisy chain to create an entire cold-swappable failover architecture </li></ul><ul><li>Ease transitions and try out new MySQL features using heterogeneous replication configurations </li></ul>
  8. 8. Bad things can happen. Sample scenarios <ul><li>You daisychain but forget to turn on “log-slave-updates” on middle slave; later, you realize mistake, but forget to resync the leaf slave </li></ul><ul><li>You forget to rotate binary logs on master – oops! </li></ul><ul><li>Your log rotation gets disrupted because replication dies on one slave </li></ul><ul><li>A table starts growing too big, slowing down replication </li></ul>
  9. 9. DOs <ul><li>Think about what to replicate </li></ul><ul><li>Try before you buy </li></ul><ul><li>Keep errata lists handy </li></ul><ul><li>Prepare to be surprised! </li></ul><ul><li>Rotate binary logs! </li></ul><ul><li>Monitor disk usage (esp. on master) </li></ul><ul><li>Consider GbE </li></ul><ul><li>Consider heterogeneous engines </li></ul>
  10. 10. DON'Ts <ul><li>Replicate tables and databases thoughtlessly </li></ul><ul><li>Forget to set your grants tables (esp. on slaves) </li></ul><ul><li>Forget to monitor slave lag </li></ul><ul><li>Forget to monitor master disk usage </li></ul><ul><li>Fail to rotate binary logs </li></ul><ul><li>If you daisy chain, DON'T forget “log-slave-updates”! </li></ul>
  11. 11. Why not? <ul><li>Not so good for demanding load balancing needs </li></ul><ul><li>Can require code changes </li></ul><ul><li>Not so good for maximal reliability: expect occasional replication crash recovery </li></ul><ul><li>Not so good for maximal user transparency: lag must be monitored </li></ul><ul><li>If you have several identical, big-iron machines with lots of memory, consider clustering instead </li></ul>
  12. 12. Summary <ul><li>Great versatility </li></ul><ul><li>Easy to set up </li></ul><ul><li>You CAN (will?) get in trouble down the road – all of a sudden! Read errata; keep your pager handy; breath; practice zazen. </li></ul><ul><li>Sometimes code changes may be required </li></ul><ul><li>Some ancillary infrastructure required (eg, third party load balancing solutions, backup and rotation regimes, etc) </li></ul>

×