HDR (crash recovery)
A user tested HDR failover by inserting 200 rows on the primary and then killing the oninit process. The secondary showed only 192 rows, dropped to 100 after a restart, and only reached 200 once the primary was brought back up and replayed its logs. Replies explained this is expected with ASYNC HDR: log buffers are only shipped when the HDR buffer fills or DRINTERVAL expires, so recent commits can lag on the secondary. To guarantee a committed transaction reaches the secondary, use unbuffered logging and set DRINTERVAL to -1 (SYNC mode).
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
We conducted a test to see the business impact if primary server crashes in an
HDR.
We inserted 200 independant inserts in a table. And killed the informix
instance session (got from "onstat -g glo" command).
Here are our findings:
After crash of primary server the table on secondary node was containin 192
rows (out of 200).
We restarted the secondary server, Now the count reduces to 100.
Then we shutdown the secondary server (onmode -sky), and initialized the
primary server(oninit).
Now the primary node showing all 200 rows.
Then we initialized the secondary server as well, the number of rows(in that
table) increased to 200 on secondary server also.
Our questions are:
1- Why 192 rows on secondary server reduced after restart.
2- Why there is difference between commited transactions at primary server and
secondary server after crash of primary server.
regards,
Kamran
First of all, it is hard to believe than 200 insert statements crashed the db
server. You must have done something wrong or you don't know how to configure
the db server.
Regarding your second question, the primary had all the insert statmenets in
the log files and when the secondary server was back up it transferred the
remaining log records to the secondary server.
hth,
esteban.-
--- El jue 2-jul-09, KAMRAN HAQ <khaq@i2cinc.com> escribió:
De: KAMRAN HAQ <khaq@i2cinc.com>
Asunto: HDR (crash recovery) [16215]
Para: ids@iiug.org
Fecha: jueves, 2 de julio de 2009, 10:11 am
Hi,
We conducted a test to see the business impact if primary server crashes in an
HDR.
We inserted 200 independant inserts in a table. And killed the informix
instance session (got from "onstat -g glo" command).
Here are our findings:
After crash of primary server the table on secondary node was containin 192
rows (out of 200).
We restarted the secondary server, Now the count reduces to 100.
Then we shutdown the secondary server (onmode -sky), and initialized the
primary server(oninit).
Now the primary node showing all 200 rows.
Then we initialized the secondary server as well, the number of rows(in that
table) increased to 200 on secondary server also.
Our questions are:
1- Why 192 rows on secondary server reduced after restart.
2- Why there is difference between commited transactions at primary server and
secondary server after crash of primary server.
regards,
Kamran
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
________________________________________________________________________________
____
¡Viví la mejor experiencia en la web!
Descargá gratis el nuevo Internet Explorer 8
http://downloads.yahoo.com/ieak8/?l=ar
It sounds like 1) you might be using buffered logging, 2) You are runni=
ng
HDR in ASYNC mode, and/or 3) that you restarted the secondary by runni=
ng
oninit -PHY.
Are any of these the case?
=
"KAMRAN HAQ" =
<khaq@i2cinc.com> =
Sent by: =
To
ids-bounces@iiug. ids@iiug.org =
org =
cc
=
Subj=
ect
07/02/2009 08:11 HDR (crash recovery) [16215] =
AM =
=
=
Please respond to =
ids@iiug.org =
=
=
Hi,
We conducted a test to see the business impact if primary server crashe=
s in
an
HDR.
We inserted 200 independant inserts in a table. And killed the informix=
instance session (got from "onstat -g glo" command).
Here are our findings:
After crash of primary server the table on secondary node was containin=
192
rows (out of 200).
We restarted the secondary server, Now the count reduces to 100.
Then we shutdown the secondary server (onmode -sky), and initialized th=
e
primary server(oninit).
Now the primary node showing all 200 rows.
Then we initialized the secondary server as well, the number of rows(in=
that
table) increased to 200 on secondary server also.
Our questions are:
1- Why 192 rows on secondary server reduced after restart.
2- Why there is difference between commited transactions at primary ser=
ver
and
secondary server after crash of primary server.
regards,
Kamran
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Database is not crashed because of these inserts rather we crashed it manually by killing the database process as I already described in my previous email. We crashed the instance for test purpose that what would happen if something really goes wrong. Our database is using un-buffered logging in asynchronous mode. My questions are not about why it crashed, I am asking about the behavior of HDR/logging on primary and secondary nodes for steps I performed (given in previous email, all steps I performed are given in same order as I done during test).
I see, you should have explained that you "manually" killed the oninit process.
Anyway, you have answered your own question, since you have un-buffered
logging for you db, and I guess you run separate insert statements each insert
will trigger a buffer flush hence the 200 inserts are in the log files. When
the engine is back up it will send those records to the secondary server as it
has done in your test.
hth,
esteban.-
--- El jue 2-jul-09, KAMRAN HAQ <khaq@i2cinc.com> escribió:
De: KAMRAN HAQ <khaq@i2cinc.com>
Asunto: Re: HDR (crash recovery) [16218]
Para: ids@iiug.org
Fecha: jueves, 2 de julio de 2009, 12:59 pm
Database is not crashed because of these inserts rather we crashed it manually
by killing the database process as I already described in my previous email.
We crashed the instance for test purpose that what would happen if something
really goes wrong.
Our database is using un-buffered logging in asynchronous mode.
My questions are not about why it crashed, I am asking about the behavior of
HDR/logging on primary and secondary nodes for steps I performed (given in
previous email, all steps I performed are given in same order as I done during
test).
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
________________________________________________________________________________
____
¡Viví la mejor experiencia en la web!
Descargá gratis el nuevo Internet Explorer 8
http://downloads.yahoo.com/ieak8/?l=ar
If you run in ASYNC mode, then HDR will not send the HDR log buffers un= til either the HDR buffer is full or the age of the buffer reaches the age = of DRINTERVAL. In order to ensure that the transaction reaches the secondary as part o= f the commit, you must 1) use unbuffered logging and 2) set DRINTERVAL to= -1. = "KAMRAN HAQ" = <khaq@i2cinc.com> = Sent by: = To ids-bounces@iiug. ids@iiug.org = org = cc = Subj= ect 07/02/2009 10:59 Re: HDR (crash recovery) [16218= ] AM = = = Please respond to = ids@iiug.org = = = Database is not crashed because of these inserts rather we crashed it manually by killing the database process as I already described in my previous email. We crashed the instance for test purpose that what would happen if something really goes wrong. Our database is using un-buffered logging in asynchronous mode. My questions are not about why it crashed, I am asking about the behavi= or of HDR/logging on primary and secondary nodes for steps I performed (given= in previous email, all steps I performed are given in same order as I done= during test). ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g