On 12/1/2006 11:09 AM, David Fetter wrote:
> On Fri, Dec 01, 2006 at 02:51:38PM +0200, Hannu Krosing wrote:> ?hel kenal p?eval, R, 2006-12-01 kell 11:19, kirjutas Victoria Parsons:> > Hi,> > > > I have been using slony to replicate two database from a master> > machine to a varied number of slaves on a production system. The> > maximum that has been tested is 12. I have been asked how many we> > could get up to. From following the mailing list I have got an idea in> > my head of no more than about 20. This is because of the increased CPU> > each slon daemon uses. I know this could be increased to some extent> > by getting a more powerful machine for my master.> > > > There is talk here of replicating two databases to 1024 machines. I'm> > pretty sure that will fall over in a big heap. Has anyone ever tried> > that many? I have never used the log shipping method - would that help> > by reducing load on the master? Also I run all slon daemons from the> > master server. Would it become more scalable if I moved the slon>
 > daemons to each slave in the system.> > I'd try the following approach : > * run 1 slon slave wherever you want and ask them to save SQL commands > in text files> * move these text files ( using whatever means ) to slaves and apply> there using shell scripts.
> This sounds like a *great* way to do statement-based replication thatwould actually work.  Have you tested to see what what resources itsaves, if any?  Do you have general scripts for doing such things?Also, how do you distinguish what should be replayed vs. what shouldnot?
> Cheers,D-- David Fetter <david at fetter.org> http://fetter.org/phone: +1 415 235 3778        AIM: dfetter666                              Skype: davidfetter
> Remember to vote!_______________________________________________Slony1-general mailing listSlony1-general at gborg.postgresql.orghttp://gborg.postgresql.org/mailman/listinfo/slony1-general

Statement based replication in an MVCC system is error prone!

Just consider the following little flow of events:

X1: begin;
X1: set transaction isolation level read committed;
X2: begin;
X2: set transaction isolation level read committed;
X1: update foo set bar = 1 where baz = 5;
X1: commit;
X2: update foo set bar = 2 where baz < 20;
X2: commit;

In a concurrent environment, you have a race condition between X1's 
update and X2's update. How do you know exactly which one happened first 
in the database?

And now add 10 other transactions updating foo to that.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #