copy MySql DB from one server to another - mysql

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

Related

Is there a way to reverse engineer the commands to create a database schema?

I have an existing MySQL database with many tables, and I want to turn the schema into SQL statements that could be used to replicate database (or at the very least, all of the CREATE TABLE statements).
In MySQL Workbench I can right-click on any individual table and copy the CREATE statement for it, but I don't see a way to do this for the entire database.
Export your database in phpMyAdmin make sure to check structure only. Or you can the command line:
mysqldump --no-data -u someuser -p mydatabase
You can reverse engineer you DB using MySQL Workbench.
It is under Database in menu: Database | Reverse Engineer & Provide connection information.
As already mentioned, you can create script using mysqldup CLI.
If you have triggers, storage procedures, events -- do not forget to include special params:
mysqldump --no-data --host=server --user=usr --password=pwd --events --routines --triggers db-name
Finally, 3rd party tools can be used to dump DB (with or without data) into sql-file or directly into different DB server.
I'm personally using free HeidiSQL GUI on Windows.

mysqldump not dumping stored procedures

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.

mysqldump --routines not including routines in created file

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.

MySQL/Amazon RDS error on import

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.

Restoring selective tables from an entire database dump?

I have a mysql dump created with mysqldump that holds all the tables in my database and all their data. However I only want to restore two tables. (lets call them kittens and kittens_votes)
How would I restore those two tables without restoring the entire database?
Well, you have three main options.
You can manually find the SQL statements in the file relating to the backed up tables and copy them manually. This has the advantage of being simple, but for large backups it's impractical.
Restore the database to a temporary database. Basically, create a new db, restore it to that db, and then copy the data from there to the old one. This will work well only if you're doing single database backups (If there's no CREATE DATABASE command(s) in the backup file).
Restore the database to a new database server, and copy from there. This works well if you take full server backups as opposed to single database backups.
Which one you choose will depend upon the exact situation (including how much data you have)...
You can parse out CREATE TABLE kittens|kitten_votes AND INSERT INTO ... using regexp, for example, and only execute these statements. As far as I know, there's no other way to "partially restore" from dump.
Open the .sql file and copy the insert statements for the tables you want.
create a new user with access to only those 2 tables. Now restore the DB with -f (force) option that will ignore the failed statements and execute only those statements it has permission to.
What you want is a "Single Table Restore"
http://hashmysql.org/wiki/Single_table_restore
A few options are outlined above ... However the one which worked for me was:
Create a new DB
$ mysql -u root -p CREATE DATABASE temp_db
Insert the .sql file ( the one with the desired table ) into the new DB
$ mysql -u root -p temp_db < ~/full/path/to/your_database_file.sql
dump the desired table
$ mysqldump -u root -p temp_db awesome_single_table > ~/awesome_single_table.sql
import desired table
$ mysql -u root -p original_database < ~/awesome_single_table.sql
Then delete the temp_db and you're all golden!