Solaris

Happy New Year to all.

I am working on Solaris 10 testing as we are moving from Solaris 8. When I JumpStart Solaris 10, SW mirroring (RAID1) is enabled by default and metastat -p shows:

d10 -m d11 d12 1
d11 1 1 c1t0d0s0
d12 1 1 c1t1d0s0
d20 -m d21 d22 1
d21 1 1 c1t0d0s1
d22 1 1 c1t1d0s1
d30 -m d31 d32 1
d31 1 1 c1t0d0s7
d32 1 1 c1t1d0s7

One of the objective is to come up with a procedure to un-mirror the disks before an upgrade or patching activity and then re-mirror if successful, or start with the other disk if unsuccessful to get back to the state before the upgrade. I did some research and found this procedure on Sun BigAdmin (Automating Unmirror and Remirror for Solaris Volume Manager Volumes) (BigAdmin Submitted Tech Tip: Automating Unmirror and Remirror for Solaris Volume Manager Volumes). I could successfully un-mirror and re-mirror very quick but did not do a more detailed testing yet.

Has anybody tried this? I have few concerns/questions and wondering if you can help:

- We normally have customized applications and database running on the server, is applying this procedure safe to them (especially the database)? In other words, the database is constantly updated, if you run the un-mirror script it will detach one of the disks and hence one disk will be updated with the changes before a reboot is attempted before the un-mirror is complete.
- When the un-mirror is complete and the system is rebooted, which disk the server is using?
- If upgrade or patching activity fails and you decide to revert back and start from the other disk, how to do that?
- Finally, does anyone recommend a better way or method?

We follow following steps , I am sure there must be better way to do the same thing and my steps can be also verified/purified by Gurus


Detach the metadevices for root file system. if you have swap, var and opt mounted on different volumes then detach them also.

Mount the secondary disk on some mount point and modify the <mountpoint>/etc/vfstab and change the root file system to mount from slices instead of volumes. Some thing like below



Shutdown the system and boot from the rootmirror like below


once system is booted check the ‘/', var, opt fliesystem are clean some thing like below



ufsdump the original( primary) root, opt, and var filesystems to some other system. May be you can use other server and dump

Once you have successfully dumped the again shutdown the system and reboot the system from primary disk i.e.



do the installation/ patching once you are over with that reboot the system i.e. reboot

if no problem has been reported, re-attached the secondary disk.

Thanks for the response. We use to use a similar method with the exception that "system" and "vfstab" changes are done after the system is booted from CD in single user mode to make sure no application is running and database changes are happening.

I cam across Sun procedure provided in 816-4520 (Solaris Volume Manager Administration Guide). I will try that and post my observation. In the mean time, if anyone has comment, it will be great. Thanks!

Personally I prefer the manual way.

1. I will unmount filesystems that can be unmounted.

2. I will detach submirrors, and clear mirrors.

3. I will edit vfstab, and use the command "metaroot cXtXdXsX" that will edit /etc/system for me.

4. I will try to boot the system with only raw disks, and confirm that I have to exact copies of the data, then I will go ahead.



By the way there's another way recommended if you have enough space. You can dedicate one slice (slice 3 for example), and ufsdump your root file system there. Then upgrade and see how it goes.


Good luck

.. why not use ZFS instead of SVM?

Simply just use metadetach to detach the submirrors and do your patching etc etc. Its suffcient enough to safeguard the system and for recovery

metadetch <mirror> <submirror>

Thanks for everybody's response. It seems that we are all doing something around the official procedure in document Solaris Volume Manager Administration Guide (http://dlc.sun.com/pdf/816-4520/816-4520.pdf), section: Removing RAID-1 Volumes (Unmirroring).

Just to let you know, I have tested the script mentioned in my initial post and worked well, and have not experienced issues so far.

I have a question though, when mirroring is broken and you reboot the system, which disk the system is going to boot from (e.g. disk 0 or disk 1)? Is there a way find out after the system is started (i.e. from OS)? The reason I am asking is if the activity (e.g. patching) fails and you want to boot from the other disk and then make sure that syncing is running properly when re-mirror.