环境: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
网上有很多其他类似问题的报道。 mysqldump手册页有一个关于备份视图的错误的神秘注释,但它是作为历史问题而不是当前问题编写的。
所以,问题是:MySQL能否可靠地恢复包含视图的备份?如果可以,怎么样?如果没有,人们会做什么作为解决方法?
谢谢, 里斯
答案 0 :(得分:11)
这个问题有点陈旧,但我只是浪费了几个小时试图解决完全相同的问题,所以我想一个明确的解释可能会在将来派上用场......
切入追逐:问题出在你的mysql转储中的DEFINER字段中。它看起来像:
/*!50013 DEFINER=`some_user`@`localhost` SQL SECURITY DEFINER */
问题是这个* some_user @ localhost *将始终硬编码到用于在原始数据库中创建视图的用户帐户以及 NOT 您用于导出的用户或按照人们的预期导入数据库(或者至少我做过)。稍后,在导入期间,此用户将用于重新创建视图。
因此,您可以以root身份导出/导入,但如果原始数据库在另一个用户下运行且新数据库中没有CREATE VIEW权限,则导入将失败。
您有两个简单的解决方案:
some_user
@ localhost
的所有引用。无论哪种方式都可以解决问题,但我认为第一种方法更好更清洁,因为您将来不必担心多个用户。
答案 1 :(得分:8)
我发现解决问题的方法是在最初创建视图时使用'sql security invoker'。
create or replace sql security invoker view <VIEW_NAME> as select ...
它定义了调用者对视图的访问,而不是定义者。
然后加载转储文件时,视图会正确创建。
使用Amazon RDS:
要使用Amazon RDS(不允许使用super priv(需要执行上述操作)),可以在转储文件上运行此命令:
# Remove DEFINER statement from VIEWS in Dump file
sed -i 's/\sDEFINER=`[^`]*`@`[^`]*`//' $DUMPFILE_NAME
然后,当转储文件加载到RDS中时,视图就会正确创建。
答案 2 :(得分:3)
我在我的案例中发现了问题。我不确定它是否在网上解决了类似的报道。
这基本上是因尝试将此数据库复制到新名称而导致的权限问题。此用户和架构(curation2上的轨迹)不存在权限。我手动添加'GRANT ALL ON curation2。* TO locus'(locus是用户在错误中报告的)。执行此操作后,上面的命令行运行正常。
经验教训是,在创建新数据库时,必须手动向目标数据库和表授予必要的权限。
答案 3 :(得分:0)
一些事情:
1。)是的,您可以使用某个客户端创建视图但是表的所有者可能不是视图的所有者,这导致
2。)通常,在mysql中备份视图包括一些“无用的垃圾”,如
create algorithm xxx definer=<USER> sql security view <view_name> as ....
并且该用户通常包括用户在创建视图时登录的IP或机器名称...因此,视图将无法正确创建。检查一下,可能对你有帮助。