05.23.07
Bigger, Badder, more Power!
One of my clients grows seemingly without bound. In the space of about 16 months, their Redhat Clustered MySQL database went from 2CPU/4GIG servers to 4CPU/8GIG servers to 8CPU/8GIG servers. We just put the dual quad-core Intel bad boys in last night. It pretty much went according to plan and the new cluster is humming along.
Also in that time frame, MySQL binary logging went from a few gigs a day to over 60 gigs a day (for those who don’t know, a binary log is a record of any change to the data in the database.) That’s a hell of a lot of inserts/updates/deletes. And that’s aggregated data, too!
I’m displeased with the current state of MySQL performance management tools available. Extracting the number of selects vs inserts vs updates vs deletes, something I assumed would be very basic and straight forward, doesn’t exist (that I’ve seen.) I figure I’ll have to break out some Perl/PHP and come up with some kind of trending/management tool. Oh joy.
I’ve also started a “smart” binary log purging script. When you use MySQL replication, you want to purge binary logs up to the log being used by the “slowest” replication slave. If you delete a binary log that’s being read by a slave (or is one of the next in line to be read) then replication will break and you have to either restore the binary log to manually update the slave or rebuild replication using a backup of the master.
