On Tue, Oct 19, 2010 at 9:16 AM, Josh Berkus <josh@agliodbs.com> wrote:
> Well, one thing to be addressed is separating the PITR functionality from
> replication. PITR needs a lot of features -- timelines, recovery stop
> points, etc. -- which replication doesn't need or want. I think that
> focussing on streaming replication functionality and ignoring the archive
> logs case is probably the best way to logically separate these two.
> Presumably anyone who needs archive logs as well will be a professional
> DBA.
The way things stand you *always* need archived logs. Even if you have
streaming set up it might try to use archived logs if it falls too far
behind.
Also all the features PITR needs are needed by replication as well.
Recovery stop points are absolutely critical. Otherwise if your
replica crashed it would have to start over from the original clone
time and replay all logs since then.
Timelines are not as obvious but perhaps that's our own mistake. When
you fail over to your replica shouldn't the new master get a new
timelineid? Isn't that the answer to the failure case when a slave
finds it's ahead of the master? If it has already replayed logs from a
different timelineid in the same lsn range then it can't switch
timelines to follow the new master. But if it hasn't then it can.
--
greg