Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Andreas, Thank you so much for your response. Actually the hardware in the dr cluster is exactly the same, except that the DR raid array has more hard disk space. There are currently no other jobs or applications running in the dr cluster, it's only function is to be replicating from the primary cluster. I'm using the Ahead / Behind feature to deal with the fact that we're connected over a WAN, I wonder if that is some how messing up the stack? Unfortunately this happened again today and I had to do an ifdown on the DR eth interface to break the connection in order to get the primary cluster drbd resource to start responding again. :( :( drbdadm disconnect would just time out. Thanks, Ron Andreas Kurz-3 wrote: > > Hello, > > Any chance your DR node has significant different hardware setup, > especially regarding disk and raid controller capabilities? If your DR > node is under high (i/o load) because of e.g. a backup job it might be > unable to cope with DRBD replication at the same time because your i/o > stack is completely overloaded. Add something like "ko-count 6;" to the > net section, this will prevent your primary to block for too long time > though it will also go into Standalone mode which has to be resolved > manually. > > Regards, > Andreas > > -- > Need help with DRBD? > http://www.hastexo.com/now > > -- View this message in context: http://old.nabble.com/Problem-with-stacked-resource-failing-tp33424203p33429449.html Sent from the DRBD - User mailing list archive at Nabble.com.