I'm using mysqldump to share databases dumps, but i'm having an issue with triggers. The command does not add "drop" or "replace" lines with the triggers, making people who already added a previous dump with same triggers names having an error :
ERROR 1359 (HY000) at line 1420: Trigger already exists
I've read on forums people saying it's a missing feature for mysql, but all posts are old and i'm wondering if there could be a way to do it now.
I know there is a way to dump schema and data separately, but i'd like to keep a single dump to share.
There's a mysqldump option --skip-triggers you should use that to skip triggers.
You don't specify version. mysqldump 5.6 and above has --add-drop-trigger option.
Related
I'm testing a python script that requires me to manually clear and restore a fresh copy of my database for the purposes of debugging it. Basically each time the script cracks up, it breaks my database and I need a fresh copy. It would be really convenient if I could just run a sql script to so so. This is trivial except for the part when I re-import the data from a file on my machine; I can't seem to figure out how to do that within the sql script.
I can do it by clicking through the GUI as detailed here.
And I can do it by running this in the terminal
mysql -u root -p testdb < filename.sql
But what I would really like to do is to throw a line in my sql script along with my drop and create commands. Something like this
drop schema testing2;
create database testing2;
use testing2;
some command to restore from ....\Dump20230125.sql
I read here that I could use source ....\Dump20230125.sql but mysql workbench throws a syntax error and says that "source is not valid at this position"
Is there a way to accomplish what I'm after?
I have a large dump(~50GB) of MySQL database(Multiple databases backup). I am restoring it to a new Server which is taking a long time. I think it is taking this much time because it is huge data. the command ( gunzip < 1922-1648-329-75_all-databases.sql.20220305-0000.gz | MySQL -u test -p) also working fine and it started importing. But after some time, I'm getting an error called "Unknown column 'id' in 'OLD'". I have troubleshot and found that this error is coming from one of the triggers in the backup file.
I don't really need triggers on the new server. Is there a command-line option to use in MySQL which will allow me to skip the triggers while restoring the dump?
Below is the Restore Commane which I am using.
gunzip < 1922-1648-329-75_all-databases.sql.20220305-0000.gz | MySQL -u test -p
Recreate the dump if you can, using the --skip-triggers option. You will have to recreat them afterwards.
https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_triggers
There is no option available to disable the triggers on import.
rewrite your faulty trigger code.
you have an INSERT trigger with OLD in it, which is not supported.
Maybe it is acopy paste error, but such things must be made before making a backup runs.
the link below shows you how to select all triggers, this should help to find the problematic trigger
How do you list all triggers in a MySQL database?
I got a DB in MYSQL (that I haven't created), I do not have the code that was used for it.
I want to know what was the code used to create one of the tables in the DB , is there an option to do so? I need to create the same table but on diffrent data..
Thanks alot!
P
In MySQL Workbench you can display the DDL for any DB object. Just right click on it in the schema tree on either Copy to Clipboard or Send to SQL Editor and Create Statement:
This is a late answer, but since I don't see any reference to it, I'll suggest you to perform a dump of your database. Every decent DBMS has now a tool to do it. With MySQL, from command line, this would be :
mysqldump -u <username> <database_name> > yourfile.sql
This performs a complete dump in SQL format of your base, enabling you to recreate it elsewhere. No need for any special tool to do it when you need to. Just pass the content of the file to the regular MySQL's client.
If you want to get only the database schema without any data, just pass "--no-data" option.
mysqldump --no-data -u <username> <database_name> > yourfile.sql
You'll now be able to recreate a brand new, virgin database, having all attributes and special features of the previous one, without the data.
I need to write a script to automate MySQL backup of a database. So to determine what I will need, I go into MySQL Workbench, select the Schema, select Data Export, set a couple of controls (at the moment: Export to Self-Contained File & Include Create Schema) and Start Export.
Export Progress shows me command-line:
Running: mysqldump --defaults-file="/tmp/tmpTbhnzh/extraparams.cnf" --user=*** --host=*** --protocol=tcp --port=3306 --default-character-set=utf8 --skip-triggers "<schema-name>"
I need to know what is in that temporary "defaults file" if I'm to replicate whatever it is that MySQL Workbench passes to mysqldump. But the backup completes so quickly and deletes the file that I can't even copy it, of course!
Is there a way I can know just what arguments Workbench is passing to mysqldump so I can know I'm generating a good, robust script? (To be clear: I'm sure I can look up the mysqldump documentation to find arguments corresponding to whatever UI items I fill in explicitly, but I'm wondering what other "goodies" MySQL Workbench might know about and put in the parameters file.)
A bit of digging about in the python scripts (there's one called wb_admin_export.py) and the answer is....not very exciting... it's your password.
It also includes ignore-tables if there are any to ignore.
The problem is, that one MYI and one MYD file from MySQL database has been accidentally deleted. The only file left intact is FRM one. Only one table from the whole database is damaged that way, all other tables are OK and the database works generally fine, except the table with deleted files, which is obviously inaccessible.
There's a full database dump in pure SQL format available.
The question is, how do I re-create these files and table in safe and proper manner?
My first idea was to extract the full create table command from the dump and run it on live database. It's not so easy, as the whole dump file has over 10GB, so any operations within its content are really pain in . Yes, I know about sed and know how to use it - but I consider it the last option to choose.
Second and current idea is to create copy of this database on independent server, make a dump of the table in question and then use resulting SQL file to create the table again on the production server. I'm not quite experienced with MySQL administration tasks (well, just basic ones), but for me this option seems to be safe and reasonable.
Will the second option work as I expect?
Is it the best option, or are there any more recommendable solutions?
Thank you in advance for your help.
The simplest solution is to copy the table you deleted. There's a chance mysqld still has an open file handle to the data files you deleted. On UNIX/Linux/OS X, a file isn't truly deleted while some process still has an open file handle to it.
So you might be able to do this:
mysql> CREATE TABLE mytable_copy LIKE mytable;
mysql> INSERT INTO mytable_copy SELECT * FROM mytable;
If you've restarted MySQL Server since you deleted the files, this won't work. If the server has closed its file handle to the data file, this won't work. If you're on Windows, I have no idea.
The next simplest solution is to restore your existing 10GB dump file to a temporary instance of MySQL Server, as you said. I'd use MySQL Sandbox but some people would use a virtual machine, or if you're using an AWS environment, launch a spot EC2 instance or a small RDS instance.
Then dump just the table you need:
mysqldump -h tempserver mydatabase mytable > mytable.sql
Then restore it to your real server.
mysql -h realserver mydatabase < mytable.sql
(I'm omitting the user & password options, I prefer to put those in .my.cnf anyway)