I wanna restore my dump file (created with mysqldump)if i restore my dump file into my table,my old data in my table will remove ?
or dump file add to old data?
By default DROP TABLE IF EXISTS tablename statements are generated and placed before each CREATE TABLE ... statement. You can simply look into your dump file, it's plain text (if not compressed), and see if there are similar lines.
If those statements are there, your data will get deleted and then freshly inserted.
If they are not there, you will most likely generate errors by restoring your dump, since duplicate primary keys collide. So usually you will want to go for above mentioned statements.
Related
I am having a simple (I think) problem.
I am having a dump of MySQL database before disaster.
I need to import and replace from this dump only three columns from single table (in over 5000 rows, so that's why I am aware of doing it manually).
What should I do to do it and do not destroy anything else in working database?
I am just thinking that there is an option to skip columns during import and replace (UPDATE command I think) only these I need.
I will be thankful for help :(
------------ UPDATE ---------------
Okay, I used PHPMyAdmin and first I used SELECT query to get only three columns from whole table. Then I dumped it and I have SQL file with a dump containing only three columns.
Now, having this dump, can I (I do not know how to name it) edit or change something inside this typical MySQL dump file to make it possible to import these three columns with replace all the existing values?
I mean - to make existing column empty, then use maybe "INSERT INTO" but to whole table?
It is just over 2600 rows and I can not change it manually, so it would be better do use automation.
As far as I know, this is not possible. You can try to use sed in order to extract only the table you want - but specifically 3 columns would be complicated if not impossible.
Can I restore a single table from a full mysql mysqldump file?
The best way would be as #Ali said and just import it to a temp DB and then export the required data/columns to a new dump.
Restore DB to temp db then:
mysql> CREATE TABLE `tempTable` AS SELECT `columnYouWant` from `table`;
$> mysqldump yourDB tempTable > temp.sql
// Since you updated the question:
You want to probably use REPLACE INTO with your dump with the --replace option - though this will delete the row and replace it, not just the individual columns. If you want just the individual columns, the only way I can think of is with UDPATE. To use UPDATE, your options are:
Multi-table update
UPDATE mydb.mytable AS dest JOIN tempdb.mytable AS origin USING (prim_key)
SET dest.col1 = origin.col1,
dest.col2 = origin.col2,
...
Then drop the temp database.
Search/Replace Dump
Take your dump and use the INSERT ... ON DUPLICATE KEY UPDATE option to add it to the end of each insert line (assuming you exported/dumped individual insert commands).
I have MySQL running on SSDs, SSDs that I'm about to run out of space on. My webhost overcharges for SSDs and the majority of the data in MySQL is "archived" data (i.e. data that isn't actively used). I have larger HDDs that can hold this data. As such, I want to be able to move specific InnoDB tables from the SSDs to the HDDs.
One solution I've thought about and researched is moving the individual .ibd files (I have innodb_file_per_table enabled) for the specific tables in question to the HDDs and then symlink. However, researching this, it looks like that is a bad idea for InnoDB.
I've also seen that since 5.6, MySQL supports the DATA DIRECTORY command:
To create a new InnoDB file-per-table tablespace in a specific
location outside the MySQL data directory, use the DATA DIRECTORY =
absolute_path_to_directory clause of the CREATE TABLE statement.
Plan the location in advance, because you cannot use the DATA
DIRECTORY clause with the ALTER TABLE statement. The directory you
specify could be on another storage device with particular performance
or capacity characteristics, such as a fast SSD or a high-capacity
HDD.
The problem is, it looks like this is only supported for new tables. I want to do it for existing tables. Any tips on how? I'm running Percona MySQL, if it helps.
Thanks!
UPDATE: Here is what I tried, but I'm getting a syntax error:
CREATE TABLE abc_2 LIKE abc ENGINE=InnoDB DATA DIRECTORY='/xxx/mysql/archive/'
Apparently CREATE ... LIKE ... DATA DIRECTORY ... is a combination that is not supported.
Do SHOW CREATE TABLE to get the current definition. Edit it to add DATA DIRECTORY and INDEX_DIRECTORY. Then use the edited text to create the new table.
Then INSERT INTO new_tbl SELECT * FROM real_tbl; and shuffle the names: RENAME TABLE real_tbl TO old_tbl, new_tbl TO real_tbl;.
Verify the results and finally DROP old_tbl;
I have dealt with this problem myself, and eventually found a more elegant solution than 'create new - copy - switch': detaching, moving and re-importing the underlying tablespace files. This is much more efficient on large and/or heavily indexed tables as MySQL does not have to redo work it has already done.
In short, it comes down to the following steps:
FLUSH TABLES `table_name` FOR EXPORT;
While keeping the connection open, move the tablespace files in a shell:
$ mv /var/lib/mysql/database_name/table_name.{ibd,cfg} ~
Now back in MySQL release the lock, drop the table, re-create it with the correct DATA DIRECTORY and discard its tablespace:
UNLOCK TABLES;
SHOW CREATE TABLE `table_name`;
DROP TABLE `table_name`;
CREATE TABLE `table_name` /* ... */ DATA DIRECTORY='/path/to/desired/location';
ALTER TABLE `table_name` DISCARD TABLESPACE;
Now copy the moved tablespace files to the desired location:
$ cp -a ~/table_name.{ibd,cfg} /path/to/desired/location
And import them:
ALTER TABLE `table_name` IMPORT TABLESPACE;
More background and motivation for why 'create new - copy - switch' is inefficient can be found in a blogpost I wrote on this topic: https://www.moxio.com/blog/28/moving-individual-mysql-tables-on-disk.
Let's say I have an old .SQL dump and since it was created, I have changed the table schema.
I could be running:
INSERT INTO `ec_product_campaign_relations` (`campaign_id`, `product_id`, `product_qty`) VALUES (30,28,1),(30,27,0),(30,31,0),(30,30,0);
But if column product_qty does no longer exist, the line will not get inserted.
How can I force the line to get inserted anyways and ignore that the column does not exist?
EDIT: It should mention I'm working in PHP and it is script used to sync table shema... So no "manual" control over this.
Since editing all your SQL dump won't be trivial, I suggest you to add the column to your table, make the import, then delete the column.
You might want to create a new database for this import and restore the dump as-is. Then, once you've got a handle on what changes have been made by comparing the schema in one to the new one, create a series of ALTER TABLE statements that bring it in sync.
I tend to record these in a text file in case I need to replay them later, and also keep them as a list of what's changed. You may have to do this more than once, so notes help.
Then, once you've cleaned them up to be column-compatible, dump this database table-by-table, and restore into the other as required.
I have a mysql table y in database xxx which I attempted to change compression type before using
alter table y row_format=compressed key_block_size=8
the process stopped half way. I removed temp file '#sql-ib265.frm and #sql-ib265' in mysql lib directory and restarted the server. However
Now when I attempt the alter table y (with the same command above) again I get error.
ERROR 1050 (42S01) at line 1: Table 'xxx/#sql-ib265' already exists
I can't drop table 'xxx/#sql-ib265' because it can't be found.
what should I do?
Edit
Solution:
I ended up dropping the old database and recreate the database.
Try to restart mysql client with the --skip-auto-rehash option and try DROP TABLE again.
If above does not work, try this from MySQL Manual:
You have a corrupt innodb data dictionary..
https://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html
Problem with Temporary Table
If MySQL crashes in the middle of an ALTER TABLE operation, you may end up with an orphaned temporary table inside the InnoDB tablespace. Using the Table Monitor, you can see listed a table with a name that begins with #sql-. You can perform SQL statements on tables whose name contains the character “#” if you enclose the name within backticks. Thus, you can drop such an orphaned table like any other orphaned table using the method described earlier. To copy or rename a file in the Unix shell, you need to put the file name in double quotation marks if the file name contains “#”.
There are two ways to fix this problem.
As other answer suggests, official MySQL documentation suggests to drop a specially crafted table. But please note in versions >= 5.1 you need to prefix table name with #mysql50#.
Move (use RENAME TO) all good tables to a temporary database, drop&recreate the original one and then move the tables back. See a blog post for details.
in additional I'm loging in with root to do the recover job but failed. then i chown the .frm file to meet the owner of mysql service and succeed.
For anyone still facing this problem, I have just followed the following steps to solve it, which (to me at least) seem far less daunting than other solutions:
Use mysqldump to back up the database with all its data.
Drop and recreate the database.
Reload the database and all its schema from the file generated in (1).
Because the orphaned tables are hidden anyway, they don't get backed up, so you end up with a database without them. I had all my procedures/functions scripted out anyway, so was able to restore them easily - if you don't, make sure you use the --routines parameter to dump those too.
My dump file was around 1.5GB for the database in question (so it's not small), and the whole thing was completed in a few minutes.
I had the same error. I fixed it by switching the order in which I dropped the tables at the beginning of the file:
DROP TABLE IF EXISTS table_name;
This line is repeated for each table. Tables with foreign keys need to be deleted before the tables with the primary keys to which they point.
I'm doing an update to MySQL Database which includes MySQL scripts that make ALTER TABLE sentences, as well as DIU sentences (delete, insert, update).
The idea is to make a transactional update, so if a sentence fails, a rollback is made, but if I put ALTER TABLE sentences or others specified in http://dev.mysql.com/doc/refman/5.0/en/implicit-commit.html an implicit commit is made, so I can't make a complete rollback, because the indicated operations remains commited.
I tried to use mysqldump to make a backup which is used in case of error (mysql returns distinct to zero), but it is too slow and can fail too.
What can I do? I need this to ensure that future updates are safe and not too slow, because databases contains between 30-100 GB of data.
dump and reload might be your best options instead of alter table.
From mysql prompt or from the database script:
select * from mydb.myt INTO OUTFILE '/var/lib/mysql/mydb.myt.out';
drop table mydb.myt;
create tablemyt(your table ddl here)
load data infile '/var/lib/mysql/mydb.myt.out' INTO TABLE mydb.myt;
Check this out:
http://everythingmysql.ning.com/profiles/blogs/whats-faster-than-alter
I think it offers good guidance on "alternatives to alter".
Look at pt-online-schema change.
You can configure it to leave the 'old' table around after the online ALTER is completed. The old table will have an underscore prefix. If bad things happen, drop the tables you altered and renamed the OLD tables to the original tables. If everything is OK, then just drop the OLD tables.
http://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html