...and on Wed, Jan 12, 2005 at 10:33:14AM -0800, Dan Hrabarchuk used the keyboard:
> I've never seen "corrupted" replication on MySQL, but I've only ever
> used it on rather lite sites.
> 
> The replication is much lighter on the system though, as it's
> transaction log based.
> 
> Also setting up a new slave is MUCH faster, but you need to make the
> initial copy with a downed server.
> 
> Dan
> 

Hello, Dan.

I'm afraid that's not true. While being the fastest and most "elegant"
solution, there is most certainly the option of saying

    LOAD DATA FROM MASTER

or

    LOAD TABLE tbl_name FROM MASTER

which will populate the new slave with data from the tables directly,
rather than using transaction logs.

It works only with MyISAM tables though, and it acquires a global read
lock on the master, which means no updates are possible during the time
of the load, so it is essentially rather useless, unless you temporarily
set master to a slave replica and later on reset slave counters and
update master to the real one.

My experience with MySQL replication (we had a number of 100+GB databases
where I used to work) is that it is consistant with "the MySQL way" of
doing things - simple for the straightforward tasks, next to impossible
for complex stuff.

It is, if you leave it running and not touch it, rather reliable, for as
long as you optimize both the master and the slaves to be reasonably in
sync with reality, but it may soon become a pain, as MySQL is not too
fool-proof, and nothing prevents you from, for example, deleting a master
log while it is still in use by slaves.

I'm afraid I haven't had sufficient experience with Slony-I so far, so I'm
not able to compare the two. From what I've seen this far though, my gut
feeling is that Slony-I is a different beast alltogether, regarding both
its initial goal (as providing a number of "nodes" of which any one can be
a master for a set data source at any given moment in time) as well as its
overall flexibility.

HTH,
-- 
    Grega Bremec
    gregab at p0f dot net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050113/259a4012/attachment.bin