Eugene Vilensky wrote:
> Greetings,
>
> I've hit this exact 'bug':
>
> https://bugzilla.redhat.com/show_bug.cgi?id=491311
>
> I need to remove the mappings manually. I assume this is done via 'multipath
> -F' followed by a 'multipath -v2' ? Has anyone experienced doing this on a
> production system? We can do it during hours of low activity, but we would
> prefer to keep the databases on this host online at the time. The LUNs
> themselves are completely removed from the host and are not visible on the
> HBA bus.
Just wondering what sort of impact this has to your system? If the
paths are gone they won't be used, so what does it matter?
I have a couple batch processes that run nightly:
- One of them takes a consistent snapshot of a standby mysql database
and exports the read-write snapshot to a QA host nightly
- The other takes another consistent snapshot of a standby mysql
database and exports the read-write snapshot to a backup server
In both cases the process involves removing the previous snapshots
from the QA and backup servers respectively, before re-creating new
snapshots and presenting them back to the original servers on the
same LUN IDs. Part of the process I do delete *all* device mappings
for the snapshotted luns on the destination servers with these
commands:
for i in `/sbin/dmsetup ls | grep p1 | awk '{print $1}'`; do
dmsetup remove $i;
done
for i in `/sbin/dmsetup ls | awk '{print $1}'`; do
dmsetup remove $i;
done
I just restart the multipathing service after I present new LUNs
to the system. Both systems do this daily and have been for about
two months now and it works great.
In these two cases currently I am using VMWare raw device mapping
on the remote systems so while I'm using multipath, there is only
1 path(visible to the VM, the MPIO is handled by the host). Prior
to that I used software iSCSI on CentOS 5.2 (no 5.3 yet), and I
did the same thing, I did the same thing because I found restarting
software iSCSI on CentOS 5.2 to be unreliable(more than one kernel
panic during testing). The reason I use MPIO with only 1 path is
so that I can maintain a consistent configuration across systems,
don't need to worry about who has one path or who has 2 or who
has 4, treat them all the same, since multipathing is automatic.
On CentOS 4.x with software iSCSI I didn't remove the paths I just
let them go stale. I restarted software iSCSI and multipath as
part of the snapshot process(software iSCSI is more solid as far
as restarting goes under 4.x, had two panics in 6 months with multiple
systems restarting every day). Thankfully I use LVM because the device
names changed all the time, at some point I was up to like /dev/sddg.
But if your removing dead paths, or even restarting multipath on
a system to detect new ones I have not had this have any noticeable
impact to the system production or not.
I think device mapper will even prevent you from removing a device
that is still in use.
[root@dc1-backup01:/var/log-ng]# dmsetup ls
350002ac005ce0714 (253, 0)
350002ac005d00714 (253, 2)
350002ac005d00714p1 (253, 10)
350002ac005cf0714 (253, 1)
350002ac005d10714 (253, 4)
350002ac005ce0714p1 (253, 7)
san--p--mysql002b--db-san--p--mysql002b--db (253, 17)
350002ac005d10714p1 (253, 9)
350002ac005d20714 (253, 3)
san--p--mysql002b--log-san--p--mysql002b--log (253, 13)
san--p--pd1mysql001b--log-san--p--pd1mysql001b--log (253, 14)
san--p--mysql001b--log-san--p--mysql001b--log (253, 16)
350002ac005d30714 (253, 5)
350002ac005cf0714p1 (253, 8)
350002ac005d20714p1 (253, 6)
san--p--pd1mysql001b--db-san--p--pd1mysql001b--db (253, 12)
san--p--mysql001b--db-san--p--mysql001b--db (253, 15)
350002ac005d30714p1 (253, 11)
[root@dc1-backup01:/var/log-ng]# dmsetup remove 350002ac005d20714p1
device-mapper: remove ioctl failed: Device or resource busy
Command failed
nate
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
