Может ли MySQL надежно восстанавливать резервные копии, содержащие представления или нет?

Question

Среда: Ubuntu 11.10, MySQL 5.1.58

У меня есть небольшая база данных с представлениями. Когда я пытаюсь сбросить и восстановить, я получаю

ERROR 1356 (HY000) at line 1693: View 'curation2.condition_reference_qrm_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

Однако я могу подключиться к частично восстановленной базе данных и создать представление самостоятельно. Поэтому я подозреваю, что сообщение об ошибке является результатом проблемы, не связанной с самим представлением (а скорее с тем, как оно восстанавливается, возможно).

Вот простой подход, который я использую для демонстрации проблемы:

MYSQL_PWD='xxx' mysqldump -u root --routines -B curation \
| perl -pe 's/`curation`/`curation2`/' \
| MYSQL_PWD='xxx' mysql -u root

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

Итак, вопрос: может ли MySQL надежно восстанавливать резервные копии, содержащие представления, или нет? Если это возможно, то как? Если нет, то что люди делают в качестве обходного пути?

Спасибо, Reece

Answer 1

Этот вопрос немного устарел, но я просто потратил пару часов, пытаясь решить точно такую ​​же проблему, поэтому я думаю, что ясное объяснение может пригодиться кому-то в будущем ...

Чтобы перейти к погоне: проблема в поле DEFINER в вашем дампе mysql.Это выглядит примерно так:

/*!50013 DEFINER=`some_user`@`localhost` SQL SECURITY DEFINER */

Проблема в том, что этот * some_user @ localhost * всегда будет жестко привязан к учетной записи пользователя, которая использовалась для создания представления в исходной БД, а NOT * 1007.* пользователь, которого вы использовали для экспорта или импорта базы данных, как и следовало ожидать (или, по крайней мере, я сделал).И позже, во время импорта, этот пользователь будет использоваться для воссоздания представления.

Таким образом, вы можете экспортировать / импортировать как root, но если исходная БД работает под другим пользователем и у нее нет CREATE VIEWправа в новой базе данных, импорт не удастся.

У вас есть два простых решения:

1. Поиск и замена всех ссылок на some_user @ localhost в файле дампа наваш новый пользователь (тот, которого вы используете для импорта дампа, например root @ localhost)
2. Или вы можете предоставить * some_user * соответствующие права на новую базу данных, чтобы представления могли создаваться под его учетной записью

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

Answer 2

Что я нашел, чтобы решить эту проблему, так это использовать 'sql security invoker' при первоначальном создании представления.

  create or replace sql security invoker view <VIEW_NAME> as select ...

Определяет доступ к представлению вызывающим, а не определителем.

Затем, когда файл дампа загружен, представление создается правильно.

С Amazon RDS:

Чтобы это работало с Amazon RDS, который не позволяет использовать супер привилегию (что необходимо для выполнения вышеупомянутого), можно запустить эту команду в файле дампа:

 # Remove DEFINER statement from VIEWS in Dump file
 sed -i 's/\sDEFINER=`[^`]*`@`[^`]*`//' $DUMPFILE_NAME

Затем, когда файл дампа загружен в RDS, представление создается правильно.

Answer 3

Я нашел проблему в моем случае. Я не уверен, что он решает подобные отчеты в Интернете.

По сути, это была проблема с правами доступа, возникшая в результате попытки скопировать эту базу данных под новым именем. Разрешения не существовали для этого пользователя и схемы (местоположение на curation2). Я вручную добавил «GRANT ALL ON curation2. * TO locus» (locus - это пользователь, сообщивший об ошибке). После этого вышеуказанная командная строка работала нормально.

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

Answer 4

Пара вещей:

1.) Да, вы можете создавать представления с использованием некоторого клиента, НО, возможно, владелец таблиц не является владельцем представления, что приводит к

2.) Обычно создание резервных копий представлений в mysql включает в себя «бесполезный мусор», такой как

create algorithm xxx definer=<USER> sql security view <view_name> as ....

и этот пользователь часто включает IP-адрес или имя компьютера, который пользователь вошел в систему при создании представления ... ТАК, представление не будет создано должным образом. Проверьте это, может помочь вам.