Red Hat Bugzilla – Bug 319221
Incrementally remirror due to temperally unavailable mirror legs
Last modified: 2010-05-18 14:15:52 EDT
In the event of a mirror leg being unavailable, CLVM mirror (RAID 1) needs to be
able to recover without completely recopying the volume. It is acceptable that
the volume is unavailable during this re-sync process.
In what way is the mirror leg "unavailable"?
The current approach is to remove the disk.
Are you asking to do nothing for a while, and then pick-up again when the device
This will not be possible if the log device fails... it will be removed
immediately, so the mirror can proceed. I can be quickly replaced though.
The request revolves around managing temporary connection outages without
completely remirroring the volume. Given that there is no data transaction log,
it would be "ok" to keep the mirror as unavailable while the dirty blocks are
updated. This would mean that the mirror is either "valid" and usable or "not
valid" and that there would be no point-in-time valid state.
not just a cluster mirror problem, but a mirror problem in general - switching
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.
One Usecase for this e.g. is planned datacentre outage.
So if one datacentre is shut down, the mirrored LV could be rebuilt after a maintenance operation in the other datacentre.
Seems this request fits with this BZ.
This is a two node cluster using HA-LVM.
Request to have LVM mirror resync more inline with HP-UX
a. If the mirror goes out of sync, the pv drops from the VG
b. The VG becomes a linear volume
c. And the entire PV has to be remirrored
d In HP-UX the PV stays and each subsequent write gets logged
aa. the admin can then say "ok, I replaced the disk"
bb. even if he hadn't to force a rsync
cc. and the resync is only partial then - only the stale extents
Client would like to have this feauture request escalated.
This will likely not be implemented in RHEL 5, because it will be in a maintenance phase soon. I'm moving this feature request to upstream, it has to be implemented in upstream first, before backporting to RHEL.