Re: Synchronous replication: status of standby side

Hi,

> -----Original Message-----
> From: ext Fujii Masao [mailto:masao(dot)fujii(at)gmail(dot)com]
> Sent: Friday, June 05, 2009 9:19 AM
> To: Kolb, Harald (NSN - DE/Munich)
> Cc: pgsql-hackers(at)postgresql(dot)org; Czichy, Thoralf (NSN - FI/Helsinki)
> Subject: Re: [HACKERS] Synchronous replication: status of standby side
>
> Hi,
>
> On Thu, Jun 4, 2009 at 7:53 PM, Kolb, Harald (NSN - DE/Munich)
> <harald(dot)kolb(at)nsn(dot)com> wrote:
> > We are planning to use the HotStandby feature too.
> > That would require to have the correct state information
> since we have
> > to
> > control the DB clients when and how they can connect or reconnect.
> > But also in general, from our platform POV it's an
> important feature to
> > have the right view on the system at any point of time
> (e.g. in case of
> > update avoid switchover if standby is out of sync, ...).
>
> I understand that the feature to check the status of
> replication is useful, too.
> On the other hand, I hesitate to make the size of synch rep
> patch bigger.
> Big patch increases the burden on the reviewers. Current
> patch is already big.
> So, I think that this feature should be postponed at least
> until core of
> synch rep will be committed.
>
> BTW. Which kind of status should be detectable when combining
> replication
> with Hot Standby? There are several statuses. For example,
> the last commit
> transaction in the primary server has been;
>
> 1) not sent to the standby server yet.
This would be the standalone mode, otherwise this would mean that the
commit is not yet finished.
So this situation wouldn't be of interest.

> 2) sent to the standby, but not written there yet.
> 3) sent and written, but not fsynced yet.
> 4) sent, written and fsynced, but not applied yet.
> 5) etc..
Mh, all these situations mean a not finished commit, so I cannot see the
problem.
I meant more "global" states, like
- replication off
- replication on
- replication starting (secondary currently synchronizing with primary)
- replication broken (currently in recovery mode (or sth. similar))

>
> And, which server should we ask the status, the primary or
> the standby server?
Both should have the same view and the same state, so it should be
possible to ask both of them.
Normally it would be sufficient to ask the primary, but if the primary
side crashes, it
might be necessary to ask the secondary which is perhaps not yet
triggered to switch to primary mode.

What will happen on the secondary side when this side detects that the
replication breaks down.
Will there be any active activity to solve the problem or does it keep
itsself passive and waits that either
the primary recovers or the trigger file arises ?

>
> > In addition, can we expect that a replication break will be
> logged as an
> > important event ?
>
> Yes, the termination of replication is logged as LOG message
> in the patch.

Ah, sorry for the question, I saw the variuos ereports in the patch now
(and also the replication_broken events from primary and secondary
side). Thanks.

Regards, Harald.