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