Dave Rix's questions

I'm working with an existing web application developed in Ruby with a MySQL back-end, but I think the generic hardware topology question will apply to a wide variety of server architectures.

I'm looking for a document / web resource explaining and detailing current best practice relating to organising the hardware within a server farm for delivering a web based application with a database back-end.

The current architecture is as follows;

                    HTTP Server (Apache)
                           |
               Application Servers x 8 (Unicorn / Ruby-on-Rails)
                           |
                     MySQL Back-end (Master)
                            \
                             \
                          MySQL Slave (primarily for performing backups)

The proposed architecture needs to be more scalable than the above, including a load balancer in front of multiple HTTP servers, splitting the app servers between the HTTP server(s), multiple MySQL slaves to server read only requests (which will be controlled by changes within the application software)

The main aim is to have a more resilient system, using current best practice, and this is what has been suggested so far.

But, if anyone can suggest a resource for best practice within this type of environment, or propose an architecture which will give the resiliency, performance and scalability that we are after, I'd be most grateful :)

Dave

We currently have a DELL 2950 with 4 x 400Gb 10krpm SAS drives in RAID 5, and one of those drives has failed. Not having any identical spares (don't slap me, it's not my fault), and not being able to source any identical replacements, we have decided to upgrade the drives to the latest 'standard' sizes and speeds.

Essentially, we are going to purchase 7 x 450Gb 15krpm drives (so that we have a spare), and slowly replace all the existing drives with the new ones.

This is what we have already found out from DELL;

• Replacing a 400Gb with a 450Gb is ok, but only 400Gb will be used
• We can add a disk to the array one at a time, and the controller will expand the array
• Mixing the spindle speeds is ok, they will essentially get averages out

What we do not know is what happens when ALL the drives have been replaced, and are now 450Gb drives, does the RAID controller automatically grow the array to use all 450Gb on each of the disks or will we end up with 50Gb wasted space on each drive?

And if we get 50Gb of wasted space on each drive, will the controller allow us to then create a new RAID 5 array using these 6 x 50Gb spaces and then use that within our OS.

If we can't use the 50Gb, then we don't really care (it's only £100 worth of storage!) but it would be nice to know so that we don't assume that we can use it!

I have a number of large databases, 350Gb+ each with over 100 tables in each. They are mainly MyISAM tables, with a few InnoDB tables thrown in for good measure.

Platform :- Linux, MySQL 5.1, MyISAM + InnoDB tables (with file_per_table option turned on)

I need to duplicate these database on the master and have the duplication correctly reflected on the slave server, and am running into some issues.

Doing a mysqldump and then a restore is successful, but extremely slow, and takes a long time for the slave to catch up.

Doing a straight disk copy of the data files does not seem to work as the information_schema does not accurately reflect the copied database - in some instances the tables don't even seem to exist in the target database, even though myisamchk is able to check and repair the indexes successfully.

Is there a way of performing the disk copy of the data files and having the information_schema accurately reflect the copied database, or am I just going to have to lump it and persevere with the dump/restore option? And if I can duplicate the databases in this way, can I perform the same steps on the slave without breaking the replication status?

Thanks in advance, Dave