Informix HDR

Hi, I'm currently running Informix HDR (IDS 12.10FC8 on Windows server 2012 R2) in Async Mode. I just have a few questions: In Async Mode, the log is flushed to disk without waiting for a confirmation from the Secondary. What happens if a transaction is committed on the Primary and it suffers a failure (e.g. power outage) and the same transaction is still not committed on the Secondary (remains in Read-Only(Sec) mode)? When you bring up the Primary again, how does it know that it still needs to send the same transaction to the Secondary? What also happens if the log is not yet flushed to disk on the Primary and a sudden failure happens? What will happen to those "dirty" logs? Can anyone pls advise.

You are mixing HDR a bit with logging mode. With logging mode set to UNBUFFERED the commit is not allowed to complete until the log containing the commit is flushed to disk. With BUFFERED logging, the transaction is allowed to commit without the commit log being flushed to disk. The log buffers are always written to disk in sequential order so that if the commit has been flushed to disk, then the entire transaction has been flushed to disk. With traditional HDR 'sync/async' mode was controlled by the setting of DRINTERVAL and had to do with the synchronization of the log buffer containing the commit and transmission of that log buffer to the secondary server. If DRINTERVAL was set to -1, then the log buffer would not be set to reuse until the buffer was sent to the secondary and acknowledged. Only then could the log buffer be reused. If DRINTERVAL was greater than zero, then the log buffer would be copied into an HDR transmit buffer and the log buffer would be immediatly reusable. The data in the HDR transmit buffer would be transmitted when it had aged DRINTERVAL seconds or whenever it became full, which ever came first. In both cases the acknowledgement occurred when log buffer was received on the secondary, not when it was applied. In more recent versions of the server, we added HDR_TXN_SCOPE which is used if DRINTERVAL is turned off (i.e. set to zero). This was done to decouple the log buffer from the transmission of the buffer. The reason was that by delaying the reuse of the log buffer had a negative impact on subsequent logging. Instead we coordinated the completion of the commit with the transmission and apply of logs on the secondary. If HDR_TXN_SCOPE is set to FULL_SYNC then the transaction completion is not returned to the client application until the logs of the commit have been applied on the secondary. If set to NEAR_SYNC then control is returned to the client application when the commit log record has been received on the secondary. If set to ASYNC then control is returned as soon as the commit log record has been copied to the HDR transmit buffers. In ALL cases the commit log record is processed on the primary server before any HDR work is done. It will be copied to the log buffer, written to disk if using unbuffered logging - and then enter HDR code. Now about what happens with a power failure on the primary. 1) Any logs in the log buffer will be lost. 2) Any logs in the HDR transmit buffer will also be lost. HDR compares the logs which have been applied on both the primary and the secondary when a reconnect occurs. This is done by comparing the LSN (log sequence number) of the most recent log written on the primary and the secondary. The LSN consists of the unique log file number + the position of that log within the log file. This way the primary will know what has been applied on the secondary and what it needs to send to get the secondary current with the primary. It will then transmit those logs from disk. Once the secondary is current with the primary, then the primary will start sending logs directly from the log buffers and HDR transmit buffers. Madison Pruet Retired and Loving it On Thursday, September 14, 2017 7:00 AM, MUKESH TANUKU <mukeshbt1328@gmail.com> wrote: Hi, I'm currently running Informix HDR (IDS 12.10FC8 on Windows server 2012 R2) in Async Mode. I just have a few questions: In Async Mode, the log is flushed to disk without waiting for a confirmation from the Secondary. What happens if a transaction is committed on the Primary and it suffers a failure (e.g. power outage) and the same transaction is still not committed on the Secondary (remains in Read-Only(Sec) mode)? When you bring up the Primary again, how does it know that it still needs to send the same transaction to the Secondary? What also happens if the log is not yet flushed to disk on the Primary and a sudden failure happens? What will happen to those "dirty" logs? Can anyone pls advise. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi, any situation the secondary is "behind" the primary will be detected and the primary will send the transaction data (or the logs where it is containted). You only lose the transaction when the primary is somehow not able to recover and make the secondary the new primary (or standard). Marcus Haarmann Von: "MUKESH TANUKU" <mukeshbt1328@gmail.com> An: "ids" <ids@iiug.org> Gesendet: Donnerstag, 14. September 2017 14:00:04 Betreff: Informix HDR [39857] Hi, I'm currently running Informix HDR (IDS 12.10FC8 on Windows server 2012 R2) in Async Mode. I just have a few questions: In Async Mode, the log is flushed to disk without waiting for a confirmation from the Secondary. What happens if a transaction is committed on the Primary and it suffers a failure (e.g. power outage) and the same transaction is still not committed on the Secondary (remains in Read-Only(Sec) mode)? When you bring up the Primary again, how does it know that it still needs to send the same transaction to the Secondary? What also happens if the log is not yet flushed to disk on the Primary and a sudden failure happens? What will happen to those "dirty" logs? Can anyone pls advise. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Madison Great explanation Thanks -- Saludos Cordiales Rubén APLEXT AX ERP & TIC www.aplext.com Fono: 2493452 Quito Ecuador On Thu, 2017-09-14 at 09:34 -0400, Madison Pruet wrote: > You are mixing HDR a bit with logging mode. > > With logging mode set to UNBUFFERED the commit is not allowed to complete > until the log containing the commit is flushed to disk. With BUFFERED logging, > the transaction is allowed to commit without the commit log being flushed to > disk. The log buffers are always written to disk in sequential order so that > if the commit has been flushed to disk, then the entire transaction has been > flushed to disk. > > With traditional HDR 'sync/async' mode was controlled by the setting of > DRINTERVAL and had to do with the synchronization of the log buffer containing > the commit and transmission of that log buffer to the secondary server. If > DRINTERVAL was set to -1, then the log buffer would not be set to reuse until > the buffer was sent to the secondary and acknowledged. Only then could the log > buffer be reused. If DRINTERVAL was greater than zero, then the log buffer > would be copied into an HDR transmit buffer and the log buffer would be > immediatly reusable. The data in the HDR transmit buffer would be transmitted > when it had aged DRINTERVAL seconds or whenever it became full, which ever > came first. In both cases the acknowledgement occurred when log buffer was > received on the secondary, not when it was applied. > > In more recent versions of the server, we added HDR_TXN_SCOPE which is used if > DRINTERVAL is turned off (i.e. set to zero). This was done to decouple the log > buffer from the transmission of the buffer. The reason was that by delaying > the reuse of the log buffer had a negative impact on subsequent logging. > Instead we coordinated the completion of the commit with the transmission and > apply of logs on the secondary. If HDR_TXN_SCOPE is set to FULL_SYNC then the > transaction completion is not returned to the client application until the > logs of the commit have been applied on the secondary. If set to NEAR_SYNC > then control is returned to the client application when the commit log record > has been received on the secondary. If set to ASYNC then control is returned > as soon as the commit log record has been copied to the HDR transmit buffers. > > In ALL cases the commit log record is processed on the primary server before > any HDR work is done. It will be copied to the log buffer, written to disk if > using unbuffered logging - and then enter HDR code. > > Now about what happens with a power failure on the primary. 1) Any logs in the > log buffer will be lost. 2) Any logs in the HDR transmit buffer will also be > lost. > > HDR compares the logs which have been applied on both the primary and the > secondary when a reconnect occurs. This is done by comparing the LSN (log > sequence number) of the most recent log written on the primary and the > secondary. The LSN consists of the unique log file number + the position of > that log within the log file. This way the primary will know what has been > applied on the secondary and what it needs to send to get the secondary > current with the primary. It will then transmit those logs from disk. Once the > secondary is current with the primary, then the primary will start sending > logs directly from the log buffers and HDR transmit buffers. > Madison Pruet > Retired and Loving it > > On Thursday, September 14, 2017 7:00 AM, MUKESH TANUKU > <mukeshbt1328@gmail.com> wrote: > > Hi, > > I'm currently running Informix HDR (IDS 12.10FC8 on Windows server 2012 R2) in > Async Mode. I just have a few questions: > > In Async Mode, the log is flushed to disk without waiting for a confirmation > from the Secondary. > > What happens if a transaction is committed on the Primary and it suffers a > failure (e.g. power outage) and the same transaction is still not committed on > the Secondary (remains in Read-Only(Sec) mode)? When you bring up the Primary > again, how does it know that it still needs to send the same transaction to > the Secondary? > > What also happens if the log is not yet flushed to disk on the Primary and a > sudden failure happens? What will happen to those "dirty" logs? > > Can anyone pls advise. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean www.aplext.com AX-ERP & TIC

Thanks a lot Madison. Well Explained. Doubt was cleared. Thank you