Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Taking a resource down on a primary node does not promote any other
nodes, this has to be done either manually or by a cluster resource manager.
I was unable to reproduce the problem regarding the failed state change
while taking down a resource.
Is this a persistent problem (reproducible on your cluster every time,
with every three-node resource)?
All the various drbdadm primary / up / down combinations I tried worked
with my setup (same DRBD9 commit on a custom built kernel 3.17-rc5).
If the problem persists, some more information on the exact steps you
used to reproduce the problem and the details of the setup (kernel
version, distribution, etc.) would be interesting.
Best regards,
--
: Robert Altnöder
: Developer / Trainer
: LINBIT | Your Way to High Availability
:
: http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT.
On 09/16/2015 08:08 PM, cgasmith at comcast.net wrote:
> While testing drbd 9.0,in a three node mesh, executing drbdadm down r0
> on the primary node does not promote other nodes to primary (no big
> deal as I'll do that with pacemaker) but drbdadm reports it cannot
> detach the block device since it was primary.
>
> /[root at mom3 chucks]# drbdadm status r0/
> /This command will ignore resource names!/
> /r0 role:Primary/
> / disk:UpToDate/
> / mom1 role:Secondary/
> / peer-disk:UpToDate/
> / mom2 role:Secondary/
> / peer-disk:UpToDate/
>
> /[root at mom3 chucks]# drbdadm down r0/
> /r0: State change failed: (-2) Need access to UpToDate data/
> /additional info from kernel:/
> /failed to detach/
> /Command 'drbdsetup down r0' terminated with exit code 17/
>
> even though now from another node the resource IS down
> /[root at mom1 chucks]# drbdadm status/
> /r0 role:Secondary/
> / disk:UpToDate/
> / mom2 role:Secondary/
> / peer-disk:UpToDate/
> / mom3 connection:Connecting/
>
> and it seems to be unable to restore that it was primary, have to
> promote another node to primary and the old primary has to be taken
> down to secondary.
>
>
> So if not a "bug" / "feature" what would be the appropriate sequence,
> 1) demote current primary to secondary
> 2) promote new node to primary
> 3) bring down old primary
>
> I see some trouble brewing with this as I progress to pacemaker and
> begin hard failover testing. (aka power / communication loss on 1 or 2
> nodes at a time)
> -------------------------
> particulars...............
> ---------------------------
> drbd
> version: 9.0.0 (api:2/proto:86-110)
> GIT-hash: 360c65a035fc2dec2b93e839b5c7fae1201fa7d9
> drbd-utils
> Version: 8.9.3 (api:2)
> GIT-hash: c11ba026bbbbc647b8112543df142f2185cb4b4b
>
> [root at mom1 chucks]# drbdadm dump
> # /etc/drbd.conf
> global {
> usage-count yes;
> }
>
> common {
> net {
> protocol C;
> }
> }
>
> # resource r0 on mom1: not ignored, not stacked
> # defined at /etc/drbd.d/r0.res:1
> resource r0 {
> on mom1 {
> node-id 0;
> device /dev/drbd1 minor 1;
> disk /dev/vg_submother1/local_storage;
> meta-disk internal;
> address ipv4 192.168.110.10:7789;
> }
> on mom2 {
> node-id 1;
> device /dev/drbd1 minor 1;
> disk /dev/vg_supermother2/local_storage;
> meta-disk internal;
> address ipv4 192.168.110.20:7789;
> }
> on mom3 {
> node-id 2;
> device /dev/drbd1 minor 1;
> disk /dev/vg_mom3/local_storage;
> meta-disk internal;
> address ipv4 192.168.110.30:7789;
> }
> connection-mesh {
> hosts mom1 mom2 mom3;
> net {
> use-rle no;
> }
> }
> }
>
>
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20151005/d09a441c/attachment.htm>