Informix mirroring

We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various reasons, the parituclar machine that this database runs on has had quit a few issues with failing hard drives. Our database use software raid for some HPUX volumes and Informix mirroring for the database. In about half the cases where a drive has failed, we've had to reload the database from tape even if the HPUX volumes recover without reloading from tape backup. On the most recent occasion, the a drive was discovered to be failing and replaced prior to complete failure. Again, the HPUX volumes on the failing drive recovered readily and the operating system came up nicely. Unfortunately, the database was not so lucky, it had to be restored from a tape backup. To replace the drive, we shut the database engine down and then took the machine down completely. An hp technician replaced the failing hard drive and used various vg commands to restore logical volumes and data to the new drive. (note: There was no HPUX mirroring of the Informix database, all chunks were mirrored through the datbase engine.) It was assumed that since none of the chunks were marked as down, the database should come up and restore any missing data from the good drive. As mentioned before, this was not the case. Is there anything that should be done to tell Informix that a drive has been replaced? The only thing I can come up with is that the engine saw a blank drive where it expected data and freaked. Should the questionable chunks be taken offline before replacing a failing drive that has not totally died? Any input is appreciated. Chris Salch

OH I CAN'T RESIST! Informix mirroring OVER RAID5? Do you have a death wish? NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! This is bad on SO many levels. OK, first issue, if you ARE using Informix mirroring, the only one side of the mirror will have been trashed when the array crashed. You should only have to tell IDS to recover the failed mirror from the remaining member by dropping either the primary or the mirror chunk(s) (whichever one failed) and then adding back the replacement mirror segment(s) using onspaces. If you have both sides of the mirror on the same failed array, well that's just foolish and you deserve to lose your data. (Not to be cruel, but ...) Finally, you should not be mirroring over RAID5. RAID5 is inherently UNSAFE AT ANY SPEED, besides being slow, and adding mirroring just adds overhead without much additional safety. The RAID5 underneath is undermining the safety of the mirror. If you want to mirror but also want the additional performance of a stripe, then either mirror at the Informix level from RAID0 (stripe only) arrays (which amounts to a RAID01 array in practice), or better yet, set up an OS or VM level RAID10 array and do away with the Informix mirroring. The RAID10 array will tend to be about 10% faster than Informix mirroring of RAID0 arrays, much faster to recover from a down drive, and less likely to lose all of your data. Your RAID provider is reporting an error back to Informix even though the data is being reconstructed using the (a common RAID5 implementation problem) and that is why IDS perceived the logical partition to be 'down'. I've seen this often with RAID5 and NEVER with RAID1 or RAID10. PLEASE PLEASE read my paper on the subject of "Why should I not use RAID5?" at: http://www.baarf.com/RAID5_versus_RAID10.txt as well as the other postings on the BAARF site (www.baarf.com). Oh, and remeber: NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! Art S. Kagel ----- Original Message ----- From: Chris Salch <ids@iiug.org> At: 5/19 12:12:33 We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various reasons, the parituclar machine that this database runs on has had quit a few issues with failing hard drives. Our database use software raid for some HPUX volumes and Informix mirroring for the database. In about half the cases where a drive has failed, we've had to reload the database from tape even if the HPUX volumes recover without reloading from tape backup. On the most recent occasion, the a drive was discovered to be failing and replaced prior to complete failure. Again, the HPUX volumes on the failing drive recovered readily and the operating system came up nicely. Unfortunately, the database was not so lucky, it had to be restored from a tape backup. To replace the drive, we shut the database engine down and then took the machine down completely. An hp technician replaced the failing hard drive and used various vg commands to restore logical volumes and data to the new drive. (note: There was no HPUX mirroring of the Informix database, all chunks were mirrored through the datbase engine.) It was assumed that since none of the chunks were marked as down, the database should come up and restore any missing data from the good drive. As mentioned before, this was not the case. Is there anything that should be done to tell Informix that a drive has been replaced? The only thing I can come up with is that the engine saw a blank drive where it expected data and freaked. Should the questionable chunks be taken offline before replacing a failing drive that has not totally died? Any input is appreciated. Chris Salch ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi, If Informix sees a blank drive which is expected to be a part of a mirrored chunk, it will probably not know what to do and fails as you described. If this is part of a mirrored group, normally the chunk will be marked as down. If you are using Informix mirroring, then you should place the chunk to replace (or all on the failed disk) into down mode using onspaces, if Informix does not do this alone. You can even replace the drives while the db is working on the mirrored copy if your hardware allows this. Then, put the chunks up again (with onspaces) after the new harddrive is configured exactly like the previous one (partitioning, device links to partitions etc.). Informix will start copying the data to the failed drive while working on the mirrored copy. After a while (depending on the size of the replaced disk and the speed of your hardware) the mirror will be available again with both chunks online. Normally, this is a nice method to make sure a failed disk will not interrupt working on the db. Of course, in recovery mode, you might encounter a performance problem due to I/O activity. I have done this several times in the past and normally there was no interruption of production. And I think this was the same when we had Informix 7.31. I never encountered any change in this behaviour. Marcus -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of CHRIS SALCH Sent: Friday, May 19, 2006 6:09 PM To: ids@iiug.org Subject: Informix mirroring [6769] We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various reasons, the parituclar machine that this database runs on has had quit a few issues with failing hard drives. Our database use software raid for some HPUX volumes and Informix mirroring for the database. In about half the cases where a drive has failed, we've had to reload the database from tape even if the HPUX volumes recover without reloading from tape backup. On the most recent occasion, the a drive was discovered to be failing and replaced prior to complete failure. Again, the HPUX volumes on the failing drive recovered readily and the operating system came up nicely. Unfortunately, the database was not so lucky, it had to be restored from a tape backup. To replace the drive, we shut the database engine down and then took the machine down completely. An hp technician replaced the failing hard drive and used various vg commands to restore logical volumes and data to the new drive. (note: There was no HPUX mirroring of the Informix database, all chunks were mirrored through the datbase engine.) It was assumed that since none of the chunks were marked as down, the database should come up and restore any missing data from the good drive. As mentioned before, this was not the case. Is there anything that should be done to tell Informix that a drive has been replaced? The only thing I can come up with is that the engine saw a blank drive where it expected data and freaked. Should the questionable chunks be taken offline before replacing a failing drive that has not totally died? Any input is appreciated. Chris Salch **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Where did you get RAID5? As far as I'm aware, we are just using straight mirroring (RAID 1 if I have things right) Chris S. ART KAGEL, .... wrote: > OH I CAN'T RESIST! Informix mirroring OVER RAID5? Do you have a death wish? > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > This is bad on SO many levels. > > OK, first issue, if you ARE using Informix mirroring, the only one side of the > mirror will have been trashed when the array crashed. You should only have to > tell IDS to recover the failed mirror from the remaining member by dropping > either the primary or the mirror chunk(s) (whichever one failed) and then > adding > back the replacement mirror segment(s) using onspaces. > > If you have both sides of the mirror on the same failed array, well that's > just > foolish and you deserve to lose your data. (Not to be cruel, but ...) > > Finally, you should not be mirroring over RAID5. RAID5 is inherently UNSAFE AT > ANY SPEED, besides being slow, and adding mirroring just adds overhead without > much additional safety. The RAID5 underneath is undermining the safety of the > mirror. If you want to mirror but also want the additional performance of a > stripe, then either mirror at the Informix level from RAID0 (stripe only) > arrays > (which amounts to a RAID01 array in practice), or better yet, set up an OS or > VM level RAID10 array and do away with the Informix mirroring. The RAID10 > array > will tend to be about 10% faster than Informix mirroring of RAID0 arrays, much > faster to recover from a down drive, and less likely to lose all of your data. > > Your RAID provider is reporting an error back to Informix even though the data > is being reconstructed using the (a common RAID5 implementation problem) and > that is why IDS perceived the logical partition to be 'down'. I've seen this > often with RAID5 and NEVER with RAID1 or RAID10. > > PLEASE PLEASE read my paper on the subject of "Why should I not use RAID5?" > at: > http://www.baarf.com/RAID5_versus_RAID10.txt as well as the other postings on > the BAARF site (www.baarf.com). Oh, and remeber: > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > Art S. Kagel > > ----- Original Message ----- > From: Chris Salch <ids@iiug.org> > At: 5/19 12:12:33 > > We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various > reasons, the parituclar machine that this database runs on has had quit a few > issues with failing hard drives. Our database use software raid for some HPUX > volumes and Informix mirroring for the database. In about half the cases where > a drive has failed, we've had to reload the database from tape even if the > HPUX volumes recover without reloading from tape backup. > > On the most recent occasion, the a drive was discovered to be failing and > replaced prior to complete failure. Again, the HPUX volumes on the failing > drive recovered readily and the operating system came up nicely. > Unfortunately, the database was not so lucky, it had to be restored from a > tape backup. > > To replace the drive, we shut the database engine down and then took the > machine down completely. An hp technician replaced the failing hard drive and > used various vg commands to restore logical volumes and data to the new drive. > (note: There was no HPUX mirroring of the Informix database, all chunks were > mirrored through the datbase engine.) It was assumed that since none of the > chunks were marked as down, the database should come up and restore any > missing data from the good drive. As mentioned before, this was not the case. > > Is there anything that should be done to tell Informix that a drive has been > replaced? The only thing I can come up with is that the engine saw a blank > drive where it expected data and freaked. Should the questionable chunks be > taken offline before replacing a failing drive that has not totally died? Any > input is appreciated. > > Chris Salch > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Thanks this sounds like the solution to our problem. Hopefully, we won't have to test this for a while :) Chris S. Marcus Haarmann wrote: > Hi, > > If Informix sees a blank drive which is expected to be a part of a mirrored > chunk, it will probably not know what to do and fails as you described. If > this is part of a mirrored group, normally the chunk will be marked as down. > > If you are using Informix mirroring, then you should place the chunk to > replace (or all on the failed disk) into down mode using onspaces, if > Informix does not do this alone. You can even replace the drives while the > db is working on the mirrored copy if your hardware allows this. > Then, put the chunks up again (with onspaces) after the new harddrive is > configured exactly like the previous one (partitioning, device links to > partitions etc.). Informix will start copying the data to the failed drive > while working on the mirrored copy. > After a while (depending on the size of the replaced disk and the speed of > your hardware) the mirror will be available again with both chunks online. > Normally, this is a nice method to make sure a failed disk will not > interrupt working on the db. > Of course, in recovery mode, you might encounter a performance problem due > to I/O activity. > I have done this several times in the past and normally there was no > interruption of production. And I think this was the same when we had > Informix 7.31. I never encountered any change in this behaviour. > > Marcus > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of CHRIS > SALCH > Sent: Friday, May 19, 2006 6:09 PM > To: ids@iiug.org > Subject: Informix mirroring [6769] > > We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various > reasons, the parituclar machine that this database runs on has had quit a > few issues with failing hard drives. Our database use software raid for some > HPUX volumes and Informix mirroring for the database. In about half the > cases where a drive has failed, we've had to reload the database from tape > even if the HPUX volumes recover without reloading from tape backup. > > On the most recent occasion, the a drive was discovered to be failing and > replaced prior to complete failure. Again, the HPUX volumes on the failing > drive recovered readily and the operating system came up nicely. > Unfortunately, the database was not so lucky, it had to be restored from a > tape backup. > > To replace the drive, we shut the database engine down and then took the > machine down completely. An hp technician replaced the failing hard drive > and used various vg commands to restore logical volumes and data to the new > drive. > (note: There was no HPUX mirroring of the Informix database, all chunks were > mirrored through the datbase engine.) It was assumed that since none of the > chunks were marked as down, the database should come up and restore any > missing data from the good drive. As mentioned before, this was not the > case. > > Is there anything that should be done to tell Informix that a drive has been > replaced? The only thing I can come up with is that the engine saw a blank > drive where it expected data and freaked. Should the questionable chunks be > taken offline before replacing a failing drive that has not totally died? > Any input is appreciated. > > Chris Salch > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Sorry if I misinterpreted what you were saying, but the section: > replaced prior to complete failure. Again, the HPUX volumes on the failing > drive recovered readily and the operating system came up nicely. > Unfortunately, the database was not so lucky, it had to be restored from a > tape backup. Looked like RAID5 recover to me. If not what were the structures that were recovering? RAID1? Were you using Informix mirrors over an HP mirror? I clearly do not understand. Art ----- Original Message ----- From: Chrissalch <ids@iiug.org> At: 5/19 12:54:38 Where did you get RAID5? As far as I'm aware, we are just using straight mirroring (RAID 1 if I have things right) Chris S. ART KAGEL, .... wrote: > OH I CAN'T RESIST! Informix mirroring OVER RAID5? Do you have a death wish? > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > This is bad on SO many levels. > > OK, first issue, if you ARE using Informix mirroring, the only one side of the > mirror will have been trashed when the array crashed. You should only have to > tell IDS to recover the failed mirror from the remaining member by dropping > either the primary or the mirror chunk(s) (whichever one failed) and then > adding > back the replacement mirror segment(s) using onspaces. > > If you have both sides of the mirror on the same failed array, well that's > just > foolish and you deserve to lose your data. (Not to be cruel, but ...) > > Finally, you should not be mirroring over RAID5. RAID5 is inherently UNSAFE AT > ANY SPEED, besides being slow, and adding mirroring just adds overhead without > much additional safety. The RAID5 underneath is undermining the safety of the > mirror. If you want to mirror but also want the additional performance of a > stripe, then either mirror at the Informix level from RAID0 (stripe only) > arrays > (which amounts to a RAID01 array in practice), or better yet, set up an OS or > VM level RAID10 array and do away with the Informix mirroring. The RAID10 > array > will tend to be about 10% faster than Informix mirroring of RAID0 arrays, much > faster to recover from a down drive, and less likely to lose all of your data. > > Your RAID provider is reporting an error back to Informix even though the data > is being reconstructed using the (a common RAID5 implementation problem) and > that is why IDS perceived the logical partition to be 'down'. I've seen this > often with RAID5 and NEVER with RAID1 or RAID10. > > PLEASE PLEASE read my paper on the subject of "Why should I not use RAID5?" > at: > http://www.baarf.com/RAID5_versus_RAID10.txt as well as the other postings on > the BAARF site (www.baarf.com). Oh, and remeber: > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > Art S. Kagel > > ----- Original Message ----- > From: Chris Salch <ids@iiug.org> > At: 5/19 12:12:33 > > We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various > reasons, the parituclar machine that this database runs on has had quit a few > issues with failing hard drives. Our database use software raid for some HPUX > volumes and Informix mirroring for the database. In about half the cases where > a drive has failed, we've had to reload the database from tape even if the > HPUX volumes recover without reloading from tape backup. > > On the most recent occasion, the a drive was discovered to be failing and > replaced prior to complete failure. Again, the HPUX volumes on the failing > drive recovered readily and the operating system came up nicely. > Unfortunately, the database was not so lucky, it had to be restored from a > tape backup. > > To replace the drive, we shut the database engine down and then took the > machine down completely. An hp technician replaced the failing hard drive and > used various vg commands to restore logical volumes and data to the new drive. > (note: There was no HPUX mirroring of the Informix database, all chunks were > mirrored through the datbase engine.) It was assumed that since none of the > chunks were marked as down, the database should come up and restore any > missing data from the good drive. As mentioned before, this was not the case. > > Is there anything that should be done to tell Informix that a drive has been > replaced? The only thing I can come up with is that the engine saw a blank > drive where it expected data and freaked. Should the questionable chunks be > taken offline before replacing a failing drive that has not totally died? Any > input is appreciated. > > Chris Salch > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

We had the HPUX volumes mirrored with software mirroring by the operating system. The following restored the HP logical volumes. 1. Restore the volume group configuration to the new disk. */usr/sbin/vgcfgrestore -n /dev/vg00 /dev/rdsk/cXtXdX* 2. Activate the volume group. */usr/sbin/vgchange -a /dev/vg00* 3. Synchronize the volume group. */usr/sbin/vgsync /dev/vg00* The database was not mirrored by the operating system at all, just informix mirroring. We don't have any hardware raid in the box, as much as I'd like it. Our restore procedure was inherited from a previous admin and apparently missed a few steps. Chris S. ART KAGEL, .... wrote: > Sorry if I misinterpreted what you were saying, but the section: > > >> replaced prior to complete failure. Again, the HPUX volumes on the failing >> drive recovered readily and the operating system came up nicely. >> Unfortunately, the database was not so lucky, it had to be restored from a >> tape backup. >> > > Looked like RAID5 recover to me. If not what were the structures that were > recovering? RAID1? Were you using Informix mirrors over an HP mirror? I > clearly do not understand. > > Art > > ----- Original Message ----- > From: Chrissalch <ids@iiug.org> > At: 5/19 12:54:38 > > Where did you get RAID5? As far as I'm aware, we are just using > straight mirroring (RAID 1 if I have things right) > > Chris S. > > ART KAGEL, .... wrote: > >> OH I CAN'T RESIST! Informix mirroring OVER RAID5? Do you have a death wish? >> >> NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! >> >> This is bad on SO many levels. >> >> OK, first issue, if you ARE using Informix mirroring, the only one side of >> > the > >> mirror will have been trashed when the array crashed. You should only have >> > to > >> tell IDS to recover the failed mirror from the remaining member by dropping >> either the primary or the mirror chunk(s) (whichever one failed) and then >> adding >> back the replacement mirror segment(s) using onspaces. >> >> If you have both sides of the mirror on the same failed array, well that's >> just >> foolish and you deserve to lose your data. (Not to be cruel, but ...) >> >> Finally, you should not be mirroring over RAID5. RAID5 is inherently UNSAFE >> > AT > >> ANY SPEED, besides being slow, and adding mirroring just adds overhead >> > without > >> much additional safety. The RAID5 underneath is undermining the safety of >> > the > >> mirror. If you want to mirror but also want the additional performance of a >> stripe, then either mirror at the Informix level from RAID0 (stripe only) >> arrays >> (which amounts to a RAID01 array in practice), or better yet, set up an OS >> > or > >> VM level RAID10 array and do away with the Informix mirroring. The RAID10 >> array >> will tend to be about 10% faster than Informix mirroring of RAID0 arrays, >> > much > >> faster to recover from a down drive, and less likely to lose all of your >> > data. > >> Your RAID provider is reporting an error back to Informix even though the >> > data > >> is being reconstructed using the (a common RAID5 implementation problem) and >> that is why IDS perceived the logical partition to be 'down'. I've seen this >> often with RAID5 and NEVER with RAID1 or RAID10. >> >> PLEASE PLEASE read my paper on the subject of "Why should I not use RAID5?" >> at: >> http://www.baarf.com/RAID5_versus_RAID10.txt as well as the other postings >> > on > >> the BAARF site (www.baarf.com). Oh, and remeber: >> >> NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! >> >> Art S. Kagel >> >> ----- Original Message ----- >> From: Chris Salch <ids@iiug.org> >> At: 5/19 12:12:33 >> >> We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various >> reasons, the parituclar machine that this database runs on has had quit a >> > few > >> issues with failing hard drives. Our database use software raid for some >> > HPUX > >> volumes and Informix mirroring for the database. In about half the cases >> > where > >> a drive has failed, we've had to reload the database from tape even if the >> HPUX volumes recover without reloading from tape backup. >> >> On the most recent occasion, the a drive was discovered to be failing and >> replaced prior to complete failure. Again, the HPUX volumes on the failing >> drive recovered readily and the operating system came up nicely. >> Unfortunately, the database was not so lucky, it had to be restored from a >> tape backup. >> >> To replace the drive, we shut the database engine down and then took the >> machine down completely. An hp technician replaced the failing hard drive >> > and > >> used various vg commands to restore logical volumes and data to the new >> > drive. > >> (note: There was no HPUX mirroring of the Informix database, all chunks were >> mirrored through the datbase engine.) It was assumed that since none of the >> chunks were marked as down, the database should come up and restore any >> missing data from the good drive. As mentioned before, this was not the >> > case. > >> Is there anything that should be done to tell Informix that a drive has been >> replaced? The only thing I can come up with is that the engine saw a blank >> drive where it expected data and freaked. Should the questionable chunks be >> taken offline before replacing a failing drive that has not totally died? >> > Any > >> input is appreciated. >> >> Chris Salch >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Ahh, got it. My apologies. Just pretend I was addressing someone else. ;-} The recovery already suggested will get you what you need. Art S. Kagel ----- Original Message ----- From: Chrissalch <ids@iiug.org> At: 5/19 13:17:25 We had the HPUX volumes mirrored with software mirroring by the operating system. The following restored the HP logical volumes. 1. Restore the volume group configuration to the new disk. */usr/sbin/vgcfgrestore -n /dev/vg00 /dev/rdsk/cXtXdX* 2. Activate the volume group. */usr/sbin/vgchange -a /dev/vg00* 3. Synchronize the volume group. */usr/sbin/vgsync /dev/vg00* The database was not mirrored by the operating system at all, just informix mirroring. We don't have any hardware raid in the box, as much as I'd like it. Our restore procedure was inherited from a previous admin and apparently missed a few steps. Chris S. ART KAGEL, .... wrote: > Sorry if I misinterpreted what you were saying, but the section: > > >> replaced prior to complete failure. Again, the HPUX volumes on the failing >> drive recovered readily and the operating system came up nicely. >> Unfortunately, the database was not so lucky, it had to be restored from a >> tape backup. >> > > Looked like RAID5 recover to me. If not what were the structures that were > recovering? RAID1? Were you using Informix mirrors over an HP mirror? I > clearly do not understand. > > Art > > ----- Original Message ----- > From: Chrissalch <ids@iiug.org> > At: 5/19 12:54:38 > > Where did you get RAID5? As far as I'm aware, we are just using > straight mirroring (RAID 1 if I have things right) > > Chris S. > > ART KAGEL, .... wrote: > >> OH I CAN'T RESIST! Informix mirroring OVER RAID5? Do you have a death wish? >> >> NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! >> >> This is bad on SO many levels. >> >> OK, first issue, if you ARE using Informix mirroring, the only one side of >> > the > >> mirror will have been trashed when the array crashed. You should only have >> > to > >> tell IDS to recover the failed mirror from the remaining member by dropping >> either the primary or the mirror chunk(s) (whichever one failed) and then >> adding >> back the replacement mirror segment(s) using onspaces. >> >> If you have both sides of the mirror on the same failed array, well that's >> just >> foolish and you deserve to lose your data. (Not to be cruel, but ...) >> >> Finally, you should not be mirroring over RAID5. RAID5 is inherently UNSAFE >> > AT > >> ANY SPEED, besides being slow, and adding mirroring just adds overhead >> > without > >> much additional safety. The RAID5 underneath is undermining the safety of >> > the > >> mirror. If you want to mirror but also want the additional performance of a >> stripe, then either mirror at the Informix level from RAID0 (stripe only) >> arrays >> (which amounts to a RAID01 array in practice), or better yet, set up an OS >> > or > >> VM level RAID10 array and do away with the Informix mirroring. The RAID10 >> array >> will tend to be about 10% faster than Informix mirroring of RAID0 arrays, >> > much > >> faster to recover from a down drive, and less likely to lose all of your >> > data. > >> Your RAID provider is reporting an error back to Informix even though the >> > data > >> is being reconstructed using the (a common RAID5 implementation problem) and >> that is why IDS perceived the logical partition to be 'down'. I've seen this >> often with RAID5 and NEVER with RAID1 or RAID10. >> >> PLEASE PLEASE read my paper on the subject of "Why should I not use RAID5?" >> at: >> http://www.baarf.com/RAID5_versus_RAID10.txt as well as the other postings >> > on > >> the BAARF site (www.baarf.com). Oh, and remeber: >> >> NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! >> >> Art S. Kagel >> >> ----- Original Message ----- >> From: Chris Salch <ids@iiug.org> >> At: 5/19 12:12:33 >> >> We have an Informix 7.31.UD6 database running on HPUX 11.11i. For various >> reasons, the parituclar machine that this database runs on has had quit a >> > few > >> issues with failing hard drives. Our database use software raid for some >> > HPUX > >> volumes and Informix mirroring for the database. In about half the cases >> > where > >> a drive has failed, we've had to reload the database from tape even if the >> HPUX volumes recover without reloading from tape backup. >> >> On the most recent occasion, the a drive was discovered to be failing and >> replaced prior to complete failure. Again, the HPUX volumes on the failing >> drive recovered readily and the operating system came up nicely. >> Unfortunately, the database was not so lucky, it had to be restored from a >> tape backup. >> >> To replace the drive, we shut the database engine down and then took the >> machine down completely. An hp technician replaced the failing hard drive >> > and > >> used various vg commands to restore logical volumes and data to the new >> > drive. > >> (note: There was no HPUX mirroring of the Informix database, all chunks were >> mirrored through the datbase engine.) It was assumed that since none of the >> chunks were marked as down, the database should come up and restore any >> missing data from the good drive. As mentioned before, this was not the >> > case. > >> Is there anything that should be done to tell Informix that a drive has been >> replaced? The only thing I can come up with is that the engine saw a blank >> drive where it expected data and freaked. Should the questionable chunks be >> taken offline before replacing a failing drive that has not totally died? >> > Any > >> input is appreciated. >> >> Chris Salch >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.