Skip site navigation (1) Skip section navigation (2)

Re: Simplifying replication

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying replication
Date: 2010-10-19 18:12:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Oct 19, 2010 at 9:16 AM, Josh Berkus <josh(at)agliodbs(dot)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

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.


In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-10-19 18:20:25
Subject: Re: Simplifying replication
Previous:From: Marios VodasDate: 2010-10-19 17:46:18
Subject: gist DatumGetPointer returns pointer to corrupted data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group