Re: Replication and PITR

From: Bo Lorentsen <bl(at)netgroup(dot)dk>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Replication and PITR
Date: 2006-09-29 05:59:51
Message-ID: 451CB657.5020504@netgroup.dk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bo Lorentsen 2006-09-29 06:03:09 Re: Replication and PITR
Previous Message snacktime 2006-09-29 05:59:00 using schema's for data separation