Can MySQL reliably restore backups that contain views or not?

Question

Environment: Ubuntu 11.10, MySQL 5.1.58

I have a small database with views. When I try to dump and restore, I get

ERROR 1356 (HY000) at line 1693: View          


        

Answer 1

I found the problem in my case. I'm unsure that it solves similar reports on the web.

This was fundamentally a permission problem that resulted from trying to copy this database to a new name. Permissions didn't exist for this user and schema (locus on curation2). I manually added 'GRANT ALL ON curation2.* TO locus' (locus is the user reported in the error). After doing this, the above command line worked fine.

The lesson is that one must manually grant necessary permissions to the destination database and tables when creating a new database.

Answer 2

This question is a bit old, but I've just wasted a couple of hours trying to solve the exactly same issue, so I guess a clear explanation could come in handy to someone in the future...

To cut to the chase: The problem is in the DEFINER field in your mysql dump. It looks something like:

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

The problem is that this *some_user@localhost* will always be hardcoded to the user account that was used to create the view in the original DB and NOT the user that you've used to export or import the database as one would expect (or at least I did). And later, during the import, this user will be used to re-create the view.

So you can export/import as root, but if the original DB is running under another user and it has no CREATE VIEW rights in the new database, the import will fail.

You have two simple solutions:

1. Search and replace all references to some_user@localhost in your dump file with your new user (the one you use to import the dump, e.g. root@localhost)
2. Or you can grant *some_user* appropriate rights on the new database so that views can be created under his account

Either way will fix the problem, but I think the first approach is way better and cleaner, as you don't have to worry about multiple users in the future.

Answer 3

What I found to solve the problem is to use the 'sql security invoker' when creating the view initially.

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

It defines access to the view by the invoker, and not the definer.

Then when the dump file is loaded, the view is create correctly.

With Amazon RDS:

To make this work with Amazon RDS, which does not allow super priv (which is needed to do the above) one can run this command to on the dump file:

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

Then when the dump file is loaded into an RDS, the view is create correctly.

Answer 4

Couple of things:

1.) Yes, you can create the views using some client BUT perhaps the owner of the tables is not the owner of the view, which leads to

2.) Usually, doing backups of views in mysql includes some "useless garbage" like

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

and that user often includes the IP or machine name the user logged on when creating the view... SO, the view won't create properly. Check that out, might help you.