HDR secondary : new rows not seen on secondary

Hi, I have just setup an HDR replication on IDS 11.70 (FC5). DR_INTERVAL is set to 10 seconds, but when I insert a new row in a test table, I cannot see it on the secondary server even after more than one minute, although the "onstat -l" and "onstat -g dri" on both instances show that the logs have been transfered from primary to secondary. I noticed that the row appear on the secondary if I force a log switch ("onmode -l") or a checkpoint ("onmode -c") The database is buffered logged but I don't think that it makes a difference : I cannot see the new rows even after the logs have been transfered from primary to secondary. So is it a normal behavior ? Does someone have some explanation about it ? Thanks in advance Fabrice

Buffered logging will most definitely make a difference. Stuff will st= ay in the log buffer until it is flushed when it either fills up or when t= he next checkpoint occurs. If you are on a newer version of the server, check the contents for onconfig.std to see if there is any mention of HDR_TXN_SCOPE. If there= is, then you can take advantage of that to push stuff to the secondary serv= er quicker rather than wait for a checkpoint to occur. That way you can s= till use buffered logging and still have near sync HDR. M.Pruet = From: "FABRICE PLATEL" <fplatel@orinux.com> = = To: ids@iiug.org, = = Date: 02/19/2014 05:07 PM = = Subject: HDR secondary : new rows not seen on secondary [32541] = = Sent by: ids-bounces@iiug.org = = Hi, I have just setup an HDR replication on IDS 11.70 (FC5). DR_INTERVAL is set to 10 seconds, but when I insert a new row in a test= table, I cannot see it on the secondary server even after more than one minute= , although the "onstat -l" and "onstat -g dri" on both instances show tha= t the logs have been transfered from primary to secondary. I noticed that the row appear on the secondary if I force a log switch ("onmode -l") or a checkpoint ("onmode -c") The database is buffered logged but I don't think that it makes a difference : I cannot see the new rows even after the logs have been transfered from= primary to secondary. So is it a normal behavior ? Does someone have some explanation about i= t ? Thanks in advance Fabrice ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =

Buffered logging WILL make a difference! Iif the logical log buffer is not flushed yet then the updates are not written to the logical log and so cannot be forwarded to the secondary yet! When you switch logs, the current log buffer is flushed automatically causing it to be forwarded to the secondary and applied there. If you want quick consistency then your databases have to be set up with UNBUFFERED logging! Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Feb 19, 2014 at 6:06 PM, FABRICE PLATEL <fplatel@orinux.com> wrote: > Hi, > I have just setup an HDR replication on IDS 11.70 (FC5). > DR_INTERVAL is set to 10 seconds, but when I insert a new row in a test > table, > I cannot see it on the secondary server even after more than one minute, > although the "onstat -l" and "onstat -g dri" on both instances show that > the > logs have been transfered from primary to secondary. > I noticed that the row appear on the secondary if I force a log switch > ("onmode -l") or a checkpoint ("onmode -c") > The database is buffered logged but I don't think that it makes a > difference : > I cannot see the new rows even after the logs have been transfered from > primary to secondary. > > So is it a normal behavior ? Does someone have some explanation about it ? > > Thanks in advance > Fabrice > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e01175e7df6187904f2ca99e7

Thanks a lot Madison and Art for your answers. effectively it solved the problem, I am just wondering what will be the drawback in term of performance when a lot of concurrent transactions will perform their commits.

In extreme situations you may see the primary being hold by logical log buffer flushing... IF this happens it's easy to spot... You'll see the primary sessions with "G" flag in onstat -u. Proper secondary resources and configuration can help this as well as a good network between both (specifically the round-trip time). But again.... these are extreme situations... Regards On Thu, Feb 20, 2014 at 10:39 AM, FABRICE PLATEL <fplatel@orinux.com> wrote: > Thanks a lot Madison and Art for your answers. > effectively it solved the problem, I am just wondering what will be the > drawback in term of performance when a lot of concurrent transactions will > perform their commits. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a11c28d2060935604f2d4541c

Fernando did some testing of the performance of BUFFERED versus UNBUFFERED logging in his latest blog entry. Check it out. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Feb 20, 2014 at 5:39 AM, FABRICE PLATEL <fplatel@orinux.com> wrote: > Thanks a lot Madison and Art for your answers. > effectively it solved the problem, I am just wondering what will be the > drawback in term of performance when a lot of concurrent transactions will > perform their commits. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0122797adca63a04f2d51552

The link: http://informix-technology.blogspot.sk/2014/02/new-feature-nova-funcionalidade.h tml But I wouldn't call it a comparison in terms of performance and more important it didn't include HDR and that's a key factor here. On the several attempts I've made, naturally buffered logging was consistently faster. But I had only one session, I was running on a VM (where the I/O is naturally bad) etc. I'm not sure if the version was stated, but I'd pay more attention to Madison's suggestion about the new parameters. In an HDR environment, the flush of the logical log buffer copies data to the "replication buffers" which are 12 (not configurable). If there is no space free in these buffers, the primary will slow down (flag G). If you see a lot of G flags you're having this problem. Otherwise you're safe. The complete flux of these buffers are not clearly docuemnted, although there was a chat with the labs about HDR/MACH 11 performance that covered it somehow and I think I've seen some detailed references to how this works... not sure if it was here (probably on a Madison's post) or eventually in internal stuff like PMRs... Good network is important. Also keep in mind (and this is the main point in my article), that BUFFERED logging has durability implications... And most customers prefer full security over some undetermined performance gain (that's why I suggested a new feature and registered it on RFE site). Also note that in BUFFERED mode, Informix may never write the logical log buffer if there is no more activity on the database... Other RDBMs will do it after some time (DB2 seems to write it at most each second, and there are references that mention Oracle would do it at most each 3 seconds, although official documentation is terribly vague - something like "it will flush after a sufficient activity happens" - ) I didn't make this clear on the post because I only verified it later, but if you have a large enough buffer and you're "alone" on the database, if you're using BUFFERED mode, things will stay in the buffer (I think a checkpoint will flush it). Naturally this is not a very usual situation, specially if you have the DB scheduler active. On Thu, Feb 20, 2014 at 11:48 AM, Art Kagel <art.kagel@gmail.com> wrote: > Fernando did some testing of the performance of BUFFERED versus UNBUFFERED > logging in his latest blog entry. Check it out. > > Art > > Art S. Kagel, Principal Consultant > ASK Database Management > > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on the IIUG, nor any other organization with which I am > associated either explicitly, implicitly, or by inference. Neither do > those opinions reflect those of other individuals affiliated with any > entity with which I am affiliated nor those of the entities themselves. > > On Thu, Feb 20, 2014 at 5:39 AM, FABRICE PLATEL <fplatel@orinux.com> > wrote: > > > Thanks a lot Madison and Art for your answers. > > effectively it solved the problem, I am just wondering what will be the > > drawback in term of performance when a lot of concurrent transactions > will > > perform their commits. > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --089e0122797adca63a04f2d51552 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a1133938601c4ce04f2d554de