* Jan Wieck <[EMAIL PROTECTED]> [061201 18:00]: > 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 <[EMAIL PROTECTED]> http://fetter.org/phone: +1 415 > > 235 3778 AIM: dfetter666 Skype: > > davidfetter > > Remember to > > vote!_______________________________________________Slony1-general mailing > > [EMAIL PROTECTED]://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?
Well, it's not statement based. It's basically a feature of slony, that allows to "export" all the statements it applies to it's own slave => These statements are in fact generated out of the data captured on writeable master by the slony triggers. Andreas _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
