On Tue, 2006-09-26 at 08:21 +0200, Bo Lorentsen wrote:
> MySQL only takes care of the replication, not the failover ... but it
> seems like they have some kind of statement queue (no trigger setup) and
> a transfer protocol all integrated in the server, and that makes it
> "simpel". There is no understanding regarding transactions, as far as I
> have seen.
If it's a statement queue, what happens when you do "INSERT ... VALUES
(random())"? Can the statements be executed out of order on the slave or
are they serialized?
> > As I understand it, Slony does batch updates on the slaves, which would
> > be better performance than re-executing every transaction.
> >
> That makes sense ... then the only thing to worry about is where these
> "baches" are written. On the same disk as the master database or on the
> client side, or will it be advisable to use a NFS mount between these to
> machines to balance the disk writing ?
>
The updates are queued on the master and transferred over the network to
the slave. You don't need to do any nfs tricks.
Slony is designed to improve read performance. If you want better write
performance pretty much all you can do is use a better I/O system or
partition the data so that all the data is not stored on every server.
Often, read queries are the bottleneck, so that's why so many people
find replication like slony useful.
Regards,
Jeff Davis