While importing from sqldump, the following error is encountered.
ERROR 1812 (HY000) at line 753: InnoDB: A general tablespace named TABLESPACE_NAME cannot be found.
Used the following following command to import and export.
Export: mysqldump -h $DB_HOST -u$DB_USER -p$DB_PASSWORD --complete-insert --routines --triggers --single-transaction "$dbname" > "$dbname".sql
Import: mysql -h $server -u $user -p$password $dbname < $sql;
The same scripts created dump with no (TABLESPACE definitions) when dump against one of the other database servers while the one in AWS (RDS 5.7) resulted in dump with TABLESPACE definition.
Currently, dump should be exported from mysql 5.7 to mysql 5.7 running as docker container.
Should the definition be excluded while dumping or the definition be excluded while importing? Either ways, I need help from DB experts about command options to import such a database.
After some research and tests, this is what my understanding is.
When databases are created with tablespaces, mysqldump does not include the tablespace definitions. There is no option with mysqldump to ignore tablespace references. So, I had two options after taking dump.
1. Edit the dump manually and remove the references to tablespace.
2. Create the tablespace before importing the dump.
I had a luxury to import into a server that was running as container. So, mysql listed all the tablespaces that were not available (After such error reported, I could throw away the mysql container and start another one - to feel that the server is fresh). Since I knew all the tablespaces, I went with the second option and also thought that editing the dump created by tool (mysqldump) is not a good idea.
Used the following statement to create tablespace
create tablespace <tablespace-name> add datafile 'tablespace-name.ibd'
This approach worked for me.
I had the same problem. I wasn't able to create the tablespace on the db because it was shared hosting and required server admin privileges to do so, but I was able to use the generated error code to find the textual reference to the tablespace in the dump file. It is consistent every time, so a simple find and delete search took care of the whole file, and then the transaction completed with no errors.
Related
I'm trying to get dump of my database:
mysqldump myDatabase > myDatabase.sql
but I'm getting this error:
mysqldump: Got error: 1146: Table 'myDatabase.table' doesn't exist when using LOCK TABLES
When I go to mysql:
mysql -u admin -p
I query for the tables:
show tables;
I see the table. but when I query for that particular table:
select * from table;
I get the same error:
ERROR 1146 (42S02): Table 'myDatabase.table' doesn't exist
I tried to repair:
mysqlcheck -u admin -p --auto-repair --check --all-databases
but get the same error:
Error : Table 'myDatase.table' doesn't exist
Why I'm getting this error or how can I fix this error?
I'll really appreciate your help
For me the problem was resolved by going to /var/lib/mysql (or wherever you raw database files are stored) and deleting the .frm file for the table that the errors says does not exist.
I had an issue with doing mysqldump on the server, I realized that tables that if that tables were not used for longer time, then I do not need those (old applications that were shutdown).
The case: Cannot do backup with mysqldump, there are tables that are not needed anymore and are corrupted
At first I get the list of corrupted tables
mysqlcheck --repair --all-databases -u root -p"${MYSQL_ROOT_PASSWORD}" > repair.log
Then I analyze the log with a Python script that takes it at stdin (save as ex. analyze.py and do cat repair.log| python3 analyze.py)
#!/usr/bin/env python3
import re
import sys
lines = sys.stdin.read().split("\n")
tables = []
for line in lines:
if "Error" in line:
matches = re.findall('Table \'([A-Za-z0-9_.]+)\' doesn', line)
tables.append(matches[0])
print('{', end='')
print(",".join(tables), end='')
print('}', end='')
You will get a list of corrupted databases.
Do an export with mysqldump
mysqldump -h 127.0.0.1 -u root -p"${MYSQL_ROOT_PASSWORD}" -P 3306 --skip-lock-tables --add-drop-table --add-drop-database --add-drop-trigger --all-databases --ignore-table={table1,table2,table3 - here is output of the previous command} > dump.sql
Turn off the database, move /var/lib/mysql to /var/lib/mysql-backup, start database.
On a clean database just import the dump.sql, restart database, enjoy an instance without corrupted tables.
I recently came across a similar issue on an Ubuntu server that was upgraded to 16.04 LTS. In the process, MySQL was replaced with MariaDB and apparently the old database couldn't be automatically converted to a compatible format. The installer moved the original database from /var/lib/mysql to /var/lib/mysql-5.7.
Interestingly, the original table structure was present under the new /var/lib/mysql/[database_name] in the .frm files. The new ibdata file was 12M and the 2 logfiles were 48M, from which I concluded, that the data must be there, but later I found that initializing a completely empty database results in similar sizes, so that's not indicative.
I installed 16.04 LTS on a VirtualBox, installed MySQL on it, then copied the mysql-5.7 directory and renamed it to mysql. Started the server and dumped everything with mysqldump. Deleted the /var/lib/mysql on the original server, initialized a new one with mysql_install_db and imported the sql file from mysqldump.
Note: I was not the one who originally did the system upgrade, so there may be a few details missing, but the symptoms were similar to yours, so maybe this could help.
When i just write "mysql" in bash - it show only 2 databases.
When i write mysql -u root -p and then enter password - 2 more db occur.
Why is it happening?
+ bonus question: i backed up "data" directory from previous mysql installation, which crashed.
How to restore tables from .ibd and .frm files?
mac os 10.9
Why is it happening?
As documented under SHOW DATABASES Syntax:
You see only those databases for which you have some kind of privilege, unless you have the global SHOW DATABASES privilege.
Presumably the account under which you connect to MySQL when no explicit credentials are provided (i.e. as set in the relevant option file) only has permission to see two of your databases.
How to restore tables from .ibd and .frm files?
See Copying Tablespaces to Another Server (Transportable Tablespaces). If the files are in the server's data directory, you can use IMPORT TABLESPACE:
ALTER TABLE tablename IMPORT TABLESPACE
I'm using the following command to create an incremental backup in MySQL
mysqldump -uusername -ppassword db_name --flush-logs > D:\dbname_incremental_backup.sql
However the sql file is as big as a complete backup, and obviously importing it takes a long time as well. Could anybody tell me how to create incremental backups and import just the new data from each incremental backup rather than the whole database again?
I have read all the related articles in dev.mysql.com but still can not understand how to do it.
mysqldump only creates full backups. There's no built-in functionality for incremental backups.
For that sort of thing you probably want Percona xtrabackup but that will only work with InnoDB tables. This is usually not an issue since using MyISAM tables is considered extremely harmful.
By default a mysql dump will drop tables making an incremental update impossible. If you open up the resulting file, you will see something like:
DROP TABLE IF EXISTS `some_table_name`;
You can create a dump without dumping and creating new tables using the --no-create-info option. To make your dump friendly to incremental imports, you should also use --skip-extended-import which will break inserts out into one insert statement per row. Combined with using --force on the import will mean that inserts for rows that exist will fail but the import will continue. You will end up seeing errors in the logs for rows that already exist, but new rows will be inserted as desired.
You should be able to export with the following command (I also recommend not typing the password in the command so that it won't appear in your history)
mysqldump -u username -p --no-create-info --skip-extended-insert db_name --flush-logs > D:\dbname_incremental_backup.sql
You can then import with the following command:
mysql -u username -p --force db_name < D:\dbname_incremental_backup.sql
I've exported a mysqldump of a database with InnoDB tables and foreign key relationships in them, using the --single-transaction flag (that I read somewhere I should use for InnoDB). No problems.
But when trying to import that dump into another existing database (same database, different server) I get all sorts of errors when trying to drop the tables because it would break the InnoDB relationships.
I also read that I should use foreign_key_checks=0 to avoid this, but this is a server variable, not part of the dump process. So I'm trying to figure out how to automate all this since I have a script that backs up the DB, it was working when all we had were MyISAM tables:
mysqldump -u user -p'password' --single-transaction -q database | ssh user#backup.com mysql -u user -p'password' database
Thanks.
You can dump into a file, add the required SET FOREIGN_KEY_CHECKS=0; in that file, and then feed the file to mysql.
It turns out that the mysqldump file is smart enough to detect that they are InnoDB tables and puts the appropriate comments at the top of the file. My problem was that when I exported through PHPMyAdmin it didn't put the correct comments on the file, hence causing all this trouble.
Thanks for your response.
You can also add to the mysql command line when restoring without editing the original file. This is very useful as mysql backups can become huge, and editing a GB+ file takes lots of CPU time versus adding this to the commandline,
mysql -D YourDatabaseName -u YourUserName -p --init-command="set ##foreign_key_checks=0"<YourBackupDumpFile.sql
I know, it is really sad trying to export a database just by copying the data folder! But I have a hard disk with an important database inside and I don't know how to export this database onto my actual system (winxp - mysql 5.0.37).
So, i've copied old_harddisk/program/mysql/data/coge2010 to mypc/programs/mysql/data/coge2010
Result:
I see cogemilla (4) on my phpMyAdmin databases summary (it's correct!!! my 4 tables!)
If I click the database, I see just 1 table (oh no!)
On the mysql error log file I find messages like this one: "...[ERROR] Cannot find table coge2010/soci from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? See http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html how you can resolve the problem."
Any ideas?
You should create a dump and import it on the new server.
In Command Prompt type the following to create the dumpfile:
mysqldump -h host -u user -p databaseName > dumpFile.sql
To import the database :
mysql -h host -u user -p databaseName < dumpFile.sql
You can only copy InnoDB tables if:
1. Your database is stopped.
2. You copy all InnoDB files (ibdata* ib_logfile* /*.ibd
You could use dump/restore to copy a single table.
You could user 'ALTER TABLE sometable ENGINE=MyISAM' to convert it to MyISAM and then copy the MYI,MYD and FRM.
Percona XtraBackup can do single table restores if you're using Percona Server.
This post may help you.
Another post which may help you.
A mysql table is defined by 3 files (FRM/MYD/MYI). In your case the FRM file is missing into the database folder.
If you can run the mysql server of the old hard disk it is easier to do a dump of your database. The following link shows you how to do this