Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello!
I have configuration of resource:
[root at pan ~]# drbdadm dump A
# resource A on pan: not ignored, not stacked
# defined at /etc/drbd.d/A.res:1
resource A {
floating ipv4 172.16.20.50:11001 {
node-id 0;
device /dev/drbd_A minor 1;
disk /dev/A;
meta-disk /dev/mapper/META2_vg-A;
}
floating ipv4 172.16.20.71:11001 {
node-id 1;
device /dev/drbd_A minor 1;
disk /dev/A;
meta-disk /dev/mapper/META_vg-A;
}
net {
protocol C;
verify-alg sha256;
}
}
If node 172.16.20.71 is primary and connection between them successfully established,
from time to time when I call `drbdadm down A`, I get an error that access to UpToDate data is need. Here's some log:
Sep 7 17:35:06 666 kernel: [881937.955928] drbd A: role( Primary -> Secondary )
Sep 7 17:35:06 666 kernel: [881937.980564] drbd A: Preparing cluster-wide state change 2246176250 (1->0 496/16)
Sep 7 17:35:06 666 kernel: [881937.982451] drbd A: State change 2246176250: primary_nodes=0, weak_nodes=0
Sep 7 17:35:06 666 kernel: [881937.982453] drbd A 172.16.20.50:11001: Cluster is now split
Sep 7 17:35:06 666 kernel: [881937.982454] drbd A: Committing cluster-wide state change 2246176250 (2ms)
Sep 7 17:35:06 666 kernel: [881937.982510] drbd A 172.16.20.50:11001: conn( Connected -> Disconnecting ) peer( Secondary -> Unknown )
Sep 7 17:35:06 666 kernel: [881937.982512] drbd A/0 drbd1 172.16.20.50:11001: pdsk( UpToDate -> DUnknown ) repl( Established -> Off )
Sep 7 17:35:06 666 kernel: [881937.982544] drbd A 172.16.20.50:11001: ack_receiver terminated
Sep 7 17:35:06 666 kernel: [881937.982545] drbd A 172.16.20.50:11001: Terminating ack_recv thread
Sep 7 17:35:06 666 kernel: [881937.986060] drbd A 172.16.20.50:11001: Connection closed
Sep 7 17:35:06 666 kernel: [881937.986086] drbd A 172.16.20.50:11001: conn( Disconnecting -> StandAlone )
Sep 7 17:35:06 666 kernel: [881937.986095] drbd A 172.16.20.50:11001: Terminating receiver thread
Sep 7 17:35:06 666 kernel: [881937.986134] drbd A 172.16.20.50:11001: Terminating sender thread
Sep 7 17:35:06 666 kernel: [881937.986173] drbd A: State change failed: Need access to UpToDate data
Sep 7 17:35:06 666 kernel: [881937.986176] drbd A/0 drbd1: Failed: disk( UpToDate -> Detaching )
If I call it next time, operation is usually success.
If I set resource role to secondary before go down, it is more successful than calling `down` from primary resource.
Questions: What is absolutely correct way to down a resource without such error?
Is there some special sequence of commands required?
What this error does ever mean?
Information about DRBD:
[root at pan ~]# drbdadm --version
DRBDADM_BUILDTAG=GIT-hash:\ 98b6340c328b763a11c6fb63a6dc340722621ac2\ build\ by\ root at pan\,\ 2017-08-24\ 12:48:41
DRBDADM_API_VERSION=2
DRBD_KERNEL_VERSION_CODE=0x090008
DRBD_KERNEL_VERSION=9.0.8
DRBDADM_VERSION_CODE=0x090000
DRBDADM_VERSION=9.0.0