On Fri, Nov 21, 2008 at 12:15 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
>
>
> On Thu, Nov 20, 2008 at 8:36 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>>
>> That seems like a dangerous assumption. What if the standby had fallen
>> behind before the failover? It's not safe to failover back to the original
>> primary in that case. We'd need some kind of safeguards against that.
>>
>
> For synchronous replication, what if we ensure that the standby has received
> the WAL (atleast in its buffers) before writing it to disk on the primary ?
> If we do that, I think the old standby can never fall behind the primary and
> it would be easy for the old primary to join back the replication without a
> fresh backup.
In the current patch, since the WAL are written and sent concurrently for
the performance gain, we cannot guarantee whether the old standby fall
behind or not. I think that the setup procedure which can resolve both
cases is required.
> Of course, this doesn't work for async replication.
Yeah, in asynch replication, some committed transaction may disappear
regardless of whether the fresh backup is used or not. But, since the
current patch guarantee "Replicate Ahead Log" rule even if asynch case,
we can recover the old primary by using the WAL on the old standby
consistently.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center