Hi,
On Thu, Jun 4, 2009 at 7:53 PM, Kolb, Harald (NSN - DE/Munich)
<harald.kolb@nsn.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.
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..
And, which server should we ask the status, the primary or the standby server?
> 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center