When trying (InnoDB):
DROP DATABASE mydatabase;
I almost inmediately get:
ERROR 2013 (HY000): Lost connection to MySQL server during query
I checked the timeouts and they are far enough from being short (600 seconds) so I stopped MySQL, removed mydatabase folder and started MySQL again. Then I re-created my DB and loaded it from a dump:
mysql -u <user> -p mydatabase < Dump.sql
But the process failed once and again due to some already existing table (though I'm sure it is not duplicated in the dump file), so at this point I don't really know what to do and whether I'm facing some InnoDB corruption issue (logs do not show anything related).
Any thoughts?
So finally, as (credits go for him) #t.niese's link points out, I quit trying to drop the (corrupted) DB and ended up recovering the dump into another DB, just changing its name. Fortunately I didn't need to have the same name, so I skipped the long process pointed out at that link. But alas it seems the corrupted database will stay in the ibdata1 file.
Related
I really need help with a mariadb crash. Earlier today mariadb stopped working. i tried various things to get back with mariadb until i moved ib_logfile0 ib_buffer_pool to another location and so i was able to start mariadb but all database users seem to have lost permission.
I thought at the time that ibdata1 might be corrupted.
I changed mysql root password because I didn't have mariadb root access but all database users lost access to the database.
i tried to make a backup of all databases "mysqldump -u root -p -A > mydb.sql" but i get the error
"Table 'crmidentiq.tblactivity_log' doesn't exist in engine" when using LOCK TABLES
I'm out of ideas on how to solve this problem and repair users' permission.
Can someone help me?
Check and fix tables mysql.global_priv (for new mariadb versions) or mysql.users (for old versions) , these 2 tables contain your credentials
I tried using the mysql pump to create a backup of my MySQL database. When I tried to restore the backup to another server I am getting the error mentioned in the title. I know that question with this error has been asked before but all answers state that I need to delete the definer clause from the .sql backup file. However, I do not have a definer word at all in my backup file because I backed up my database doing:
mysqlpump --skip-definer -u root -p testempty > c:\users\admin\documents\dumps\backup.sql
I searched trough the backup file and there is absolutely no definers at all.
However, the problem is that I am trying to backup and restore to a different database name and my sql contains database1.tableName syntax. I am trying to restore to database2
That might be the reason for the problem. I know that if I was using mysqldump instead of mysql pump I could do:
mysqldump -u root -p testempty > c:\users\admin\documents\dumps\backup.sql
which exports without database name
but mysqldump does not provide skip definer option :(
Why is it such a nightmare to backup and restore mysql database and so easy to do it in MSSQL database? I am trying to streamline my backup and restore process and there are roadblocks everywhere.
I downloaded the database, edited it with notepad++ and after that I deleted "Definer = your username # local host" and it worked for me.
Ok, so I had a very large (40GB) database containing 1 table. I went to the Windows MySQL command prompt and typed:
drop database very_large_db;
I waited a few minutes and it came back with an error. I'm sorry but I forgot to record the error number. It then tried to reconnect and was unable to re-connect to the MySQL command prompt. I then rebooted the computer, went back to the command prompt, and tried to drop the database again. At this point, it just kicked me out and the MySQL service stopped (verified in services.msc). Next, I decided to go to the MySQL data directory in Windows Explorer and manually delete the database directory. It deleted no problem, and when I perform a "show databases;" command in the MySQL command prompt, it is no longer there.
Is there anything else I need to do to make sure the database was properly deleted? Is there any chance I corrupted any other databases in MySQL?
Thanks
Deleting the directory is equivalent to DROP TABLE. Try this: create a sub-directory in data and run 'SHOW DATABASES;' you'll see that MySQL just considers the directory to be a database.
I want to copy the database tables from my production server to a local test machine so I can perform test om (copies of) the real data.
I stopped mysql and deleted all the frm, MYD and MYI files. Starting mysql here and querying show tables gives an empty result set. I then shut down mysql and copied all the frm, MYD and MYI files from the server. When starting mysql "show tables" shows the tables as expected but trying to query them I get the error message
ERROR 1017 (HY000): Can't find file: './WhateverTableIQuery.frm'
(errno: 13)
But the WhateverTableIQuery.frm file is on the disc and is identical to the one on the server.
Any ideas about what might be the problem?
I'd suggest giving two things a try:
1. Check Permissions
Make sure that your MySQL data directory and all the files in it are owned by mysql user and mysql group. This may not be the case if you copied the files onto your local test machine as root user:
chown -R mysql:mysql your-mysql-data-dir-here
2. Repair corrupted tables
Use mysqlcheck to check for corrupted tables and repair them if it finds any:
mysqlcheck -u root -p --auto-repair --all-databases
If you still can't use the tables after that then give mysqldump a go!
I encountered the same issue after restoring a MySQL database with frm and MYD files. After a number of hours spent I observed that I have configured the database directory with only read and write permission to mysql user but not execute permission. After adding execute permission to the database directory, the problem was solved.
I did have the very same issue a couple minutes ago and it took me a few minutes to realize that I had insufficient permission to access the .sql file I wanted to import.
In order to get rid of this problem you could just move the file to a place you know you have access to (with your current user) for sure. (eg. ~/Home_directory).
I hope I could help some lonely soul that was searching for the answer just like I was.
I had the same issue and did this...
Delete Migrations Folder
Drop the _migrationhistory table
Enable, Add and Update migration
I'm sure there's a much better way to solve this but, it worked for me.
I changed permissions for the mysql-data-directory as well as the <table>.frm file.
If using as root user:
chmod 600 mysql-data-directory chmod 600
mysql-data-directory/tableOfData.frm
If using as non-root user:
chmod 660 mysql-data-directory
chmod 660 mysql-data-directory/tableOfData.frm
This error, "General error: 1017 Can't find file", also happened on Windows with WAMP if the table doesn't exist.
Try following things:
repair whole database
change permission to mysql:mysql
restart mysql service
One of these will work.
I imported a large mysql database using
mysql -uroot -ppassword dbName
the database has gone away during the process possibly due to timeout after a few days...
is there a way to resume it? or am I out of luck and need to delete the existing db and reimport?
It might help to use a "--ignore" option on the commandline, to "resume" the import.
The semantics is that it should ignore any already imported data and only import what's not yet there.
Here's the MYSQL documentation for the ignore option:
http://dev.mysql.com/doc/refman/5.0/en/mysqlimport.html#option_mysqlimport_ignore
I'm using INSERT IGNORE INTO by stream editing (sed) my dump file like this:
nice gunzip < dumpfile.sql.gz | sed -e "s|^INSERT INTO |INSERT IGNORE INTO |g" | nice mysql -uroot -p"password" DBName
If you know the last insertion point on your query, split your mysqldump file to just before that point, and replace insert with insert ignore. You probably don't want to insert ignore the whole dataset, as each transaction is attempted.
Also, mysql server has gone away can also be indicative of violating max_allowed_packet size.
The "database has gone away" is usually indicative of the server crashing, check your mysql logs /var/log/mysqld.log or if not there run;
SELECT * FROM GLOBAL_VARIABLES WHERE VARIABLE_NAME = 'LOG_ERROR';
I've never had a client disconnect, even in week long runs over the network. It looks like your connecting locally so a disconnect is very unlikely.
If you want to resume, you can do the following;
Check the error log to see the cause of the error and fix this first
Grep the dump file; grep -irH 'DROP TABLE'
Compare the tables restored to the grep results; note the line of the last match
Create a new file from the last matched db (inclusive); tail --lines=+10000 database.sql > resume.sql
OR; as someone else stated, use the ignore-lines option in mysqlimport
Hope this helps