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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Mysql Replication 4 Idiots

1,578
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
1,578
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
44
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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)