Обсуждение: Synchronous replication: status of standby side
<p><span lang="de"><font face="Arial" size="2">Hi,</font></span><p><span lang="de"><font face="Arial" size="2">will therebe a possibility to retrieve the standby situation in case of synchronous replication ?</font></span><br /><span lang="de"><fontface="Arial" size="2">We would need a command or similar to report the current state and state changes </font></span><br/><span lang="de"><font face="Arial" size="2">(like: syncing, in-sync, replication broken, ..). </font></span><br/><span lang="de"><font face="Arial" size="2">Observing and scaning the logfile would not be appropriate.</font></span><br/><span lang="de"><font face="Arial" size="2">Are there plans for such an interface ?</font></span><spanlang="en-us"> </span><p><span lang="en-us"><font color="#000000" face="Arial" size="2">Best regards</font></span><spanlang="de"> </span><br /><span lang="de"><font color="#000000" face="Arial" size="2">Harald Kolb</font></span>
Kolb, Harald (NSN - DE/Munich) wrote: > Hi, > > will there be a possibility to retrieve the standby situation in case of > synchronous replication ? > We would need a command or similar to report the current state and state > changes > (like: syncing, in-sync, replication broken, ..). > Observing and scaning the logfile would not be appropriate. > Are there plans for such an interface ? Not sure; we have not written all the synchonous replication code yet. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hi, On Thu, Jun 4, 2009 at 12:28 AM, Kolb, Harald (NSN - DE/Munich) <harald.kolb@nsn.com> wrote: > Hi, > > will there be a possibility to retrieve the standby situation in case of > synchronous replication ? > We would need a command or similar to report the current state and state > changes > (like: syncing, in-sync, replication broken, ..). > Observing and scaning the logfile would not be appropriate. > Are there plans for such an interface ? No, not yet. You think that this feature is a high-priority TODO item? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Hi, > -----Original Message----- > From: ext Fujii Masao [mailto:masao.fujii@gmail.com] > Sent: Thursday, June 04, 2009 6:25 AM > To: Kolb, Harald (NSN - DE/Munich) > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Synchronous replication: status of standby side > > Hi, > > On Thu, Jun 4, 2009 at 12:28 AM, Kolb, Harald (NSN - DE/Munich) > <harald.kolb@nsn.com> wrote: > > Hi, > > > > will there be a possibility to retrieve the standby > situation in case of > > synchronous replication ? > > We would need a command or similar to report the current > state and state > > changes > > (like: syncing, in-sync, replication broken, ..). > > Observing and scaning the logfile would not be appropriate. > > Are there plans for such an interface ? > > No, not yet. You think that this feature is a high-priority TODO item? 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, ...). In addition, can we expect that a replication break will be logged as an important event ? Regards, Harald.
Where can I find a more recent version of syncrep patch. The last one that I've here is synch_rep_0428 and I'm getting segfault with it ":(. In Wiki [1] the last is syncrep_0305 [1] http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects []s -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A
Hi, 2009/6/5 Dickson S. Guedes <listas@guedesoft.net>: > > Where can I find a more recent version of syncrep patch. The last one > that I've here is synch_rep_0428 and I'm getting segfault with it ":(. > In Wiki [1] the last is syncrep_0305 > > > [1] http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects Attached is the latest version (but WIP) of synch rep patch. And, I uploaded it into wiki. You can set up synch rep according to the following page. http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#How_to_set_up_Synch_Rep Please feel free to try it! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
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
Em Sex, 2009-06-05 às 16:19 +0900, Fujii Masao escreveu: > 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.. We could have some kind of "table of replication status code" and a "last status code" or a "history of status codes", which is used by clients (psql, pgadmin, etc) to shows the replication status. > And, which server should we ask the status, the primary or the standby server? Is expected that this information resides in both? For example, take a status code like "2) sent to the standby, but not written there yet.", if we expect this in primary, in the stand by must have something like "2) received from primary, but not written here yet." as status code? I guess that would be a good way to check whether and how replication is working in both servers. I agree with you that this feature should be postponed. Best Regards, -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A
Hi, > -----Original Message----- > From: ext Fujii Masao [mailto:masao.fujii@gmail.com] > Sent: Friday, June 05, 2009 9:19 AM > To: Kolb, Harald (NSN - DE/Munich) > Cc: pgsql-hackers@postgresql.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.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. 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.