Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

loss of data due to rdun = disabled

Status
Not open for further replies.

Captain1911

Technical User
Feb 26, 2009
14
0
0
NO
Hi. I have some questions about rdun.
I have a 4.50 1000M (61C) The system was with unknown reason showing "rdun = disabled" (edd LD 43) (Why?) Not knowing exactly for how long this status has been on we had a power down caused by a external main power fault, lasting a few hours. This of course,caused the system to go down. On system restart after the main power return. The databases on the two CPU`s was ofcourse different. The restart ocured on the oldest Backup and when "done", the system syncronises, overwriting the newest Database. And redundacy is enabled. (kind of self destructing). Is there any workaraund to avoid this without checking redundansy often. (eg. system restart on latest backup)
 
To my knowledge, the the "Sync" process selects the newer of the two databases, resulting in the system having the latest saved data. All the files have date stamps

In other words, you can Sync any time you want and not have to worry about older data overwriting new data.

However, since there was time between the last EDD and the system reloading, you would have lost changes performed during the time between the last midnight routine and the power loss.

~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
 
I suppose, if the system was never doing an EDD (it automatically attempts one, regardless of 43 being in Midnights), then you could have reverted to data saved quite some time ago.

As for the "solution". Most critical sites have some form of maintenance monitoring that looks for key TTY output, and if detected, "calls for help", opening a service call.

In your case, various CCED and EDD messages would have been output at some time.

~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
 
Hi, Thanks for your reply.
my system is a CPP2 and i dont believe the sync command is valid in this matter.

>ld 137
CIOD000
.sync

CIOD001 Invalid command

The data base it recovers from was about 4 months old.
so we lost some data but we kept a prt of the sets from ld 81.
But, we have seen several systems go from redundansy = enable to disable without any reason. and why is that?
on some systems a unplug/plug of the hsp link cable will start the sync.
othervise a restore of the inactive CPU is nessesary.



 
Doesn't the CP2 and CP4 systems on a sync load the database from core 0?

So if the system has been running on core 1 for a long period of time and all updates were done on core 1's database that would explain your data loss?

I could be wrong but I thought that was how it worked.
 
Yes i agree, it explain the loss of data, but why was the redundance disabled? I dont see why several of our systems sudenly goes into this state. And i would ofcourse like a dual prosessor system to check for the latest backup on restart.
 
can you print LD 135

.stat cpu

John
 
Another poster (who has since "moved on") asked "how can you synch both sides to each other". I'd like to hear others thoughts on that question. Clearly our posters system wasn't synched, since he reverted to old data.


~~~
[©] GHTROUT.com [⇔] A Variety of Free Resources for Nortel Meridian/CS1000 System Administrators
 
I believe that the SYNC command is only applicable to the motorola processors. You use the join command on the pentium processors and the sync process is automatic.

Signature===========================================

Aastra Authorized Reseller
 
The system has now been reprogrammed (lost data)
edd, copied backup frm the "single" folder on the CF card.
CPU`s are redundant:

>ld 135
CCED000
.stat cpu

cp 1 16 PASS -- ENBL

TRUE REDUNDANT
DISK STATE = REDUNDANT
HEALTH = 24
VERSION = Jul 28 2005, 04:14:02
Side = 1, DRAM SIZE = 512 MBytes


cp 0 16 PASS -- STDBY

TRUE REDUNDANT
DISK STATE = REDUNDANT
HEALTH = 24
VERSION = Jul 28 2005, 04:14:02
Side = 0, DRAM SIZE = 512 MBytes
and
>ld 43
EDD000
.edd

DB SEQ NUM = 4098
CONFIG
CIOD157 INFO: FMD 1 is ACTIVE, RDUN is ENABLED

I will follow up the system and see if the redundance will fall out again. and may be why.


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top