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.
Related
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.
I've been migrating ddbb (a few GB size) in mySQL workbench 6.1, from one mySQL server to another mySQL. Never having done this before I thought it was 99% reliable. Instead, 2 out of 3 tries have failed.
My ddbb dont have complex features (triggers, SP & functions,...). The errors, though, are difficult to interpret, almost always about tables failing to export, reason unknown. There might be occasionally a duplicated key index in source, but that shouldn't prevent an export from happening?
I've tried all the different methods available in the interface:
1) Server > Data Export > Data Import
2) Migration wizard
3) Schema transfer wizard
4) Reverse engineer
but no real difference.
Also, all methods seem variants of the same, do these menu options rely on the same procedure internally, how really different are they?
My questions are generic:
1) Is there a foolproof method, relaxed about errors, e.g. is
mysqldbcopy from myQL utilities much better that workbench wizards?
2) Does mySQL wizards configuration make any difference (e.g. a checkbox that causes errors by being too demanding if the source db has a problem) I just want to transfer the db, not perfection in the target server. I've switched SSL=NO, but still not working.
3) What is the single most important cause of errors in migration, e.g. server overloaded, enough memory, table structure?
Thanks in advance,
There might be occasionally a duplicated key index in source, but that shouldn't prevent an export from happening?
Yeah, It shouldn't prevent export operation.
I've tried all the different methods available in the interface:
All interface you have used might have some timeout configured so it don't really execute fully as your database is BIG.
So how to migrate MySQL database from one server to another?
To do it properly, I suggest you use command line like this:
Step 1: create backup file on old server
mysqldump -u [[user_name]] -p[[password]] [[db_name]] > db_backup.sql
Step 2: Transfer backup file to new server.
Step 3: Import backup file in new server.
mysql -u [[user_name]] -p[[password]] [[db_name]] < db_backup.sql
Pro tip:
you can combine step 1 & 2 if you have remote MySQL enabled on old server. Just execute this command on new server so it will download the backup file in current directory of new server.
mysqldump -h [[xxx.xx.xxx.xxx]] -u [[user_name]] -p[[password]] [[db_name]] > db_backup.sql
where [[xxx.xx.xxx.xxx]] represents ip address/hostname for old server.
Extra Note:
Please note that there is no space between -p and [[password]]. you can also omit the [[password]] if you think it's security issue to include password in command.
If you have access to your terminal you can try using "mysqldump" and also you could try percona xtrabackup tool.
Mysql dump : (If your DB is too large then I suggest you to use screens)
Backup all DB : mysqldump -u root -pxxxx --all-databases > all_db_backup.sql
Backup Tables : mysqldump -u root -pxxxx DatabaseName table1 table2 > tables.sql
Backup Individual databases : mysqldump -u root -pxxx --databases DB1 DB2 > Only_DB.sql
To import : Sync all the files to another server and try importing as show below
mysql -u root -pxxxx < all_db_backup.sql (Use Screen for large Databases)
Individual DB : mysql -u root -pxxx DBName < DB.sql
( Note : Before you import make sure your backuped file already has create database if not exists statements or you could create those DB names before importing )
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.
This question already has answers here:
How do I rename a MySQL database (change schema name)?
(46 answers)
Closed 8 years ago.
I created a database with the name of hrms. Now I need to change database name to sunhrm. But, It is disabled in MySQL workbench. Can I do that on the Linux server itself?
In case you need to do that from the command line, just copy, adapt & paste this snippet:
mysql -e "CREATE DATABASE \`new_database\`;"
for table in `mysql -B -N -e "SHOW TABLES;" old_database`
do
mysql -e "RENAME TABLE \`old_database\`.\`$table\` to \`new_database\`.\`$table\`"
done
mysql -e "DROP DATABASE \`old_database\`;"
I don't think you can do this. Basic answers will work in many cases, and in others cause data corruptions. A strategy needs to be chosen based on heuristic analysis of your database. That is the reason this feature was implemented, and then removed. [doc]
You'll need to dump all object types in that database, create the newly named one and then import the dump. If this is a live system you'll need to take it down. If you cannot, then you will need to setup replication from this database to the new one.
If you want to see the commands that could do this, #satishD has the details, which conveys some of the challenges around which you'll need to build a strategy that matches your target database.
It's possible to copy database via mysqldump command without storing dump into file:
mysql -u root -p -e "create database my_new_database"
mysqldump -u root -p original_database | mysql -u root -p my_new_database
mysql -u root -p -e "drop database original_database"
You can create a new database exactly as the previous database existed and then drop the old database when you're done. Use the mysqldump tool to create a .sql backup of the database via mysqldump orig_db > orig_db.sql or if you need to use a username and password then run mysqldump -u root -p orig_db > orig_db.sql. orig_db is the name of the database you want to "rename", root would be the user you're logging in as and orig_db.sql would be the file created containing the backup. Now create a new, empty database with the name you want for the database. For example, mysql -u root -p -e "create database new_db". Once that's done, then run mysql -u root -p new_db < orig_db.sql. new_db now exists as a perfect copy of orig_db. You can then drop the original database as you now have it existing in the new database with the database name you wanted.
The short, quick steps without all the above explanation are:
mysqldump -u root -p original_database > original_database.sql
mysql -u root -p -e "create database my_new_database"
mysql -u root -p my_new_database < original_database.sql
mysql -u root -p -e drop database originl_database
Hope this helps and this is a reliable means to accomplish it without using some ad-hoc method that will corrupt your data and create inconsistencies.
You can do it by RENAME statement for each table in your "current_db" after create the new schema "other_db"
RENAME TABLE current_db.tbl_name TO other_db.tbl_name
Source Rename Table Syntax
In short no. It is generally thought to be too dangerous to rename a database. MySQL had that feature for a bit, but it was removed. You would be better off using the workbench to export both the schema and data to SQL then changing the CREATE DATABASE name there before you run/import it.
I used following method to rename the database
take backup of the file using mysqldump or any DB tool eg heidiSQL,mysql administrator etc
Open back up (eg backupfile.sql) file in some text editor.
Search and replace the database name and save file.
Restore the edited SQL file
If your DB contains only MyISAM tables (do not use this method if you have InnoDB tables):
shut down the MySQL server
go to the mysql data directory and rename the database directory (Note: non-alpha characters need to be encoded in a special way)
restart the server
adjust privileges if needed (grant access to the new DB name)
You can script it all in one command so that downtime is just a second or two.
For impatient mysql users (like me), the solution is:
/etc/init.d/mysql stop
mv /var/lib/mysql/old_database /var/lib/mysql/new_database
/etc/init.d/mysql start
First backup the old database called HRMS and edit the script file with replace the word HRMS to SUNHRM. After this step import the database file to the mysql
Another way to rename the database or taking image of the database is by using Reverse engineering option in the database tab. It will create a ERR diagram for the database. Rename the schema there.
after that go to file menu and go to export and forward engineer the database.
Then you can import the database.
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