Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Nov 29, 2013 at 04:05:07PM +0800, Mia Lueng wrote:
> In my cluster(node1/node2) with drbd, the state in /proc/drbd is
> primary/secondary up2date/up2date, but when I change primary to node2 , the
> file that existed on node1 can not be found on node2.
> Then I do "drbdadm verify drbd0" to verify and resync the data, node2's
> data returned to be OK.
>
> I am wondering how the problem occurs and how I can avoid it?
>
> BTW: I build a PV/VG/LV on drbd0, and drbd0 is built on a LV too. Is this
> the reason?
You likely have:
----------------
Filesystem [DRBD] -------- [DRBD] remote node
\ /
\ /
[logical volume]
(DRBD does not see or know about any changes done by Filesystem)
You need:
---------
[Filesystem]
|
[DRBD] -------- [DRBD] remote node
/
[logical volume]
Or, adding the "sandwitch" layer
THIS IS WRONG:
-------------
Filesystem
[LV]
[PV] [DRBD] -------- [DRBD] remote node
\ /
[logical volume]
(DRBD does not see or know about any changes done by Filesystem)
You need it to look like this:
------------------------------
Filesystem
[LV]
[PV]
[DRBD] -------- [DRBD] remote node
/
[logical volume]
(DRBD sees every change done by the Filesystem, and thus
has a chance to replicate the changes over).
Ok?
If you trigger a resync of all (or all changed, as found by verify)
blocks, of course everything that is in the bottom level
will (temporarily) be identical again and look ok.
But all changes bypassing DRBD will obviously be missed, so the replication
target will be inconsistent or outdated or worse quickly.
So don't bypass DRBD.
Lars
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed