HAST: split-brain -- how to force one side to become primary?
Freddie Cash
fjwcash at gmail.com
Thu Mar 4 00:31:45 UTC 2010
According to the wiki, when a split-brain situation arises, I should be able
to stop hastd on one side, write changes to the /dev/hast/* providers on the
primary to increment the localcnt valye, and then bring up the secondary
hastd. The locacnt/remotecnt values will be different, and everything will
start to re-sync.
However, this doesn't seem to work. Or, maybe I'm not doing things right to
make it work. Or maybe I've completely misunderstood how it all works.
(Nah, that can never happen. roll-eyes) :)
/dev/hast/* is used to form a raidz1 vdev as part of pool "hapool". There's
a single 1 GB zvol created, that is exported via iSCSI (net/istgt). I can
mount the iSCSI disk on a Linux client, partition it, format it using XFS,
and write data to it. Using only hast2 node as primary, I've written out 10
MB of new data, and verified that the data is there via "zfs list" on hast2,
and multiple mount/unmount cycles on the client. Yet localcnt never
increments beyond 1 (remotecnt is 0).
Is there a way to forcibly increment localcnt on one node, so that bringing
up hastd on the other node will correctly come up as secondary, and start a
sync?
Or, do I have to manually re-do the HAST setup on one side? Or zero out the
base/physical disk underneath HAST?
/etc/hast.conf (only listen line is different between nodes):
# Global section
control /var/run/hastctl
listen 172.20.0.1
replication memsync
# Resource section
resource disk01 {
on hast1 {
local /dev/label/disk01
remote 172.20.0.2
}
on hast2 {
local /dev/label/disk01
remote 172.20.0.1
}
}
resource disk02 {
on hast1 {
local /dev/label/disk02
remote 172.20.0.2
}
on hast2 {
local /dev/label/disk02
remote 172.20.0.1
}
}
resource disk03 {
on hast1 {
local /dev/label/disk03
remote 172.20.0.2
}
on hast2 {
local /dev/label/disk03
remote 172.20.0.1
}
}
resource disk04 {
on hast1 {
local /dev/label/disk04
remote 172.20.0.2
}
on hast2 {
local /dev/label/disk04
remote 172.20.0.1
}
}
hastctl dump on hast1:
resource: disk01
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 1224151284752404553
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk02
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 10884849062207686761
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk03
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 14443609578994823508
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk04
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 1365498106518463540
localcnt: 1
remotecnt: 0
prevrole: primary
hastctl dump on hast2:
resource: disk01
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 1224151284752404553
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk02
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 10884849062207686761
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk03
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 14443609578994823508
localcnt: 1
remotecnt: 0
prevrole: primary
resource: disk04
datasize: 2147478528
extentsize: 2097152
keepdirty: 64
localoff: 4608
resuid: 1365498106518463540
localcnt: 1
remotecnt: 0
prevrole: primary
--
Freddie Cash
fjwcash at gmail.com
More information about the freebsd-fs
mailing list