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

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

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

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

Why Replicate? Redundancy Backups “Load balancing” queries Experimental/transition

Redundancy

Backups

“Load balancing” queries

Experimental/transition

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.

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.

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

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

Gettin' fancy

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

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

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

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

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

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

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”!

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”!

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

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

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)

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)