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 that
> would actually work.  Have you tested to see what what resources it
> saves, if any?  Do you have general scripts for doing such things?
> Also, how do you distinguish what should be replayed vs. what should
> not?
>
>   
The "-a" option for slon, specifying a logshipping directory, does this...

What it does, to be precise, is to capture all of the statements that
the slon is applying to a subscriber, for a given SYNC, and write them
out to a file.

The ordering of the updates will be a "compatible ordering," in that it
reflects the same ordering that the slon uses for a 'first class'
subscriber. 

And with a fully expanded query for each tuple, there is NO problem with
the nondeterminism issues commonly associated with statement replication:

- Any instances of NOW() or usages of nextval('myseq') have been
resolved into actual values;
- Issues where you only modify a non-deterministically-determined set of
tuples cause no confusion because the Slony-I log triggers have recorded
the exact ones that were touched.