debian 升级后mysql_debian – 系统升级引入了一个不寻常的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表？