More theoretical Database Stuff

[Chuck Williams]

I haven't kept up with hardware for years. So my only comment may be
dated. My employer successfully uses
tape for backups but in my previous employments I thought tape was a big
headache.

Just curious since I read a book or two this summer: Why PostgreSQL
rather than MySQL?

Chuck Williams


original message:

Folks:
    I'd like to get your opinions/experiences/references on
something.

   Let's say we're developing a 24/7 multi-user (avg: 5 at
a time, all the time) database for a warehousing project for
a multi-site food company. (GFS, Spartan, whatever.)

  Here's what we're thinking:

- Server:  Linux or Solaris-Running x86's, two of them, each
with dual processors and RAID 5.  Not true clustering, the
2nd one just "mirrors" the first and routinely backs up
transactions to tape.  This costs no downtime.  In the event
of server 1 failure, we switch over to server two, swap some
hard drives around, restore, and re-run.  Operational downtime
of about 3 minutes in the event of  a failure, with general uptime
of, say, 99.9% or so.

  We'd pay the extra $ for the hardware that scales and doesn't
fail, and a tape backup that can run while the database is running.
(Question: Can PostGreSQL and Lunix handle this?  I think we might
need solaris for it's transactioning file system.)

  My thought was that we didn't need the extra "guarentees"
(system mirroring) if we had tape backup and raid 5,
but my partner is a team leader at Meijer and insists that 1 hour
of downtime will most more than just buying an extra system and
mirroring it.  Which begs the questions:

1) Can we do tape backup in Linux in real-time with PostGreSQL and
2) What do you think of the scheme above?

regards,


Matt H.