Re: rebuilding database through DR fails

although my question remains, in the mean time i was able to find the reason for the crash. i had a long transaction aborted error on the primary that apparently is able to take down the secondary. anyway, i rebuild the server on the primary without any logging on, made an ontape -s -L 0, recovered on the secondary with ontape -p, did the onmode -d again and everything works like a charm. this is great! i now am able to hdr to an offsite location and on top of that can cluster two databaseservers in "update anywhere" mode greatly increasing the maintenance possibilities. whats the added value of xps if you can do all this with ids ? ;-) regards hoyte "Hoyte Swager" <h.swager@chello.nl> wrote in message news:VQBmb.377037$lh.97615776@amsnews02.chello.com... > hi there > if i try to rebuild a database from scratch (dbexport schema+unload data) > on the primary the secondary crashes. > versions are equal and chunk setup at both sides is identical. > > is there a limit to how much data can be replicated in a burst? > > any help appreciated > regards > hoyte > > primary: > Linux vfs1 2.4.21 #2 Wed Aug 13 12:23:17 CEST 2003 i686 unknown > IBM Informix Dynamic Server Version 9.40.UC2E1 -- On-Line -- Up > 01:55:29 -- 471464 Kbytes > > secondary:> Linux dsl 2.4.22 #10 Wed Oct 22 21:14:37 CEST 2003 i686 unknown > IBM Informix Dynamic Server Version 9.40.UC2E1 -- Fast Recovery (Sec) -- > Up 00:00:31 -- 279464 Kbytes> Blocked:CKPT > > > 22:57:38 Assert Failed: DR: Log Record Apply Thread Exited Abnormally.> Internal Error. > A restart of the database server shall be required to correct > this problem. > > 22:57:38 IBM Informix Dynamic Server Version 9.40.UC2E1 > 22:57:38 Who: Session(18, informix@, 0, 0x5141cb28) > Thread(43, dr_secapply, 513ed478, 1) > File: rshdr.c Line: 5497 > 22:57:38 Results: Dynamic Server must abort > 22:57:38 Action: Reinitialize shared memory > 22:57:38 stack trace for pid 13209 written to /ids940uc2e1/dump/af.413e3c0 > 22:57:39 See Also: /ids940uc2e1/dump/af.413e3c0> SENDER IS NULL NO MAIL WILL BE SENT > *** WARNING: IBM Informix Dynamic Server is no longer running. *** > > *** WARNING: IBM Informix Dynamic Server is no longer running. *** > > *** WARNING: IBM Informix Dynamic Server is no longer running. *** > > SENDER IS NULL NO MAIL WILL BE SENT > 22:57:47 rshdr.c, line 5497, thread 43, proc id 13209, DR: Log RecordApply > Thread Exited Abnormally. Internal Error. > A restart of the database server shall be required to correct > this problem. > . > 22:57:47 The Master Daemon Died > 22:57:47 PANIC: Attempting to bring system down> > > > > > >

Hoyte Swager wrote: > although my question remains, in the mean time i was able to find the reason > for the crash. i had a long transaction aborted error on the primary that > apparently > is able to take down the secondary. anyway, i rebuild the server on the > primary > without any logging on, made an ontape -s -L 0, recovered on the secondary > with ontape -p, did the onmode -d again and everything works like a charm. > this is great! i now am able to hdr to an offsite location and on top of > that What you did, and well, was workaround an existing problem. In the latest versions of IDS we've seen a constant change in the engine behaviour when the dr_secapply thread dies. What I personnaly would love to see was a throughout investigation on why the hell the thread dies, and specially why does it die with risk of leaving the server in an inconsistent and unrecoverable error. I've seen it happen because of "excessive" amount of I/O on the secondary. Not a reason that I would consider acceptable. Regards.