[Tfug] raid help

[Ronald Sutherland]

I got a lot of reading to do on HA but I think the idea is not to transfer
the computer core memory system of one to the other, but the data that makes
it into a journaled hard drive, which has gone though memory parity test and
should be good (I think anyway). This is the data I would want transfered
over in a timely fashion. That works (I hope) with an an SQL server, because
they make sure data is on disk (meaning the journal is updated) before
marking the transaction as complete. So when the other computer launched and
found SQL data not marked as complete, it is rolled back. Anyway I think the
idea is to let the computer die as fast as possible when a memory compromise
is detected and then have a plan to recover with what is most likely good
data.

If bad data gets to the hard drive then never mind, I vote back-up, but I
still do not see a good reason for mirroring the swap files (other than
speed). Virtual memory is an extension of main memory, and anything going
wrong in main memory is grounds for stopping, this is indefinitely true. If
I assign importance to memory I place my own bits as most valuable, system
and service bits next, then main memory. I care least if main memory is
lost. I care more if system or service bits are lost, and I will have a shit
fit if my stuff is lost. So I try to separate these things physically, I
have at least 3 drives, 2 mirrored for my stuff, and one for system and
swap. If the system and swap die I don't actually care very much, and can
recreate it in about 1.5hr. The less the swap system is hammering on the
stuff I care about, the better I feel (does that make sense?).

On Sun, Mar 30, 2008 at 3:31 PM, Brian Murphy
<murphy+tfug at email.arizona.edu<murphy%2Btfug at email.arizona.edu>>
wrote:

> Jumbled RAM is a game over situation.  Especially if the system writes a
> portion of the jumble out to your disk.  Mirroring just ensures that
> both drives get the jumbled data. :)
>
> Backups are a good idea and about your only recovery option if you write
> garbage data over the good stuff.
>
> HA is good, but you typically have shared disk between the 2 servers.
> If server 1 writes bad data, server 2 will be equally hosed if they
> share disks.  The same is true if you have subtle file corruption and a
> periodic sync between your two servers. (e.g. rsync from cron)  Keep
> tape backups for anything you really don't want to lose.  Snapshots can
> also be part of a good recovery strategy as long as you don't have
> controller issues that scramble your entire disk.
>
> Brian
>
>
> Quoting Ronald Sutherland <ronald.sutherland at gmail.com>:
> > Last time I was trying to figure out what all I should mirror I was
> having
> > over heating issues (it was jumbling my RAM). I've also seen power line
> > sags/spikes/noise, and power supply's go bad and jumble RAM. So for my
> needs
> > I've decided that first I want data (SQL, FileServer, SVN/CVS...)
> mirrored
> > and second my system to be fully duplicated and/or real easy to build
> again
> > (a setup that is scripted). Having seen memory get messed up for various
> > reasons, I didn't see much advantage in adding redundancy to the virtual
> > part of the memory system, although I guess mirroring gives a speed
> > advantage during reading. I have the hardware but not yet the time to
> setup
> > full redundancy. Many of the Linux rags have ran articles on a service
> > called "heartbeat" that allows the backup to have a clue if the
> main/master
> > is alive and then take over if not, anyway thats what I'm looking into.
> >
> > http://www.linux-ha.org/Heartbeat
> >
> > On S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20080330/5ee1f647/attachment-0002.html>