How to take MySql database backup using MySql Workbench?

Open MySql workbench. To take database backup you need to create New Server Instance(If not available) within Server Administration.Steps to Create New Server Instance:1. Select New Server Instance option within Server Administrator. 2. Provide connection details. After creating new server instance , it will be available in Server Administration list. Double click on Server instance you have created OR Click on Manage Import/Export option and Select Server Instance.Now, From DATA EXPORT/RESTORE select DATA EXPORT option,Select Schema and Schema Object for backup.You can take generate backup file in different way as given below-Q.1) Backup file(.sql) contains both Create Table statements and Insert into Table StatementsANS:1. Select Start Export Option Q.2) Backup file(.sql) contains only Create Table Statements, not Insert into Table statements for all tablesANS:1. Select Skip Table Data(no-data) option 2. Select Start Export OptionQ.3) Backup file(.sql) contains only Insert into Table Statements, not Create Table statements for all tablesANS:1. Select Advance Option Tab, Within Tables Panel- select no-create info-Do not write CREATE TABLE statement that re-create each dumped table option. Select Start Export Option

How to Recover an InnoDB table whose files were moved around

So I have a test db server that was setup on a replication stream. Over the name an optimize came through that quickly filled up the space on the slaves datadir. Mysql dutifully was just waiting for some more space.This datadir is a file system used ONLY as mysql's datadir so there wasn't anything else to free up.I had a 4 gig innodb test table that wasn't part of the replication stream so I figured I'd try something to see if it'd work, and being a test environment I wasn't too worried if things went horribly wrong.Here's the steps I took1. Flushed the table I was about to move 2. Placed a read lock on it (even though nothing was writing to it and it wasn't in the replication stream) 3. Copied the .frm and .ibd over to a filesystem w/ some spare room 4. Unlocked the table 5. Truncated that table - this freed up enough space for the optimize to finish have replication start chugging along again. 6. Stop slaving/shutdown mysql 7. Copy the file out of tmp back to the data dir 8. Restart mysql Nothing shows up in the .err log, things look good. I connect and use mydb; and see the table I was messing with in show tables. But, if I tryselect * from testtable limit 10;I get the errorERROR 1146 (42S02): Table 'mydb.testtable' doesn't existFrom what I can tell so far I can read from all the other tables just fine and replication started back up w/o any complaints.Is there anything I can do to recover from this point? I can rebuild it from scratch if need be but was curious what others thought about this venture in general. Was there anything about the series of steps I took that would have ended up w/ more flawless results? What if this wasn't a test server I couldn't just 'do it live' and see what happens? What would have the best way to free up space temporarily on a production slave if I had to like that?

The biggest thing most people forget about TRUNCATE TABLE is that TRUNCATE TABLE is DDL and not DML. In InnoDB, the metadata within ibdata1 contains a numbered list of InnoDB tables. Using TRUNCATE TABLE causes the internal metadata id of the InnoDB table to shift. This happens because TRUNCATE TABLE effectively does the following:Example: To truncate an InnoDB Table called mydb.mytbUSE mydbCREATE TABLE newtb LIKE mytb;ALTER TABLE mytb RENAME oldtb;ALTER TABLE newtb RENAME mytb;DROP TABLE oldtb;The new mytb would thus have a different internal metadata id.When you copied the .ibd file to some other place, the .ibd contains within it the original internal metadata id. Simply putting the .ibd file back does not cause a reconciliation of the internal metadata id with that of the one in ibdata1.What you should have done is this:Copy the .ibd file of the InnoDB table. Then, run thisALTER TABLE tablename DISCARD TABLESPACE;To bring it back later on, copy the .ibd file back into datadir and then runALTER TABLE tablename IMPORT TABLESPACE;This would have preserved the internal metadata id.Make sure .frm is always present.I once helped a client restore 30 InnoDB tables he hosed in the same manner. I had to use another DB server and play some games with adding and dropping InnoDB tables to hunt down the correct internal metadata id.The biggest thing most people forget about TRUNCATE TABLE is that TRUNCATE TABLE is DDL and not DML. In InnoDB, the metadata within ibdata1 contains a numbered list of InnoDB tables. Using TRUNCATE TABLE causes the internal metadata id of the InnoDB table to shift. This happens because TRUNCATE TABLE effectively does the following:Example: To truncate an InnoDB Table called mydb.mytbUSE mydbCREATE TABLE newtb LIKE mytb;ALTER TABLE mytb RENAME oldtb;ALTER TABLE newtb RENAME mytb;DROP TABLE oldtb;The new mytb would thus have a different internal metadata id.When you copied the .ibd file to some other place, the .ibd contains within it the original internal metadata id. Simply putting the .ibd file back does not cause a reconciliation of the internal metadata id with that of the one in ibdata1.What you should have done is this:Copy the .ibd file of the InnoDB table. Then, run thisALTER TABLE tablename DISCARD TABLESPACE;To bring it back later on, copy the .ibd file back into datadir and then runALTER TABLE tablename IMPORT TABLESPACE;This would have preserved the internal metadata id.Make sure .frm is always present.I once helped a client restore 30 InnoDB tables he hosed in the same manner. I had to use another DB server and play some games with adding and dropping InnoDB tables to hunt down the correct internal metadata id.QUESTION #1Are the tables of all databases in the server locked during the mysqldump?ANSWER TO QUESTION #1Depends on the default settings you allow and what setting you use to override. The --opt parameter is enabled by default. That enables --add-drop-table, --add-locks, --create-options, --quick, --extended-insert, --lock-tables, --set-charset, and --disable-keys. If you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can just use --single-transaction. This will create a clean point-in-time snapshot of all tables involved in the mysqldump. Any INSERT/UPDATE/DELETE queries against an InnoDB table will not interfere with the point-in-time consistency of the mysqldump.By the way, --single-transaction is mutually exclusive to --lock-all-tables. Thus, using --single-transaction will disable --lock-all-tables.QUESTION #2If I have to do an incremental backup using mysqlbinlog from the last full backup, should I take the time when mysqldump started or when it ended?ANSWER TO QUESTION #2You could take the time if you do mysqlbinlog at different times of the day. You could save yourself some off that housekeeping information by simply running FLUSH LOGS; or FLUSH BINARY LOGS; the same time every night. For example, you could script a cronjob to run FLUSH LOGS;at 11:59 PM like this#!/bin/shsleep 55mysql -uroot -p... -e"FLUSH LOGS;"That way you can logically group together all binary logs that have the same date when formulating any needed incremental backup.You do not have record times or positions in this respect: If you include the option --master-data=2 in the mysqldump, the log file and position at recorded as a comment on line 22 of the mysqldump output.QUESTION #3What happens when one is using the database when mysqldump is running? How can I take the start time for mysqlbinlog? What happens when mysqldump is executed?ANSWER TO QUESTION #3Here is where you have to be very careful. As I mentioned earlier, if you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can use --single-transaction and every table involved in the mysqldump will exist in the same point-in-time. What Can Go Wrong #1If you are performing INSERT/UPDATE/DELETE queries against a MyISAM table during the mysqldump, then the MyISAM tables will not be point-in-time consistent. What Can Go Wrong #2If you are performing ALTER TABLE, DROP TABLE, RENAME TABLE, or TRUNCATE TABLE against any table (MyISAM or InnoDB), consistent mysqldumps are no longer isolated. The transaction you issued with --single-transaction is released (made null and void) and all tables afterward can no longer the point-in-time consistent.If one of these occur, recording start times or position is rendered useless.