Peacebringers

Just a quick note that I think any passers-by might find of interest: tuning-primer.sh. It a spiffy script that I use both at home and at work for a quick evaluation of basic performance tweaks that could be made to a MySQL server. It in no way replaces a DB Administrator… *knowing* MySQL and how to tune it is much preferred. However, in some case you may have a knowledgeable non-DBA working on your server and they may need help tweaking MySQL.

However, in the latest version of this shell script, I noticed a new alert pop up. It was alerting me that I had not enabled sync-binlog in my config file. I hadn’t set it since my personal server is a hobby system, it’s not running in a RAID array, and is not running on high end equipment… quite the opposite. But I figured what the hell, I’ll enable it anyway. I figured I’d see if it would harm my system by enabling it on such a craptastic machine, and came across an interesting article about enabling sync-binlog on CentOS systems running on a RAID array. This perked me up right away… it’s what my team uses at my job.

Since sync-binlog is a performance tuning suggestion for systems doing replication and running RAID, this fits quite a few of my customers machines. The blog post I came across is entitled Beware: ext3 and sync-binlog do not play well together, and mentions how there’s an issue with the Linux Ext3 file system in a RAID situation and enabling sync-binlog. Most notably, you should not have hard drive caching on, or it could be detrimental and cause data loss during a crash. I’d suggest reading the article, as well as the user comments.

In the end, I’m thankful… RAID or not, I have always had the practice of separating my MySQL data onto its own disk partition and formatting it ReiserFS or XFS. Currently I run XFS on mine, so I am safe for the moment, at least as safe as I can be running on a single old IDE drive. I do make backups! What kind of an admin would I be without those?

Peace.