Назад | Перейти на главную страницу

Обновление системы вызвало необычную ошибку привилегий mysql

После обновления сервера, на котором запущен mysql, сценарий резервного копирования возвращает ошибку для баз данных с таблицами Innodb.

Система под управлением Debian 5 (Lenny) была обновлена ​​до Debian 6 (Squeeze), и в системе был запущен стандартный пакет mysql-server из репозитория Debian.

Резервное копирование выполняется сценарием, который выполняет резервное копирование нескольких серверов mysql и создает резервную копию каждой отдельной базы данных отдельно.

Это команда и ошибка, возвращаемая get при запуске в базе данных таблиц 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 '*...'

Я знаю, что, вероятно, я мог бы просто не использовать опцию lock-tables в базе данных Innodb и использовать --single-transaction вариант, но это не будет работать очень хорошо. В паре баз данных есть таблицы с использованием как механизма хранения Myisam, так и Innodb, и вариант с единственной транзакцией не сделает таблицы Myisam согласованными. Кроме того, это более старый сценарий, и для его резервного копирования по-разному в зависимости от механизма хранения потребуется гораздо больше работы.

Поскольку сценарий уже проходит --force вариант mysqldump, что означает, что я получаю данные из резервной копии, и это не совсем сбой. Есть шанс, что это не будет полностью последовательным, если кто-то будет работать посреди ночи. Тот факт, что я фактически получаю данные в своем дампе, заставляет меня думать, что речь идет исключительно о привилегии блокировки.

Поэтому я хочу исправить проблему с наименьшим количеством изменений. Почему я получаю ошибку таблиц блокировки только в базах данных с таблицами на основе Innodb? Нужно ли мне предоставлять больше прав для блокировки таблицы Innodb?

После дополнительного расследования я обнаружил проблему с определителем на некоторых из ПРОСМОТРОВ в базе данных проблем.

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

Этот аккаунт принадлежал разработчику, которого больше не было, и он был удален. С помощью ребят dba.stackexchange Мне удалось создать сценарий для замены моих представлений существующей учетной записью.