PostgreSQL Replication


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

PostgreSQL Replication

  1. 1. PostgreSQL Replication T o r o n t o P U G Steven Singer FreeNode: stevenSn July 28 2008
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 11. Slony T o r ● 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. 12. Longdiste T o r ● 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. 13. Bucardo T o r ● o ● Async trigger based n ● Developed by t o ● Allows multi-master writes with P user specified conflict U resolution G
  14. 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. 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. 16. Sequoia T o r ● o ● Middleware n ● Supports multiple RDBMS t o ● Has its own journaling P ● Ensure all SQL writers U understand how it works G
  17. 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. 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. 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. 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. 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. 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. 23. Questions? T o r o n t o P U Steven Singer G FreeNode: stevenSn