I had a problem with our InnoDB database. I tried the
innodb_force_recovery = 4
option in /etc/my.cnf
MySQL can't be used but runs at 100% CPU. Is it normal? Does it try to recover, or I waste my time waiting for the process to stop using 100%?
It runs since 17 minutes now, the ibdata1 file is about 6Gb.
Thanks!
Don't stop on innodb_force_recovery = 4 , try values 5 and 6.
Check the error log too. If it prints something like "Waiting to start purge thread" then add innodb_purge_threads=0 to my.cnf
Then dumps all databases with mysqldump and reload into the fresh mysql instance
Related
I have configured the database using SET GLOBAL binlog_expire_logs_seconds = 259200; query to purge binary logs older then 3 days. Using MySQL 8.0.22. This does not seem to have any effect. bin logs are accumulating under /var/lib/mysq/dbname-bin.000xx files. Executing
PURGE BINARY LOGS BEFORE '2020-.......'
works, but I would like the DB engine to purge those logs on its own without myself calling it. Otherwise binlogs take most of the disk space. Please suggest.
I had the same problem (but on Windows 10), I edited my.ini located in c:/xampp/mysql/bin and added the following:
binlog_expire_logs_seconds=60
Does this work for you?
I asked this on the MySQL forums, but didn't get any replies:
I've been manually running "PURGE BINARY LOGS TO" to purge the binary logs of a master DB for over a year now (1 slave DB on a different machine). After my most recent purge, over the next few hours, it generated a huge amount of logs - about 8 files of 1 GB each. Normally, it would take days before one 1GB file would be created. I did another purge that day and restarted mysql and it has returned to normal. What could have caused this? Is there anything I should be concerned about right now?
I can't remember the exact number of the purge command and it is now gone from history since I restarted mysql, but I think it was:
PURGE BINARY LOGS TO 'mysql-log.000101';
Thanks for any insight into this.
We have noticed that we run out of space on one of our machines that is running Mysql 5.5.37 (InnoDb)
Mysql seems to be generating several ~1.1GB files per day with the name pattern 0.0001234 (increasing number) in the /var/lib/mysql folder.
What are those files?
Can they be deleted?
Can we configure mysql to write them to a different location?
To avoid having to do the purge periodically, set this:
expire_logs_days = 7
in my.cnf. That will keep the binlogs purged down to 7 days' worth.
See also binlog_expire_logs_seconds in MySQL 8.0.
Turns out these were binlogs.
The setting log_bin=0
does not disable them but simply sets the file-name-format to 0.\d+
We deleted the present logs with PURGE BINARY LOGS to 'lastFileName', then disabled the generation by commenting out all bin_log related entries in the my.cnf.
I have a C# application performing some database operations on a MySQL 5.7 server. Once the complete system hunp up and I had to hard-reset it. When it comes to a specific table read/write operation now the database server crashes. The windows log shows
InnoDB: Trying to access page number 286720 in space 29,
space name myInstance/myTable, which is outside the tablespace bounds.
Byte offset 0, len 16384, i/o type read.
I tried to use mysqlcheck --repair but it fails because note : The storage engine for the table doesn't support repair.
I've read some advices that say I should start MySQL in a recovery mode, so I added
[mysqld]
innodb_force_recovery=4
to the my.ini config file whereupon I should be able to use mysqldump to export the affected database table. But unfortunatelly I am not.
mysqldump: Error 2013: Lost connection to MySQL server
during query when dumping table `myTable` at row: 1246
Edit:
I checked the error log again and found lots of entries saying
[ERROR] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe:
The table 'myTable' is full
I'm running the server on a Windows 32bit OS with an NTFS formatted partition. The myTable.ibd file size is around 4.5 GB, checking C.10.3 Limits on Table Size states a file size limit of "2TB (possibly larger)" for Win32 w/ NTFS.
While checking the reasons for my error the only possible cause I found was a full InnoDB tablespace. The solution might be "Changing the Number or Size of InnoDB Redo Log Files" although the coherence is a bit vague to me. Nevertheless I increased the size of the Redo Log Files from 48M to 100M. But nothing changed.
If I perform a SQL select * from myTable order by Id desc the server crashes instantly. Error log entry is exactly the same as above.
I checked the chapter 15.7.1 Resizing the InnoDB System Tablespace as well and found out that innodb_data_file_path is not explicitly specified.
Any ideas what I can do now? Thanks a lot!
InnoDB cannot repair corruption in tablespaces. This was never implemented and mysqlcheck won't help in any way.
The corruption is in space id 29 which is table myInstance.myTable. To repair it you need to dump all records from this table with innodb_force_recovery. Try all values from 4 to 6 until MySQL doesn't crash. Then drop the table and reload the dump.
If MySQL crashes even with innodb_force_recovery=6 then restore the table from backup.
If you don't have backup - use script http://bazaar.launchpad.net/~percona-dev/percona-data-recovery-tool-for-innodb/trunk/view/head:/fetch_data.sh . It will fetch as many records as it can.
One possible cause could be that the ib_logfile* files are corrupted.
To fix this, remove these files using rm ib_logfile*.
Where are these files?
These files are in mysql datadir. The location of datadir depends on the OS. Check my.cnf, in osx that should be in /usr/local/etc.
I have a backup from two weeks ago that will be a last resort, but the DB files themselves seem fine and it appears it's just the ibdata1 file that is having issues. As stated, I'm using Xampp and MySQL crashes right after I start it. Here is the error log: http://textuploader.com/7vfd
I hadn't done anything out of the ordinary; it seemingly just up and stopped working.
I looked up InnoDB recovery, but the solutions I tried required MySQL to be functional, which it isn't due to the corruption. Is there a way to salvage what are presumably intact IBD files with a bad ibdata1 file?
Edit: I was aware of using innodb_force_recovery = # and I had tried it...except I had tried it in the wrong my.ini. I had to use the one in the bin folder. It appears to be fixed now.
The ibdata1 file contains the tablespace information and other metadata about your Mysql database(s).
You can try using the innodb_force_recovery = 1 all the way to innodb_force_recovery = 6 to see if that rectifies the problem. Try changing this in your my.cnf (my.ini for windows) file and then attempt to restart your mysql server again.
If you are able to start Mysql using recovery flag, your database will be in a read-only mode. You should do a mysqldump of the data, stop mysql, re-install fresh, create your database again, and import back in the data.
Here is a link for more info on innodb recovery dev.mysql.
If you use linux...
Another more complex option is to use percona recovery tool kit. This will realign your tablespaces. Although, from experience its a bit of a challenge to navigate and takes a bit of time to implement if you are a newb.
However, akuzminsky the creator of the toolkit (how cool is that!) mentioned that he has made significant improvements to the toolkit.
Link to download toolkit Percona.com
Link with a walkthough from chriSQL.
Link to akuzinsky's website TwinDB.
Unless that data is mission critical, I would just revert back to the backup from 2 weeks prior. The amount of time and effort you may end up putting into recovering this data may out way the benefit.
In my case, the mysql.ini didn't have the innodb_force_recovery option.
So i added it to the file and the start was able to start normally
The location to the ini file for my case was
C:\xampp\mysql\bin\my.ini
innodb_force_recovery = 1
For my case, the data got corrupted after a disk check up by windows. In the due course, the database got corrupted.
Hope this can as well help someone out there.
on my case using xampp v3.3.3, i enable innodb_force_recovery = 6 in the top of my.ini configuration file and start the service from xampp dashboard.
also i clean up log, disable innodb_force_recovery = 6 and start again. it works like a charm