Let me ask the following (Chris):

Is it wise to partition things such that /data and /binlogs are on two
different partitions?  That way, the binary log(s) can't fill up the /data
drive.  If so, is there a guideline for how much space to save for binary
logs?  Or do you just keep both the DBs and binlogs and data together?

TIA,
Tim

> -----Original Message-----
> From: Tim Lucia [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 12, 2006 5:41 PM
> To: 'Chris White'; mysql@lists.mysql.com
> Subject: RE: I don't understand why SCSI is preferred.
> 
> 
> > -----Original Message-----
> > From: Chris White [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 12, 2006 5:15 PM
> > To: mysql@lists.mysql.com
> > Subject: Re: I don't understand why SCSI is preferred.
> >
> > On Wednesday 12 July 2006 01:13 pm, Tim Lucia wrote:
> > > I've seen whitepapers from MySQL's web site, co-authored with Dell,
> that
> > > recommend the hardware optimization be:
> > >
> > > 1. More Memory
> >
> > That's a definite
> >
> > > 2. Faster Drives (15K RPM is better the 10K)
> >
> > Well, I guess for any server really, the faster the disk writes (Though
> > let's
> > be honest, the faster the disk writes AND the better integrity disk).
> > Generally this is, in my opinion more suitable for things like logging,
> or
> > the times MySQL actually decides to write to the disk (here's where a
> > MySQL
> > person steps in and states when that is ;) ).
> >
> > > 3. Faster CPU.
> >
> > As with most things these days.  Better CPU means less worry about "Oh,
> I
> > wonder if I can do this" and increases the time period between now and
> > when
> > you need to scale.
> >
> > > Based on this, we're spec'ing 2950s with 16Gb, dual 2.8 dual-core
> Xeons,
> > > and 146Gb 15K (times 6) drives.
> >
> > Sounds about right.  If you're on a linux system I also recommend that
> you
> > turn on NPTL (Native Posix Threading Library), which is done through
> glibc
> > (or by grabbing an rpm/deb/whatever with said support).  As always,
> don't
> > forget the SMP support in the kernel to benifit from the Dual-Core (I'm
> > guessing you probably know this, but hey.. never hurts).
> >
> > > The plan is to RAID then 2 x RAID1 for the o/s (/boot, /,
> >
> > sounds good
> >
> > > /var, and some
> >
> > It's actually best to shove this on a separate disk.  As the name
> > implies, /var is for variable data.  That said, you'll be chucking
> > everything
> > and the kitchen sink at it.  Logs, spools, etc.  These suckers are
> > constantly
> > being written to, and let's forgot the fact that some people attack
> > servers
> > by shoving data at it, which goes to logs.. which take up space.. you
> get
> > the
> > idea.
> 
> 
> /var would be on a separate partition, on the same physical RAID set --
> sorry that was obvious to *me* but I didn't say that.
> 
> 
> >
> > > working space for dumps and restores), and 4 x RAID10 for /data.
> Anyone
> > > have any feedback on this?
> >
> > Some people use replication servers for backups, others use the same
> > drive.  I
> > like the idea of a separate backup replication server as if the main one
> > goes
> > down, I've got a real physically separated backup to work with.  In the
> > end
> > that's what matters.
> 
> The plan is to backup the slave.  I just want to reserve some space if I
> need to have a local dump file or something.
> 
> >
> > --
> > Chris White
> > PHP Programmer/DBloomingOnions
> > Interfuel
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]
> 
> 
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to