Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Usman Ahmad wrote: Hi, it would be easier if you didn't top-post. Thanks. > No, there is no firewall setup, but same question again, it may be > stupid. How long does a drbd node wait for changing the other node to > unknown state ( i guess this is done through different timeout > parameters etc.), and if the other server comes back up again, is it > changed normally or not? First, just in case it wasn't clear, DRBD doesn't change the status of the *local* node; only an external program (e.g. Heartbeat) does that. As for what it shows for the status of the *remote* node, well, I haven't read the code but it normally seems to me to be pretty fast. Again, read the logs: if the local node is primary (and writes are taking place, I think), then you should start seeing "ko" warnings quickly, and how long before the other node is declared dead depends on the "ko-count" configuration option. You will see all kinds of warnings from DRBD when the nodes can't communicate. See also my bug report on this list the other day though, about DRBD not reporting a transition of the remote node to "Unknown" status in the logs. > on-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f"; > halt -f? That's not directly related. This is what happens if the machine is inconsistent and the cluster is degraded when DRBD starts (i.e. the machine should be becoming primary, but it doesn't have a full copy of the data). Tim