Is there a concise way to ignore multiple tables using mysql --ignore-table?
The documentation says that --ignore-table must be used for each table.
I have to ignore around 20 tables so the command is going to be huge
This must be run via the command line
Go the whitelist route instead of the blacklist route. From the man page:
mysqldump [options] [db_name [tbl_name ...]]
You still have to type everything out, but at least you don't have to continuously type the --ignore-table flag.
Try using MySQL Workbench to build the command. It'll give the option to specify which tables you want via checkboxes.
If you need to, you can copy and paste the command from the Export Progress tab.
Related
I want to write a set of small shell scripts to help me keep MySQL schema in git. But one crux is that mysqldump -uuser -ppass -d devdb > schema.sql includes two things that change over time even if there are no schema changes:
AUTO_INCREMENT=[some number] at the end of the definition of any table that has an auto-incremented column
-- Dump completed on [date and time] at the end
I have scoured the web for ways to get a dump without those things, to no avail. Can you advise? Or should I be using a different command or tool to get a clean schema for use in version control?
EDIT: I just now found the --skip-dump-date option, so that solves point #2, but I still can't get rid of the auto-increment number without losing the other table attributes (or whatever you call those things) like the engine and the default character set.
There is no way to bypass #1, check https://bugs.mysql.com/bug.php?id=20786.
As noted in the comments section, you can use that sed command to filter it out (unless you have some CREATE TABLE statements that use it).
When I create a view, I create it in the context of the default database. So none of my references to table have a prefix which explicitly specify a database. However, when I edit a view in Workbench it automatically adds the database prefix!
I don't want the database prefix because when I restore a database under a different name it causes the restore to fail.
Is this possible to stop the prefixing in a view edit or there another way to get round the restore issue?
see https://bugs.mysql.com/bug.php?id=85176
The mysql 8.0.3 or above has been fixed
That's not possible. Views are stored in specific databases, not in some space "above" all databases. Consider following...
use playground_a; /*or whatever database*/
create view view_whatever as
select * from table_whatever;
use playground_b;
select * from view_whatever; /*here you will get an error that view_whatever does not exist*/
select * from playground_a.view_whatever; /*this works*/
That's why there will always be database prefixes in the view definition.
The only possibility I see, would be to use a stored procedure with a database name as parameter. In the procedure you'd use a prepared statement to execute a concated string of your query and the database name parameter. Of course this comes with downsides, like i.e. you can't add a where clause easily.
Creating the view without explicitely specifying a schema is a convenience feature. Behind the scenes the view is still saved in a specific schema (the default one in this case). When editing the source code is retrieved from the server which returns the real code (including the schema qualification). Hence already when you send the view code the association happens and cannot be removed again later.
Here is the command I use to create the backup:
mysqldump -u xxxxxx -pxxxxxx --routines database_a | gzip -9 > $FULLGZIPPATH
If you aren't easily able to update to MySQL 8.X then a workaround I've implemented was a post-processing step performed on the dump file itself prior to importing. I just remove the explicit prefixed db name, since the import process / view creation doesn't need it.
PowerShell -Command ^
"filter replace-dbname { $_ -replace '`<DB_NAME>`.`', '`' }"^
"Get-Content dump.sql -ReadCount 10 | replace-dbname | Add-Content replaced_dump.sql"
I've used PowerShell since I'm on Windows, but any scripting language will do. The only notes are that:
You'll need to do the replacement a-few-lines-at-a-time if you can't afford to read the entire dump into memory. Our dumps are about 11GB, which'd be a strain on our testing server's resources.
In my script I'm not doing an in-place string replacement, so it'll create a new dump file replaced_dump.sql alongside the original dump.sql. For me this was useful for diagnostics, because it meant if there was an issue, I didn't have to dump it again. Again, depending on your dump/disk size this might be an issue.
If your database happens to have `<DB_NAME>`.` as content in something like a text-field, this basic approach will also remove the string there as well.
How do I stop using a database?
To start mysql, you can use:
mysql -u root -pXXXX<ENTER>
At this time, no database is selected. We'll call this
state 1
To select (or use) a database:
use "MyDB";
.....My operations or queries
Now, I want to return to state 1 (without any database selected). How I can do that? I can select another database, but I don't want to do that.
What you are asking for is not possible. The only way to return to that state is to disconnect and then reconnect.
If you are just looking to switch away from your current db, you can switch to a system database, such as the internal "mysql" database:
use mysql
Or you could create an empty database and use that:
create database empty;
use empty
Try prompt.
From the MySQL manual:
Reconfigure the mysql prompt to the given string. The special
character sequences that can be used in the prompt are described later
in this section.
If you specify the prompt command with no argument, mysql resets the prompt to the default of mysql>.
Ike Walker's answer is on the right track me thinks.
Create a swap space, or you could just halt the server (stop the process) and restart it I suppose. That defeats the purpose of the server—but it would for sure wind up where you want it with no database in 'use'.
I'm certain you know this, but I mention here just in case. You never know. Someone might not know it is possible to do this.
If I export a database with phpmyadmin his size is 18MB
If I expoert it from terminal using this command is size is only 11MB.
/usr/bin/mysqldump --opt -u root -ppassword ${DB} | gzip > ${DB}.sql.gz
Could you explain me why ? Is because of --otp parameter ?
How can I be sure the database has been succesfully exported ? Should I inspect it.. still it is not a reliable evaluation. thanks
With the details you've given, there are a number of possibilties as to why the sizes may differ. Assuming the output from phpMyAdmin is also gzipped (otherwise the obvious reason for the difference would be that one is compressed, the other isn't), the following could affect size to some degree:
Different ordering of INSERT statements causing differences in the compressibility of the data
One using extended inserts, the other using only standard inserts (this seems most likely given the difference in sizes).
More comments added by the phpMyAdmin export tool
etc...
I'd suggest looking at the export to determine completeness (perhaps restore it to a test database and verifying that the row-counts on all tables are the
I don't have enough points to comment so I'm adding my comments in this answer...
If you look at the uncompressed contents of the export files from a phpmyadmin export and a mysqldump they will be quite different.
You could use diff to compare the two sql files:
diff file1.sql file2.sql
However, in my experience that will NOT be helpful in this case.
You can simply open the files in your favorite editor and compare them to see for yourself.
As mentioned by Iridium in the previous answer, the use of inserts can be different. I created two new empty databases and imported into each (via phpmyadmin) - one of the two exports mentioned above (one from phpmyadmin and the other via mysqldump).
The import using the mysqldump export file recreated the database containing 151 tables with 1484 queries.
The import using the phpmyadmin export file recreated the database containing 151 tables with 329 queries.
Of course these numbers apply only to my example, but it seems to be in line what Iridium was talking about earlier.
Hi I need to backup MySQL database and then deploy it on another MySQL server.
The problem is, I need it backup without data , just script which creates database, tables, procedures, users, resets autoincrements etc. ...
I tried MySQL administrator tool (Windows) and UNchecked "complete inserts check box", but it still created it ...
Thanks in advance
use mysqldump with option -d or --no-data
don't forget option -R to get the procedures
this page could help you: http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html
From within phpMyAdmin you can export the structure, with or without the data. The only thing I'm not sure of, is wether it exports users as well. If you like, I can test that tomorrow morning. It exports users too. You can check all sorts of options.
(source: obviousmatter.com)
According to the page, there isn't a good way to dump the routines and have them easily able to be recreated.
What they suggest is to dump the mysql.proc table directly. Including all the data.
Then use your myback.sql to restore the structure. Then restore the mysql.proc table with all of its data.
"... 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. ..."