• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MySQL::Replication (Melbourne Perl Mongers 2011-07)
 

MySQL::Replication (Melbourne Perl Mongers 2011-07)

on

  • 4,791 views

 

Statistics

Views

Total Views
4,791
Views on SlideShare
4,777
Embed Views
14

Actions

Likes
8
Downloads
113
Comments
3

2 Embeds 14

http://www.redditmedia.com 11
http://twitter.com 3

Accessibility

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Awesome, I just finished a design doc to do almost the same thing to solve the same issues. I'm going to go look at your work. :)
    Are you sure you want to
    Your message goes here
    Processing…
  • It was for a talk given at Melbourne Perl Mongers. I used ’because’ and ’so’ as breathers between sections of the talk and to wait for any questions about what I just talked about.
    Are you sure you want to
    Your message goes here
    Processing…
  • Seriously, dude, you need to work on how you put slides together. Having a slide with the word 'because' on it makes me want to hit you in the face.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    MySQL::Replication (Melbourne Perl Mongers 2011-07) MySQL::Replication (Melbourne Perl Mongers 2011-07) Presentation Transcript

    • MySQL::Replication
    • what is it?
    • It's a replacement for
    • MySQL Replication
    • why?
    • first...
    • what is replication?
    • synchronising data
    • between multiple databases
    • db1 db2
    • why replicate?
    • examples...
    • redundancy
    • database client client client client client client client client
    • database on client client client client client client client client
    • database on fire client client client client client client client client
    • database on fire client client client client client client client client
    • database on fire client client client client client client client client
    • arhhhh!
    • If we had replicated
    • to a hot standby
    • clients could be moved
    •  
    •  
    • another example
    • performance
    • database client
    • database client client
    • database client client client
    • database client client client client
    • database client client client client client
    • database client client client client client client
    • database client client client client client client client
    • database client client client client client client client client
    • database client client client client client client client client
    • database client client client client client client client client
    • arhhhh!
    • If we replicated
    • for scale out
    • load would be spread
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    • so...
    • why replicate?
    • because it gives you benefits
    • compared to having
    • a single database
    • so...
    • how does it work?
    • in particular...
    • how does MySQL Replication work?
    •  
    • master
    • master slave
    • master client slave
    • master client binlog slave
    • master client binlog slave relay
    • master client binlog slave relay
    • the cool thing is
    • each slave
    • can be a master
    • to other slaves
    • master slave slave slave
    • master slave slave master/slave slave
    • master master/slave slave master/slave slave slave
    • this works fine
    • but...
    • slaves can only have a single master
    • master master/slave slave master/slave slave slave
    • so?
    • that means...
    • no multiple masters
    • slave master master master
    • slave master master master
    • why not?
    • don't ask me
    • because I don't know
    • but...
    • we can emulate multiple masters
    • to do this
    • we have to
    • setup a ring topology
    • what?
    • each slave
    • is a master
    • to another slave
    • master slave
    • master slave master/slave
    • master master/slave master/slave slave
    • master/slave master/slave master/slave master/slave
    •  
    • so...
    • how does this achieve
    • multiple master replication?
    • by having each master
    • write all queries
    • to it's binlog
    • ...including the queries
    • it replicated
    • from its master
    • huh?
    • queries are passed
    • around the ring
    • kind of like
    • pass the parcel
    •  
    • why is this a problem?
    • when the ring breaks
    •  
    •  
    •  
    •  
    •  
    • arhhhh!
    • so does everything else
    • ...and recovery is hard
    • why?
    • infinite loops!
    • what do you mean?
    • each master
    • is responsible
    • for termination
    • of its own queries
    • around the ring...
    • in other words
    • queries don't replicate infinitely
    • because
    • a master won't relay
    • its own queries twice
    •  
    • so...
    • what happens if...
    • a database goes down?
    • we recover by
    • ...reconnecting the links
    • ...and restarting replication
    • ?
    •  
    •  
    • (OpenOffice doesn't do the arrow I wanted)
    • hang on...
    • who was responsible
    • for terminating
    • the failed database's queries?
    • hrmmm...
    • if there are queries
    • from the failed database
    • still replicating
    • that haven't yet terminated
    •  
    • arhhhh
    • Infinite queries, infinitely replicating
    • so...
    • how can I achieve
    • multiple master replication
    • ...that is fault tolerant
    • ...and is easy to recover from?
    • MySQL::Replication
    • It's a replacement
    • for MySQL's built-in replication
    • it's a client/server model
    • each master runs the server
    • slave master master master
    • slave master master server
    • slave server master server
    • slave server server server
    • each slave runs the client
    • ...and the client
    • can run multiple instances
    • (one for each server)
    • (think peer-to-peer)
    • slave server server server
    • client(s) server server server
    • and if something breaks
    • client(s) server server server
    • client(s) server server server
    • client(s) server server server
    • only the peer connection is effected
    • client(s) server server server
    • client(s) server server server
    • and if the failed database recovers
    • we restart from where we left off
    • client(s) server server server
    • client(s) server server server
    • otherwise
    • we just fail it out
    • and can take our time rebuilding
    • it was redundant anyway
    • right?
    • :)
    • ohh
    • ...and no infinite loops
    • why?
    • since we connect
    • directly to the server
    • no intermediary connections
    • can break
    • there's more...
    • relay caching
    • say what?
    • instead of connecting
    • directly to the master
    • the client
    • connects to a local relay
    • if it doesn't have
    • the queries we want
    • it will get them for us
    • example
    • multiple clients
    • in data center A
    • ...each connect
    • to a server
    • in data center B
    • ...each download the same queries
    • what a waste
    • ...in bandwidth
    • ...and server load
    • so...
    • instead
    • ...each connect
    • to a local relay
    • now...
    • only a single client (the relay)
    • connects to the server
    • ...saves bandwidth
    • ...saves server load
    • :)
    • so...
    • CPAN?
    • almost ready
    • client/server working in production
    • I just need to do the documentation
    • then I'll put it on CPAN
    • what about the relay stuff?
    • It's nearly complete...
    • I just need to finish
    • ...a couple more test harnesses
    • ...and write the documentation
    • FAQ
    • what happens with collisions?
    • when two databases
    • update the same record
    • It's a race condition
    • solution?
    • solve it at the application layer
    • use a broker for global IDs
    • or shard writes
    • questions?
    • [email_address]