Your SlideShare is downloading. ×
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Mysql Replication 4 Idiots
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mysql Replication 4 Idiots


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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