Re: streaming replication breaks horribly if master crashes

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: streaming replication breaks horribly if master crashes
Date: 2010-06-16 20:30:08
Message-ID: 4C18EE0002000025000324BF@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> So, obviously at this point my slave database is corrupted
>>> beyond repair due to nothing more than an unexpected crash on
>>> the master.
>>
>> Certainly that's true for resuming replication. From your
>> description it sounds as though the slave would be usable for
>> purposes of taking over for an unrecoverable master. Or am I
>> misunderstanding?
>
> It depends on what you mean. If you can prevent the slave from
> ever reconnecting to the master, then it's still safe to promote
> it.

Yeah, that's what I meant.

> But if the master comes up and starts generating WAL again, and
> the slave ever sees any of that WAL (either via SR or via the
> archive) then you're toast.

Well, if it *applies* what it sees, yes. Effectively you've got
transactions from two alternative timelines applied in the same
database, which is not going to work. At a minimum we need some
way to reliably detect that the incoming WAL stream is starting
before some applied WAL record and isn't a match.

-Kevin

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-06-16 20:32:45 Re: streaming replication breaks horribly if master crashes
Previous Message Robert Haas 2010-06-16 20:26:16 Re: streaming replication breaks horribly if master crashes