multi-master replication with slony
TRANSCRIPT
PRESENTATION NAME
Multi-Master Replication
Using Slony
Who Am I?
Jim MlodgenskiCo-organizer of NYCPUG
Founder of Cirrus Technologies
Former Chief Architect of EnterpriseDB
What is Mult-Master?
Multiple phyiscal servers in a cluster allow for the updating of dataIncreases Availability
Increases performanceMost noticable over a WAN
CAP Theorem
The theory put forth by Brewer that only 2 of the 3 are possible in a distributed systemConsistency
Availability
Partition Tolerance
Sync vs. Async
SynchronousAll transactions applied to all server before a success is returned to the clientSimpler to design and architect
At the expense of performance
Sync vs. Async
AsynchronousA transaction is applied to a single server before a success is returned to the clientAbout the same performance as a single server
Need to deal with conflict resolution
Existing Solutions
Bucardo
PgPool
RubyRep
Bucardo
Asynchronous multi-master, master-slave, event based replication solutionUsed in several production deployments
Limited to 2 masters
PgPool
Synchronous statement based, multi-master replication solutionMuch more than a replication solution
Need to deal with Nondeterministic functions
RubyRep
Asynchronous multi-master, event based replication solutionNot a PostgreSQL only solution
Limited to 2 masters
What is Slony?
Asynchronous master-slave, event based replication solutionProven production use cases
Cascading replication
Retail Store Problem
Corporate HQ controls the pricing
The stores control the daily sales information
Retail Store Problem
The information pushed down for HQ is exactly what Slony is good atThe tables controlled at HQ replicates to the many stores
The tables at the stores are read-only
Retail Store Problem
A single replication set can control thisMay need to cascade if there are many stores
slonik