The document discusses multi-master replication in database systems, highlighting the benefits of increased availability and performance. It introduces Slony, an asynchronous master-slave replication solution especially effective for retail scenarios, and describes how it can manage data consistency and conflict resolution across multiple geographic locations. The document emphasizes the complexity of implementing such systems and advises caution in using multi-master configurations unless necessary.

1. Multi-Master Replication Using Slony

2. Who Am I? Jim Mlodgenski Co-organizer of NYCPUG

3. Founder of Cirrus Technologies

4. Former Chief Architect of EnterpriseDB

5. What is Mult-Master? Multiple phyiscal servers in a cluster allow for the updating of data Increases Availability

6. Increases performance Most noticable over a WAN

7. CAP Theorem The theory put forth by Brewer that only 2 of the 3 are possible in a distributed system C onsistency

8. A vailability

9. P artition Tolerance

10. Sync vs. Async Synchronous All transactions applied to all server before a success is returned to the client Simpler to design and architect

11. At the expense of performance

12. Sync vs. Async Asynchronous A transaction is applied to a single server before a success is returned to the client About the same performance as a single server

13. Need to deal with conflict resolution

14. Existing Solutions Bucardo

15. PgPool

16. RubyRep

17. Bucardo Asynchronous multi-master, master-slave, event based replication solution Used in several production deployments

18. Limited to 2 masters

19. PgPool Synchronous statement based, multi-master replication solution Much more than a replication solution

20. Need to deal with Nondeterministic functions

21. RubyRep Asynchronous multi-master, event based replication solution Not a PostgreSQL only solution

22. Limited to 2 masters

23. What is Slony? Asynchronous master-slave, event based replication solution Proven production use cases

24. Cascading replication

25. Retail Store Problem Corporate HQ controls the pricing

26. The stores control the daily sales information

27. Retail Store Problem The information pushed down for HQ is exactly what Slony is good at The tables controlled at HQ replicates to the many stores

28. The tables at the stores are read-only

29. Retail Store Problem A single replication set can control this May need to cascade if there are many stores slonik <<_EOF_ cluster name = HQ; node 1 admin conninfo = 'dbname=hq'; node 2 admin conninfo = 'dbname=store1'; node 3 admin conninfo = 'dbname=store2'; node 4 admin conninfo = 'dbname=store3'; node 5 admin conninfo = 'dbname=store4'; node 6 admin conninfo = 'dbname=store5'; init cluster ( id=1, comment = 'HQ Node'); create set (id=1, origin=1, comment='All HQ tables'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.items', comment='items table'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.prices', comment='prices table'); store node (id=2, comment = 'Store1 node', event node=1); store path (server = 1, client = 2, conninfo='dbname=hq'); store path (server = 2, client = 1, conninfo='dbname=store1'); ...

30. Retail Store Problem Replicating all of the stores data to HQ is the challenge Use table inheritance