☰

系统升级引入了不寻常的 mysql 权限错误

tag-icon • tag-icon debian mysql
系统升级引入了不寻常的 mysql 权限错误

运行 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

常规备份帐户具有锁定表权限，并且在系统升级之前备份运行良好。但我也尝试使用 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 表？

答案1

经过进一步调查后，我发现问题数据库中某些 VIEWS 的定义器存在问题。

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

这个账号属于一个不再存在的开发者，已被删除。在dba.stackexchange我能够编写一个脚本来用实际存在的帐户替换我的观点。

相关内容