Re: Replication and PITR - Mailing list pgsql-general

From Bo Lorentsen
Subject Re: Replication and PITR
Date
Msg-id 451CB657.5020504@netgroup.dk
Whole thread Raw
In response to Re: Replication and PITR  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-general
Jeff Davis wrote:
> 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?
>
That is very relevant, and my ref to MySQL replication was only the
relatively ease of its setup. And in most of the situation it works OK,
but it has its limits and is not to be trusted 100% (I had to make
special test records to see if the queue was stock).

I Just imagined PITR data used instead of SQL update queues, for
replication.
> The updates are queued on the master and transferred over the network to
> the slave. You don't need to do any nfs tricks.
>
Ok, nice ... as long as Slony don't write local files there is no
problem. I really have to start reading about Slony, to understand it
better ... I may get surprised :-)
> 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.
>
Classic for databases :-)
> Often, read queries are the bottleneck, so that's why so many people
> find replication like slony useful.
>
Yes and that goes for me too.

/BL


pgsql-general by date:

Previous
From: Casey Duncan
Date:
Subject: Re: Expected accuracy of planner statistics
Next
From: Bo Lorentsen
Date:
Subject: Re: Replication and PITR