I must of miscommunicated here as you're describing PITR replication.
I'm asking about a master failing and the slaving picking up. Now, some
n-time later, how do you recover your master system to be back in sync
with the slave. Obviously, I'm assuming some level of manual recovery.
I'm wondering what the general approach would be.
Consider that on the slave which is now the active server (master dead),
it's possible that the slave's PITR's will be recycled before the master
can come back up. As such, unless there is a, an archival process for
PITR or b, a method of streaming PITR's off for archival, the odds of
using PITR to recover the master (resync if you will) seem greatly
reduced as you will be unable to replay PITR on the master for
synchronization.
Greg
On Mon, 2002-12-16 at 08:02, Shridhar Daithankar wrote:
> On Monday 16 December 2002 07:26 pm, you wrote:
> > I'm curious, what would be the recovery strategy for PITR master-slave
> > replication should the master fail (assuming hot fail over/backup)? A
> > simple dump/restore? Are there/is there any facilities in PorstgreSQL
> > for PITR archival which prevents PITR logs from be recycled (or perhaps,
> > simply archived off)? What about PITR streaming to networked and/or
> > removable media?
>
> In asynchrounous replication, WAL log records are fed to anoter host, which
> replays those transactions to sync the data. This way it does not matter if
> WAL log is recycled as it is already replicated someplace else..
>
> HTH
>
> Shridhar
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting