Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I'm trying to test the 0.7.11 version of drbd (upgrading from 0.6 on a
2.4 kernel).
In order to test the new detach functionality, I did |drbdadm detach drbd0|.
This seemed to work, with the system going into DiskLessClient state,
and postgresql continuing to work as expected.
[root at dbtools01.syd ~]# cat /proc/drbd
version: 0.7.11 (api:77/proto:74)
SVN Revision: 1807 build by root at build03.syd.optusnet.com.au, 2005-07-27 16:07:12
0: cs:DiskLessClient st:Primary/Secondary ld:Consistent
ns:10119312 nr:1052948 dw:11172260 dr:551285 al:128 bm:516 lo:0 pe:0 ua:0 ap:0
I then wanted to reattach drbd to its drive. A reattach failed, since
the device was still primary (drbd_ioctl_set_disk: (mdev->state != Se
condary)). I then did a takeover onto the other node, and that produced:
Jul 28 08:45:08 dbtools01 kernel: drbd0: Primary/Secondary --> Secondary/Secondary
Jul 28 08:45:08 dbtools01 kernel: drbd0: drbd_md_write: (!inc_local_md_only(mdev)) in /usr/src/redhat/BUILD/drbd-0.7.11/drbd/drbd_main.c:1991
Jul 28 08:45:09 dbtools01 kernel: drbd0: mdev->backing_bdev==NULL
Jul 28 08:45:09 dbtools01 kernel: [<f8a45e78>] drbd_determin_dev_size+0x160/0x2e7 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a4d38a>] drbd_recv+0x8f/0x23c [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a50cc0>] receive_param+0x552/0xa23 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a5076e>] receive_param+0x0/0xa23 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a518fe>] drbdd+0xbd/0x10d [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a525ac>] drbdd_init+0xde/0x2d0 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a58c19>] drbd_thread_setup+0x81/0x147 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a58b98>] drbd_thread_setup+0x0/0x147 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb
Jul 28 08:45:09 dbtools01 kernel: drbd0: mdev->backing_bdev==NULL
Jul 28 08:45:09 dbtools01 kernel: [<f8a45f7b>] drbd_determin_dev_size+0x263/0x2e7 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a4d38a>] drbd_recv+0x8f/0x23c [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a50cc0>] receive_param+0x552/0xa23 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a5076e>] receive_param+0x0/0xa23 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a518fe>] drbdd+0xbd/0x10d [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a525ac>] drbdd_init+0xde/0x2d0 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a58c19>] drbd_thread_setup+0x81/0x147 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<f8a58b98>] drbd_thread_setup+0x0/0x147 [drbd]
Jul 28 08:45:09 dbtools01 kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb
Jul 28 08:45:09 dbtools01 kernel: drbd0: Secondary/Secondary --> Secondary/Primary
Jul 28 08:45:09 dbtools01 kernel: drbd0: drbd_md_write: (!inc_local_md_only(mdev)) in /usr/src/redhat/BUILD/drbd-0.7.11/drbd/drbd_main.c:1991
But it still seemed fine:
[root at dbtools01.syd ~]# cat /proc/drbd
version: 0.7.11 (api:77/proto:74)
SVN Revision: 1807 build by root at build03.syd.optusnet.com.au, 2005-07-27 16:07:12
0: cs:DiskLessClient st:Secondary/Primary ld:Consistent
ns:10119692 nr:1052948 dw:11172260 dr:551285 al:128 bm:516 lo:0 pe:0 ua:0 ap:0
Then on giveback, the system started doing a full sync:
Jul 28 08:45:48 dbtools01 kernel: drbd0: drbdsetup [6568]: cstate Connected --> Unconnected
Jul 28 08:45:48 dbtools01 kernel: drbd0: drbd0_receiver [1707]: cstate Unconnected --> BrokenPipe
Jul 28 08:45:48 dbtools01 kernel: drbd0: short read expecting header on sock: r=-512
Jul 28 08:45:48 dbtools01 kernel: drbd0: worker terminated
Jul 28 08:45:48 dbtools01 kernel: drbd0: asender terminated
Jul 28 08:45:48 dbtools01 kernel: drbd0: drbd0_receiver [1707]: cstate BrokenPipe --> Unconfigured
Jul 28 08:45:48 dbtools01 kernel: drbd0: Connection lost.
Jul 28 08:45:48 dbtools01 kernel: drbd0: receiver terminated
Jul 28 08:45:48 dbtools01 kernel: drbd0: drbdsetup [6568]: cstate Unconfigured --> Unconfigured
Jul 28 08:45:52 dbtools01 kernel: drbd0: size = 139 GB (146669568 KB)
Jul 28 08:45:53 dbtools01 kernel: drbd0: 0 KB marked out-of-sync by on disk bit-map.
Jul 28 08:45:53 dbtools01 kernel: drbd0: Found 6 transactions (324 active extents) in activity log.
Jul 28 08:45:53 dbtools01 kernel: drbd0: Marked additional 128 MB as out-of-sync based on AL.
Jul 28 08:45:53 dbtools01 kernel: drbd0: drbdsetup [6576]: cstate Unconfigured --> StandAlone
Jul 28 08:45:53 dbtools01 kernel: drbd0: drbdsetup [6579]: cstate StandAlone --> Unconnected
Jul 28 08:45:53 dbtools01 kernel: drbd0: drbd0_receiver [6580]: cstate Unconnected --> WFConnection
Jul 28 08:45:53 dbtools01 kernel: drbd0: drbd0_receiver [6580]: cstate WFConnection --> WFReportParams
Jul 28 08:45:53 dbtools01 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74
Jul 28 08:45:53 dbtools01 kernel: drbd0: Connection established.
Jul 28 08:45:53 dbtools01 kernel: drbd0: I am(S): 1:00000003:00000001:00000029:00000009:11
Jul 28 08:45:53 dbtools01 kernel: drbd0: Peer(P): 1:00000003:00000001:0000002c:00000009:10
Jul 28 08:45:53 dbtools01 kernel: drbd0: drbd0_receiver [6580]: cstate WFReportParams --> WFBitMapT
Jul 28 08:45:53 dbtools01 kernel: drbd0: Secondary/Unknown --> Secondary/Primary
Jul 28 08:45:55 dbtools01 kernel: drbd0: drbd0_receiver [6580]: cstate WFBitMapT --> SyncTarget
Jul 28 08:45:55 dbtools01 kernel: drbd0: Resync started as SyncTarget (need to sync 146669568 KB [36667392 bits set]).
Is this expected behaviour? I would have expected that the quick resync
would have taken place.
Takeover/giveback were done using the heartbeat commands.
Bradley