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