系统升级引入了一个异常的mysql权限错误

Question

在运行 mysql 的机器升级后，备份脚本为具有 Innodb 表的数据库返回错误。

运行 Debian 5 (Lenny) 的系统已升级到 Debian 6 (Squeeze)，并且该系统正在运行来自 Debian 存储库的库存 mysql-server 软件包。

• Debian 5 = Mysql 5.0.51a
• Debian 6 = Mysql 5.1.49

备份由一个脚本执行，该脚本备份多个 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

常规备份帐户具有锁表权限，并且在系统升级之前运行良好的备份。但我也尝试过使用 root 帐户并看到相同的错误。

mysql> show grants for 'backup'@'%';
GRANT SELECT, RELOAD, LOCK TABLES, SHOW VIEW 
      ON *.* TO 'backup'@'%' IDENTIFIED BY PASSWORD '*...'

我知道我可能根本不使用 Innodb 数据库上的 lock-tables 选项--single-transaction，而是使用该选项，但这不会很好地工作。几个数据库有同时使用 Myisam 和 Innodb 存储引擎的表，并且单个事务选项不会使 Myisam 表保持一致。此外，这是一个较旧的脚本，需要大量的工作才能根据存储引擎进行不同的备份。

由于脚本已经将--force选项传递给 mysqldump，这意味着我正在备份中获取数据，并且它并没有完全失败。如果有些人在半夜工作，那么它就有可能不会完全一致。我实际上在我的转储中获取数据这一事实让我认为这纯粹是关于锁定特权。

所以我想用最少的改动来解决这个问题。为什么我只在基于 Innodb 的表的数据库上收到锁表错误？我是否必须授予更多权限才能锁定 Innodb 表？

Answer 1

经过更多调查后，我发现问题数据库中某些视图的定义器存在问题。

Got error: 1449: The user specified as a definer ('cittool'@'%') does not exist when using LOCK TABLES

该帐户属于不再存在的开发人员，并且已被删除。在dba.stackexchange上的人们的帮助下，我能够构建一个脚本来用实际存在的帐户替换我的视图。