Anton Maksimenkov engineer
Thu Jun 24 09:01:02 PDT 2004
Hi. Sorry for bad english.

  I brief read docs of PostgreSQL (actually, not whole) and Slony. And
some question born in my mind: why it's restricted to only one master?

  Some time ago, before I found Slony, I thought about replication
system with load balancing. System, where all (or most) nodes usually
on-line and work together, while seen as one productive machine.
  Of course, I construct it only in my mind, and some schemes,
algorithms, protocols was discussed on paper with my friend.

  I thought, while nodes connected to some restricted network, which
they use only for replication needs, synchronous work may be achieved.
Ideas was some similar:
1. Read-Write transactions. While 1-st transaction (T1) run on 1-st
machine (M1), 2-nd (T2) wait blocked on 2-d machine (M2) before start.
When T1 commited (it produce change log) on M1, somewhat replicate
changes to M2. Then T2 start (sees changes of T1), and work on M2, while
T3 blocked before start on M1. And so on.
2. Read-Only transactions not way anything, and start immediately.

  It was assumed, that it will be "application" - set of inline
functions. Client will only call this functions. This functions will
work with 2 "threads" - blocking (with dblink), and working.

  For "block" may be used addition transactions started by M2,M3...,
which work only on "master" (let say, M1), using 'dblink'. They try
INSERT 'command_name' on some table, and try LOCK TABLE before it. Work
transaction try LOCK TABLE some tables (in same order) which will be
used in it. Then "blocking" transaction COMMIT, and "working" continues
to work.
  So several RW transactions, which not touch same tables may work
really simultaneously on all machines.

  While it sounds like slower than serializable transactions with
crossed tables in RW commands, it may work just great with many RO
commands, no crossed RW commands... But some hard with stand up after
failover or offline.

  Did anyone think about such system? Or my ideas is really stupid, and
  only possible algorithm when transactions works on one machine (which
Slony implement as I has understood)?

  Is it possible idea for increase performance with Slony: suppose I
have 3 machines, set 1-st origin for table1,2,3, set 2-nd origin for
table4,5,6, set 3-nd origin for table7,8,9. And subscribe with all. Then
I design my application to work with tables using dblink to table's
origin (if it work) or to slave (which will new master, when origin
fail). It's brief overview of idea, but will it cost spent efforts? Or I
only lost functionality?

  I just don't know, where else I can ask.

--
engineer




More information about the Slony1-general mailing list