I had executed the following command :
mysqldump -u root db_name --add-drop-database --routines --verbose > db_name.sql 2>db_name.log
But when I checked the sql file content, there were no stored procedure creation syntaxes. I also checked the log file and received the same result.
Anyone know what is the root cause of this issue? I have already googled around and found this one https://github.com/sequelpro/sequelpro/issues/517. But still there's no workaround.
FYI, I'm using MariaDB 10.2.
You might be missing a permission:
ยท --routines, -R
Included stored routines (procedures and functions) for the dumped databases in the output. Use of this option requires the SELECT privilege for the mysql.proc table. The output generated by using --routines contains CREATE PROCEDURE and CREATE FUNCTION statements to re-create the routines. However, these statements do not include attributes such as the routine creation and modification timestamps. This means that when the routines are reloaded, they will be created with the timestamps equal to the reload time.
If you require routines to be re-created with their original timestamp attributes, do not use --routines. Instead, dump and reload the contents of the mysql.proc table directly, using a MariaDB account that has appropriate privileges for the mysql
database.
Related
I want to create a FULL BACKUP of my database (MySQL) and I'm using the command:
mysqldump --routines -u dev_user -pblabla MyDB > d:\DB_Backups\%date%.sql
(this is on a Windows machine with a simple .bat script).
All of the sadden, I realized that all the routines stopped from being included in the created file.
Is there a way to create a full backup that can then be used to create a new DB (in production) with the whole contents of the database?
Thanks in advance.
For my windows mysql 5.6.24 install, I would use the -R switch, such as
mysqldump -u root -p -R so_gibberish > c:\nate\out123.sql
Note, the -p prompts for the password, and the db name is so_gibberish.
And the output file would contain the tables, procedures, and functions:
As an aside, please see the Mysql Manual Page on Restrictions on Views. Also, these fine answers on the stack:
The role of the Definer by ivanhoe
Various topics plus updated comments by Rolando
Though the above may not immediately address your issue, I am still looking, and may assist others.
I had the same problem and was missing the privilege SELECT on mysql.proc table for the user I was using with mysqldump.
According to the documentation:
Include stored routines (procedures and functions) for the dumped databases in the output. This option requires the SELECT privilege for the mysql.proc table.
What are the minimum privilege required for a mysql db user to use the mysqldump file and restore.
Cannot use root db user in my case.
Have taken full backup of all schemas in a dump file using mysqldump utility.
Need to know minimum required privileges to be given to a db user(other than root db user) so that it can be used to do restore from mysqldump file.
It is not possible to restore a complete, unmodified dump file to a MySQL Server without the SUPER privilege.
The "root" user is not a magical user. It just happens to be a user that is created by default and has GRANT ALL PRIVILEGES ON *.* ... WITH GRANT OPTION. Another user can be given the same privileges.
Restoring a database essentially means obliterating everything on a server and replacing it with something else, including all the user accounts so SUPER is required.
More limited privileges can be used if certain modifications to the dump file are made, such as removing all DEFINER statements, and modifying the way the mysql schema is handled, but those modifications are an advanced topic with system-specific considerations.
I've started with SUPER, INSERT, & ALTER and tried repeatedly adding new ones until the restore finished successfully.
This is what I've ended up with:
SUPER
ALTER
INSERT
CREATE
DROP
LOCK TABLES
REFERENCES
SELECT
If you have routines and triggers then you'll need these two additionally:
CREATE ROUTINE
TRIGGER
Hope this helps.
From the Mysql official site:
mysqldump requires at least the SELECT privilege for dumped tables,
SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK
TABLES if the --single-transaction option is not used. Certain options
might require other privileges as noted in the option descriptions.
--single-transaction
This option sets the transaction isolation mode to REPEATABLE READ and
sends a START TRANSACTION SQL statement to the server before dumping
data. It is useful only with transactional tables such as InnoDB,
because then it dumps the consistent state of the database at the time
when START TRANSACTION was issued without blocking any applications.
In conclusion, privileges are:
select (required)
lock tables (required)
show views and trigger (optional)
I'm attempting to dump all the databases from a 500Gb RDS instance into a smaller instance (100Gb). I have a lot of user permissions saved so I need to dump the mysql table.
mysqldump -h hostname -u username -ppassword --all-databases > dump.sql
Now when I try to upload the data to my new instance I get the following error:
mysql -h hostname -u username -ppassword < dump.sql`
ERROR 1044 (42000) at line 2245: Access denied for user 'staging'#'%' to database 'mysql'
I would just use a database snapshot to accomplish this, but my instance is smaller in size.
As a sanity check, I tried dumping the data into the original instance but got the same error. Can someone please advise on what I should do here? Thanks!
You may need to do the databases individually, or at least remove the mysql schema from the existing file (perhaps using grep to find the line counts for the USE database; statements and then sed to trim out the troublesome section, or see below), and then generate a dump file that doesn't monkey with the table structures or the proprietary RDS triggers in the MySQL schema.
I have not tried to restore the full mysql schema onto an RDS instance, but I can certainly see where it would go awry with the customizations in RDS and the lack of SUPER privilege... but it seems like these options on mysqldump should get you close, at least.
mysqldump --no-create-info # don't try to drop and recreate the mysql schema tables
--skip-triggers # RDS has proprietary triggers in the mysql schema
--insert-ignore # write INSERT IGNORE statements to ignore duplicates
--databases mysql # only one database, "mysql"
--skip-lock-tables # don't generate statements to LOCK TABLES/UNLOCK TABLES during restore
--single-transaction # to avoid locking up the source instance during the dump
If this is still too aggressive, then you will need to resort to dumping only the rows from the specific tables whose content you need to preserve ("user" and the other grant tables).
THERE IS NO WARRANTY on the following, but it's one from my collection. It's a one-liner that reads "old_dumpfile.sql" and writes "new_dumpfile.sql"... but switching the output off when it sees the USE or CREATE DATABASE statements with `mysql` on the same line, and switching it back on again the next time such a statement occurs without `mysql` in it. This will need to be modified if your dump file also has the DROP DATABASE statements in it, or you could generate a new dumpfile with --skip-add-drop-database.
Running your existing dump file through this should essentially remove only the mysql schema from that file, allowing you to easily restore it manually, first, and then let the rest of the database data flow in more smoothly.
perl -pe 'if (/(^USE\s|^CREATE\sDATABASE.*\s)`mysql`/) { $x = 1; } elsif (/^USE\s`/ || /^CREATE\sDATABASE/) { $x = 0; }; $_ = "" if $x;' old_dumpfile.sql > new_dumpfile.sql
I guess you can try to use workbench. There is a migration function there, create the smaller instance (100GB) first, then use that migration feature to migrate from 500GB to the 100GB one see if it works.
I have had too many access denied issues with the RDS MySQL. So running below command on RDS is my way out:
GRANT ALL ON `%`.* to '<type_the_usernamne_here>'#'%';
I am not sure whether this will be helpful in your case. But it has always been a life saviour for me.
This may seem like a very dumb question but I didn't learn it in any other way and I just want to have some clarification.
I started to use MySQL a while ago and in order to test various scenarios, I back up my databases. I used MySQL dump for that:
Export:
mysqldump -hSERVER -uUSER -pPASSWORD --all-databases > filename.sql
Import:
mysql -hSERVER -uUSER -pPASSWORD < filename.sql
Easy enough and it worked quite well up until now, when I noticed a little problem with this "setup": It does not fully "reset" the databases and tables. If, for example, there is an additional table added AFTER a dump file has been created, that additional table will not disappear if you import the same dump file. It essentially only "corrects" tables already there and recreates any databaes or tables missing, but does not remove any additional tables, which happen to have names that are not in the dump file.
What I want to do is to completely reset all the databases on a server when I import such a dump file. What would be the best solution? Is there a special import function reserved for that purpose or do I have to delete the databases myself first? Or is that a bad idea?
You can use the parameter --add-drop-database to add a "drop database" statement to the dump before each "create database" statement.
e.g.
mysqldump -hSERVER -uUSER -pPASSWORD --all-databases --add-drop-database >filename.sql
see here for details.
There's nothing magic about the dump and restore processes you describe. mysqldump writes out SQL statements that describe the current state of the database or databases you are dumping. It has to fetch a list of tables in each database you're dumping, then it has to read the tables one by one and write them out as SQL. On databases of any size, this takes time.
So, if you create a new table while mysqldump is running, it may not pick up that new table. Similarly, if your application software changes contents of tables while mysqldump is running, those changes may or may not show up in the backup.
You can look at the .sql files mysqldump writes out to see what they have picked up. If you want to be sure that your dumped .sql files are perfect, you need to run mysqldump on a quiet server -- one where nobody is running data definition language.
MySQL hot backup solutions are available. You may need to look into that.
The OP may want look into
mysql_install_db
if they want a fresh start with the post-install default
settings before restoring one or more dumped DBs. For
production servers, another useful script is:
mysql_secure_installation
Also, they may prefer to dump the DB(s) they created separately:
mysqldump -hSERVER -uUSER -pPASSWORD --database foo > foo.sql
to avoid inadvertently changing the internal DBs:
mysql, information_schema, performance_schema.
I need to copy a MySQL DB from a server on Linux to a server on Windows. I've tried using mysqldump but it doesn't seem to include Stored Procs. I want to copy everything, i.e. schema, data, stored procs, triggers, etc.
Thanks,
Don
You want the "--routines" option of mysqldump.
From the documentation for --routines flag:
Dump stored routines (procedures and
functions) from the dumped databases.
Use of this option requires the SELECT
privilege for the mysql.proc table.
The output generated by using
--routines contains CREATE PROCEDURE and CREATE FUNCTION statements to
re-create the routines. However, these
statements do not include attributes
such as the routine creation and
modification timestamps. This means
that when the routines are reloaded,
they will be created with the
timestamps equal to the reload time.
If you require routines to be
re-created with their original
timestamp attributes, do not use
--routines. Instead, dump and reload the contents of the mysql.proc table
directly, using a MySQL account that
has appropriate privileges for the
mysql database.
This option was added in MySQL 5.1.2.
Before that, stored routines are not
dumped. Routine DEFINER values are not
dumped until MySQL 5.1.8. This means
that before 5.1.8, when routines are
reloaded, they will be created with
the definer set to the reloading user.
If you require routines to be
re-created with their original
definer, dump and load the contents of
the mysql.proc table directly as
described earlier.
mysqldump -u root -p --routines --databases io \
| sed -e "s/;;/\$\$/g" \
> io.sql
please try dump. and import command to :
mysql -u root -p --fource --databases io < io.sql