Can more queries equal a healthier MySQL server?

This week was an ugly one for my monster database servers. It should have been triumphant, but oddly enough, I think it shows how prone to mistuning InnoDB on MySQL 5.0 is with multiple cores.

This server is a multi-core, high concurrency server. The application has been designed a little bit naively in that it just throws almost all queries at the main db server. Several bits have been designed to scale by not doing that, but unfortunately, huge amounts of functionality were built around those apps to prevent them from scaling.

As a result, we’ve had to scale up the central database server and its redundant systems significantly. We started with the Proliant DL380 G4 with two Xeon 3.4Ghz CPU’s and 12GB of RAM, and plenty of disks in an external RAID. As more traffic was added, we moved up to the DL580 servers with 4 Xeon 3.4Ghz and 64GB of RAM. This worked well, but still more traffic, and more data, was coming and the app wasn’t ready to change significantly. We finally landed on the latest DL580 server, with 1GB of total battery backed write cache, 14 SAS disks, 128GB of RAM, and two quad core Xeon CPU’s.
Continue reading

The new fad: Outsourced Parachute Packing

Holy cow, did you read about this company “The Linkup” losing 45% of its customers’ data?! How about they change their name to “The @$%! Up”.

First off, let me say that these guys didn’t have to be retarded to lose this much data. In fact, there are (were?) probably a lot of really talented people who designed and built this system to avoid such things.

I’m an optimist, so I have to believe somebody raised their voice at a meeting when data was shipped off to some loosely linked company from some past relationship. The finger pointing going on now is exactly what nobody ever wants to see happen to something they built.

Nirvanix says it has not deleted any customer data, and promises that its Storage Delivery Network is immune to the problem that plagued The Linkup. Continue reading