On 12/1/2006 12:06 PM, Andreas Kostyrka wrote: > * 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 sl on> >> > 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.
Oh ... missed that part ... indeed, Hanny wasn't talking about statement based replication at all, but about Slony's log shipping. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
