在运行mysql的盒子升级之后，备份脚本正在为Innodb表的数据库返回一个错误。
一个运行Debian 5（Lenny）的系统已经升级到了Debian 6（Squeeze），系统从Debian仓库运行股票mysql-server软件包。
备份是通过备份多个mysql服务器的脚本来执行的，并分别备份每个单独的数据库。
这是在对Innodb表数据库运行时返回的命令和错误。
$ mysqldump --defaults-extra-file=creds.cnf --lock-tables --flush-logs --force db_innodb > /dev/null mysqldump: Got error: 1045: Access denied for user 'backup'@'%' (using password: YES) when using LOCK TABLE echo $? 2 在同一台服务器上使用相同的帐户对同一个Myisam表的数据库运行相同的命令时，没有错误。
$mysqldump --defaults-extra-file=creds.cnf --lock-tables --flush-logs --force db_myisam > /dev/null echo $? 0
常规备份帐户具有locking表权限，以及在系统升级之前正常运行的备份。 但我也尝试了与根帐户，并看到相同的错误。
mysql> show grants for 'backup'@'%'; GRANT SELECT, RELOAD, LOCK TABLES, SHOW VIEW ON *.* TO 'backup'@'%' IDENTIFIED BY PASSWORD '*...'
我知道我可以简单地不使用Innodb数据库上的锁表选项，而是使用--single-transaction选项，但是这样做效果不好。 几个数据库有使用Myisam和Innodb存储引擎的表，单个事务选项不会使Myisam表保持一致。 而且这是一个较旧的脚本，需要大量的工作才能基于存储引擎进行不同的备份。
由于该脚本已经将--force选项传递给mysqldump，这意味着我正在获取备份中的数据，并且不是完全失败。 如果有些人在半夜工作的话，就有可能不完全一致。 事实上，我实际上在我的转储中获取数据使我的事情，这纯粹是关于锁的特权。
所以我想用最less的改变来解决这个问题。 为什么我只有在Innodb表的数据库上才会出现锁表错误？ 我必须授予更多特权来lockingInnodb表吗？
经过更多的调查，我发现问题数据库中的一些VIEWS的定义者的问题。
Got error: 1449: The user specified as a definer ('cittool'@'%') does not exist when using LOCK TABLES
这个帐户属于一个不在身边的开发者，并已被删除。 在dba.stackexchange上的家伙的帮助下，我能够build立一个脚本，用一个实际存在的帐户来replace我的视图。