Grab a used PC, install Linux on it and play around with MySQL and PHP. It's a cheap and easy way to learn the basics and you can adapt to whatever technologies are in use when you get hired in a development shop.
Try utilizing all of your hardware instead of having some sitting around doing nothing but waiting for the primary node to break. Especially if you don't have money to waste.
On our big UNIX boxes, they are all SAN attached and the application binaries as well as the data are located on these drives. Use some clustering software so that each server can see all of the drives. This will allow you to have each server with a primary responsibility and can handle a secondary when another primary server dies. Server A dies? Server B can see it's drives and you can start the application - most of the time scriptable with the failover server monitoring the primary. This eliminates dead (and expensive) weight in the datacenter.
We tend to find load balancing not as attractive, as you have to keep all the member nodes exactly the same when you install patches and/or make changes to the application. With commodity x86 servers running 3-4GHz and 2Gbps Fibre Channel for storage, things tend to run plenty fast. If your application requires more than that, you need to be running on a "big iron" 16 or 32-processor system with an unGodly amount of memory.
Slashdot Mirror
Grab a used PC, install Linux on it and play around with MySQL and PHP. It's a cheap and easy way to learn the basics and you can adapt to whatever technologies are in use when you get hired in a development shop.
Try utilizing all of your hardware instead of having some sitting around doing nothing but waiting for the primary node to break. Especially if you don't have money to waste. On our big UNIX boxes, they are all SAN attached and the application binaries as well as the data are located on these drives. Use some clustering software so that each server can see all of the drives. This will allow you to have each server with a primary responsibility and can handle a secondary when another primary server dies. Server A dies? Server B can see it's drives and you can start the application - most of the time scriptable with the failover server monitoring the primary. This eliminates dead (and expensive) weight in the datacenter. We tend to find load balancing not as attractive, as you have to keep all the member nodes exactly the same when you install patches and/or make changes to the application. With commodity x86 servers running 3-4GHz and 2Gbps Fibre Channel for storage, things tend to run plenty fast. If your application requires more than that, you need to be running on a "big iron" 16 or 32-processor system with an unGodly amount of memory.