ne of the most sought after features in PostgreSQL is a scalable multi-master replication solution. While there does exists some tools to create multi-master clusters such as Bucardo and pgpool-II, they may not be the right fit for an application. In this session, you will learn some of the strengths and weaknesses of these more popular multi-master solutions for PostgreSQL and how they compare to using Slony for your multi-master needs. We will explore the types of deployments best suited for a Slony deployment and the steps necessary to configure a multi-master solution for PostgreSQL.

3. Founder of Cirrus Technologies

4. Former Chief Architect of EnterpriseDB

8. A vailability

9. P artition Tolerance

11. At the expense of performance

13. Need to deal with conflict resolution

15. PgPool

16. RubyRep

18. Limited to 2 masters

20. Need to deal with Nondeterministic functions

22. Limited to 2 masters

24. Cascading replication

26. The stores control the daily sales information

28. The tables at the stores are read-only

33. Cascading will be necessary with many stores slonik <<_EOF_ cluster name = Store1; node 1 admin conninfo = 'dbname=store1'; node 2 admin conninfo = 'dbname=hq'; init cluster ( id=1, comment = 'Store1 Node'); create set (id=1, origin=1, comment='All Store1 sales tables'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.sales_store1', comment='sales partition'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.sales_line_store1', comment='sales detail partition'); store node (id=2, comment = 'HQ node', event node=1); store path (server = 1, client = 2, conninfo='dbname=store1'); store path (server = 2, client = 1, conninfo='dbname=hq'); _EOF_

35. Need to deal with the complexity of table inheritance

37. All accounts need to be visible

38. Changes to international accounts do occur

40. Unique account identifier across all regions

41. Ping-pong effect

43. FROM accounts

44. WHERE account_no = X

47. SELECT account_id, account_no, account_name,

48. amount, created_date, last_update

49. FROM accounts_tbl

56. Reliance on a central broker

58. PostgreSQL is extremely flexible

59. Together you can do some strange and powerful things

60. Don't use multi-master unless absolutely necessary