Re: Moving a chunk - a related question

Hi, I'd like to ask a question about this method (at the risk of appearing dim) - but in relation to having a broken disk affecting a primary chunk of a mirrored pair. In a search of the archives I've seen this method given as a solution to having a primary chunk down due to disk failure (which is my problem) - the process being: 1. shutdown 2. swap the links, ie. link the primary to the mirror device and the mirror to the primary device 3. restart 4. drop and recreate the mirror. But when I tested this (on a healthy system) - I marked a primary chunk as down , shutdown. Swapped links, restarted - and the primary chunk is still marked as down, the mirror as online. But now, I can't drop the mirror until the primary is online. So I can run onspaces to bring the primary online. But it verifies the chunk by copying from the mirror (so I gather from onstat -D ) ..... but the mirror is now the disk which is broken, so although this works on my healthy system, it presumably won't work on the real problem ... ? (I did also try linking the primary to the mirror and the mirror to a replacement unused device - that just gave me assert-failed errors as I expected and ended up with both chunks down) Am I missing something ? Or do I actually have to do the dd thing. (I was hoping not because of the downtime) [ IDS Version 9.21.UC1, running on SunOS 5.7 ] Thanks a lot, Rosemary "Superboer" <superboer7@t-online.de> wrote in message news:ca752198-08fd-428d-9f05-496c21cb396c@d50g2000hsf.googlegroups.com... > If not too many chunks and MIRROR is enabled... > > enable mirroring for the dbspace. > > bring down the chunk you want to move using onspaces. > relink the chunk you want to move to the new device. > bring online the chunk using onspaces. > then remove mirror using onspaces.... > (hopefully you run on a 'recenter version of 7.3'... a bug may prevent > the above... > so test it first on a test box...) > > This can be done without shutting the engine.... > > Superboer. > > way fast=http://www.clipjes.nl/clip/nederlands/n/normaal_- > _oerend_hard.html

On Nov 28, 8:28 am, "Rosie Rhodes" <rosem...@spider-networks.net> wrote: > Hi, > I'd like to ask a question about this method (at the risk of appearing > dim) - but in relation to having a broken disk affecting a primary chunk of > a mirrored pair. You're working too hard. If a primary chunk fails and you have an existing IDS mirror chunk for that chunk, then you simply relink the damaged link to the replacement chunk and use onspaces to mark the chunk back online. IDS will copy from the good mirror to the replacement drive marking it inconsistent instead of down until the copy completes. Once THAT sync operation completes, IFF you want the original mirror to be the primary and the new disk the mirror you would shutdown and swap the links then restart. Art S. Kagel > In a search of the archives I've seen this method given as a solution to > having a primary chunk down due to disk failure (which is my problem) - the > process being: > > 1. shutdown > 2. swap the links, ie. link the primary to the mirror device and the mirror > to the primary device > 3. restart > 4. drop and recreate the mirror. > > But when I tested this (on a healthy system) - > I marked a primary chunk as down , shutdown. > Swapped links, restarted - and the primary chunk is still marked as down, > the mirror as online. > But now, I can't drop the mirror until the primary is online. > So I can run onspaces to bring the primary online. But it verifies the chunk > by copying from the mirror (so I gather from onstat -D ) ..... but the > mirror is now the disk which is broken, so although this works on my healthy > system, it presumably won't work on the real problem ... ? > (I did also try linking the primary to the mirror and the mirror to a > replacement unused device - that just gave me assert-failed errors as I > expected and ended up with both chunks down) > > Am I missing something ? > Or do I actually have to do the dd thing. (I was hoping not because of the > downtime)