When you think you are being smart by only giving your backup user SELECT privileges, don’t forget that you also need to be able to LOCK TABLES to use some of the mysqldump features.
That is all.
From the InnoDB backup section of the MySQL manual.
In addition to making binary backups as just described, you should also regularly make dumps of your tables with mysqldump. The reason for this is that a binary file might be corrupted without you noticing it. Dumped tables are stored into text files that are human-readable, so spotting table corruption becomes easier.
Ummmm, yeah…about that whole reading multi-megabyte text files to look for corrupted data…not gonna happen.
Do:
Don’t
So, one an older instance of mysql (3.23.58 to be exact) we recently came across a very odd permission problem which I haven’t encountered before. Basically I created a database and then granted all privileges on the database and any of it’s tables to a user on the localhost identified by a password.
All afternoon I was getting ERROR 1045: Access denied and it was really starting to annoy me. Of course, I just reset the password on the user and it works now. Not cool. Not cool at all. Maybe the database was just running too hot and needed time to cool off. Maybe it was the Flying Elves™.
You would think I would be able to find those incredibly simple steps somewhere other than the spec file for RedHat Enterprise Linux php.
I’m just sayin’…
PS — up2date will dump the src.rpm is /var/spool/up2date
PPS — You would think I would be smart enough to remember to specify `—target=i686`. You would, of course, be wrong.
