jrmuir

To help fix this, if you have binlog enabled on your mysql server(s) you can pretty quickly find your bad cron tables:

mysqlbinlog --verbose --base64-output=DECODE-ROWS mysql-bin.000001 | less

Just search through for ngg_delete. Once you find one, scroll up to get the database/tablename. To get to the next, search for UPDATE once, then again for ngg_delete (hint, / in less is the search, so /ngg_delete<enter> to search for ngg_delete).

Good for monitoring that you actually caught them all as well.

And thanks to SH101 for the script, that seems to be doing the trick. I was going down a similar route but hadn’t gotten there yet.

It’s pretty impressive when you can load up 1180+ cron entries for the same thing in a site. Add that across multiple sites running on the same db server(s) in a replication setup, and you can take 3-4 G of db content and turn that into 50+ G of binlog data in under 5 minutes, break replication, and corrupt databases.

This was a really, really bad update Cais.

Further update, went back to my last db backup (with the wp_1_ tables renamed to fix the missing tables issue) and realized somehow the admin user’s super admin privileges (site_admins entry in sitemeta) was removed. Doh! After a little security feature math I added it back in manually and things looked a lot better now.

Thanks for the response, and if anyone else comes across something similar and it isn’t plugins, doublecheck that the admin user has an entry in the wp_sitemeta (or tableprefix_sitemeta) for site_admins. Should look a little something like this, assuming the admin name is “admin”:
a:2:{i:0;s:5:”admin”}

John