1. PostgreSQL Replication
T
o
r
o
n
t
o
P
U
G Steven Singer
ssinger_pg@sympatico.ca
FreeNode: stevenSn
July 28 2008

2. Who am I
T SELECT * FROM pg_user where name='Steve'
o
r ● PostgreSQL user since 6.5
o ● Author of contrib/dbmirror
n included with 7.x
t ● Software developer for a local
o consulting company
P
U
● Occasional contributor to side
projects
G

3. The Golden Rule
T
o
r ● You can't have everything
o ● What you want != what you
n need
t ● Determine need from
o requirements
P
U
● Be prepared to accept trade-
offs
G
● If you've already been sold on
Oracle RAC, go and buy RAC

4. The Choices
T
o pgcluster
pl/proxy
r slony
pgcluster-II
Mammoth
o dbmirror RepDB
n longdist Bucardo
t pgpool
Cybercluster
o pgpool-II
erserve
rserv
P Sequioa NTT WAL shipping
U PITR
pg_dump/pg_restore
G postgres-r pyReplica EDB Replicator

5. Why Replication?
T
o
r ● Because it is fun?
o ● So you can buy twice the
n number of licenses?
t ● To distribute your data?
o
P
● So you can be buzzword
U compliant?
G

6. Fail-Over
T
o
r ● Goal: To have additional
o database servers standing by in
n case of:
t – Hardware Failure
o – DBA/Application mistakes
P – Maintenance
U ● Turning on a standby means
G failing the master

7. Automatic or manual
T
o
r ● Who makes the decision to
o promote a slave to a master?
n ● Computer or human?
t ● Look at your possible failures,
o how can you detect them?
P
U
● When will the wrong decision
be made?
G

8. Load Balancing
T
o
r ● Goal: Improve performance by
o adding more servers
n ● Master slave or multi-master?
t ● You can only do queries on
o slaves
P
U
● Multi-Master is really hard
G

9. Load Balancing : slaves
T
o
r ● Send queries to slaves
o ● Run query parts on machines
n and combine results
t ● Partition some data across
o servers (sharding)
P
U
● Topic on its own
G Question: How stale will you allow your slaves to be?

10. Trigger based
T Replication
o
r ● Slony, Longdiste, Bucardo
o ● Uses ON INSERT,ON
n UPDATE,ON DELETE triggers
t ● Slaves jump between consistent
o snapsnots of master
P
U
● Asynchronous
G ● Performance impact on master
● No triggers will fires on DDL

11. Slony
T
o
r ● www.slony.info
o ● Developed by Afillias
n ● Async trigger based,
t master/slave
o
P
● Most widely deployed Postgreql
U replication solution
G ● Very flexible
● Allows for complicated setups
● Some rough edges

12. Longdiste
T
o
r ● https://developer.skype.com/Sk
o ypeGarage/DbProjects/SkyTools
n ● Async trigger based, master
t slave
o ● Part of SkyTools from Skype
P
U
● Based on experience with Slony
but simpler; less features
G
● Can't cascade slaves
● No switchover support (Today)

13. Bucardo
T
o
r ● http://bucardo.org
o ● Async trigger based
n ● Developed by backcountry.com
t
o ● Allows multi-master writes with
P user specified conflict
U resolution
G

14. Middleware based
T statement replication
o
r ● pgpool-II, pgcluster, Continuent,
o GridSQL
n ● Sits in-between your application
t and PostgreSQL
o ● Redirects SQL to one or more of
P your databases
U ● How do you know all databases
G contain the same data?

15. Middleware - Issues
T
o ● INSERT INTO x VALUES (rand())
r ● Functions/Stored Procedures, or
o timestamps are a bad idea
n ● How do you ensure things
t happen in the same order on all
o nodes?
P ● What if a COMMIT on the
U second node fails?
G
● Limitations fine for some
applications

16. Sequoia
T
o
r ● http://sequoia.continuent.org/Hom
o ● Middleware
n ● Supports multiple RDBMS
t
o ● Has its own journaling
P ● Ensure all SQL writers
U understand how it works
G

17. PITR
T
o
r ● Point-In Time Recovery
o ● WAL segments are sent to the
n slaves
t ● Aysnc (today)
o
P
● Can't query slaves (today)
U unless you bring them up
G ● Rolling slaves with ZFS?
● Only good for failover (today)

18. Multi-Master
T
o
r ● If the same row is changed on
o two servers around the same
n time?
t ● Solving this in the general
o sense is really hard.
P ● Don't go here unless you
U need to
G

19. Works in progress
T
o
r ● Not Production Ready
o ● Serious technical problems to
n be worked out
t ● If your up for a challenge
o
P
● Good place to spend your RAC
U budget
G

20. postgres-r
T
o
r ● Multi Master based on a group
o communication system
n ● All nodes process all
t statements in the same order
o (total order)
P ● Depends on a GCS like Spread
U ● Recently open-sourced
G

21. pgcluster-II
T
o
r ● Multi Master
o ● Shared disc
n ● Presented at pgconn 07 not
t released
o
P
● Status unknown
U
G

22. Rules of Thumb
T
o
r ● PITR if it will meet your needs
o ● Slony or Longdiste if you need
n to query your slaves
t ● Find a way around multi-master
o
P
● Avoid statement based
U solutions if consistency is
important
G

23. Questions?
T
o
r
o
n
t
o
P
U Steven Singer
G ssinger_pg@sympatico.ca
FreeNode: stevenSn