После обновления сервера, на котором запущен 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 Мне удалось создать сценарий для замены моих представлений существующей учетной записью.