Server :: MySQL 5.0.32-Debian_7etch8 "forgets" Permissions Repeatedly

I'm a PostgreSQL administrator. We have a few sites (maybe 30? 40?) that use MySQL as a backend, but nothing like the thousands of sites that run PostgreSQL. As you can imagine, my knowledge of PostgreSQL has grown much faster than my knowledge of MySQL. The problem, then, is very likely to be PEBKAC. This past weekend we had an upstream transformer incident that managed to take out an enterprise APC, causing this particular server to reboot. The server environment is a bit wanky (I didn't set it up this way), with both PostgreSQL and MySQL running together on a Debian "Etch" box, with PostgreSQL taking up the lion's share of resources (it has 200+ databases vs. MySQL's 10 or so). Both PostgreSQL and MySQL came up after the reboot, but now MySQL is acting "funny".

Initially after the reboot, sites were getting "Could not connect to MySQL." I went in and looked at the user and db tables and fixed the permissions, ran flush permissions, and all sites came up. Happy DBA. Over the remaining weekend and this morning, we're seeing a repeated issue where sites get "Could not connect to MySQL", and it affects sites independently of each other (site "A" is fine, site "B" gets "could not connect to mysql"). I checked the max_connections and max_user_connections and noticed that they were a bit lower than I'd like, so I bumped them up (now set to: 1000 max_connections, 800 max_user_connections) and ran flush permissions again. All is well once more.

Then it happened again. Granted, it's not nearly as frequent as it was Saturday, but it still occurs. This is becoming problematic (and, as you can imagine, quite a headache). I'm the only DBA in my company, so *ANY* ticket that has the word "database" in it, regardless if it's PostgreSQL/MySQL/MSSQL/DB2/Oracle/etc... find their way to me...and this one has me a bit stumped. Every time it occurs, I can run "flush permissions" and everything works again. I've considered the short-term fix of creating a cronjob, but that's quite a hack and I'd rather just fix the cause rather than treat the symptom.

Edit - a bit more background on this particular server: I had it running PostgreSQL 8.3.5, then went on vacation. When I returned, it was running PostgreSQL 8.4beta1 (it's a production box! /me cries) and now PostgreSQL has all kinds of library version mismatch issues and what-not. I scolded the IT tech who gave dev root on this box, revoked all dev permissions, and I've been busy building a replacement machine to move all of the PostgreSQL databases to, but due to some purchasing delays the replacement box isn't ready yet. It's entirely possible that MySQL has similar issues, though I've not witnessed anything of the sort (yet).