Multiple hard drive arrangement testing
I am thinking about testing two layouts of hard drives in a db server. I have this small “disagreement” with members of the sys-admin team about which is best: using a striped RAID arrangement to spread reads over multiple drives or what I was always taught — separating your data among various drives. For example I would typically do something like this: 1 drive for OS, 1 drive for data, 1 drive for log files. This spreads the reads and writes somewhat.
Before I go and start testing all this…can someone point me to a test of MySQL on these arrangements?
Thanks!!
5 Comments so far
Leave a reply
Wouldnt it be easier to simply do the math on the maximum number of iops on each disk and figure out your answers from that? If you can have N disks serving N iops to return some data, versus one disk doing the same work, which will be faster? That is assuming you dont need to have dedicated disks for some part of your OS (say, lots of logging on /var.)
I have always felt that most modern RAID controllers with decent caching will beat out anything we do by hand.
Take care,
-Peter
Depends a lot on what you’re aiming for: the striped RAID will probably give you sheer read speed for random accesses (where the majority of the search happens in indexes), simply because the data should average out across the drives, allowing (effectively) multiple operations to occur at the same time.
With your proposed layout, the data drive would be used almost constantly (assuming a constant load level - probably also much more reading than writing, although that would depend on the application), the log drive fairly regularly (probably more writing than reading), and the OS drive infrequently (on booting, on daemon restart, and whenever a specialist tool is required).
Note that this isn’t benchmarked, just my experiences of how different drives tend to get used when divided up on different systems with similar load patterns.
Thanks everyone. While it might not be true in every situation, I think by and large some type of striped RAID will be best. I think I had this weird hold-over from the 90’s with the idea of separating things out into single drives. Maybe its all the Coke I drink.
It might be modestly better to do some type of hybrid setup where you boot off a single drive (possibly mirrored for reliability) drive and then use RAID for data and logging.
Ideally you might want to have separate RAID pools for data and logging to separate out I/O a little. Not sure that you can do that without spending a great deal of money, and it would definitely add to the complexity of the setup so your sys admins (if you have them) would not be happy.
Anyways, I have decided against doing the testing as it doesn’t seem to be worth the time to prove what others already know. Thanks again for the input!!
Your hybrid theory is how I usually break down a master in a replication environment. Typically: dedicated disk(s) for OS, RAID for data partition, and dedicated disk for binlogs. If you have sufficiently many disks in your raid array allocating a separate set of disks for binlogs might be a waste of money.
A lot depends on the RAID you have.
If you have BBU you can typically well have give most of your drives to RAID10 which makes it easier than trying to balance logs/Binlogs/Data
Really even placing OS on the same RAID volume could be good idea - OS drives typically almost idle in the operation
but it is often nice to have OS and data in different locations to make it easier to manage.
Using OS drives for binlogs can be good idea as even if something messes up and your data RAID volume is killed you can do point in time recovery from binlogs.