Since i'm not to sure what to do other then what i've seen on here and stackoverflow but i'm getting this error when i startup MySql in WampServer: Semaphore wait has lasted > 600 seconds error. I've tried lowering and raising the values of these variables and this is what i have it set to now innodb_buffer_pool_size = 10M
innodb_log_file_size = 2G innodb_log_buffer_size = 10M in my my.ini config file the only way i've been able to overcome this error was by setting innodb_force_recovery to level 6 but then mysql is in read only mode and i need to create some more tables in my db any suggestions would help thanks
here's the whole error let me know if you need to see more of the log or more variables in my config file
InnoDB: ###### Diagnostic info printed to the standard error stream
2021-02-23T18:25:17.237395Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2021-02-23 13:25:17 0x3a8c InnoDB: Assertion failure in thread 14988 in file ut0ut.cc line 918
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:25:17 UTC - mysqld got exception 0x80000003 ;
everytime I try to backup or check all tables mysql server crashes on Windows server 2012,
I am using XAMPP stack for my development environment.
The database crypto has more then 1100+ tables in DB.
I am including the logs below.
InnoDB: End of page dump
2017-09-24 13:58:35 7dc InnoDB: uncompressed page, stored checksum in field1 2521749199, calculated checksums for field1: crc32 2344073126, innodb 1121903210, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 2344073126, innodb 2892594725, none 3735928559, page LSN 0 2936733816, low 4 bytes of LSN at page end 0, page number (if stored to page already) 34, space id (if created with >= MySQL-4.1.1 and stored already) 1767
InnoDB: page type 17855 meaning INDEX
InnoDB: Page may be an index page where index id is 1522
InnoDB: (index "PRIMARY" of table "crypto"."300-token")
2017-09-24 13:58:35 2012 [ERROR] InnoDB: It is also possible that your operatingsystem has corrupted its own file cache.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: and rebooting your computer removes the error.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: If the corrupt page is an index page you can also try to
2017-09-24 13:58:35 2012 [ERROR] InnoDB: fix the corruption by dumping, dropping, and reimporting
2017-09-24 13:58:35 2012 [ERROR] InnoDB: the corrupt table. You can use CHECK
2017-09-24 13:58:35 2012 [ERROR] InnoDB: TABLE to scan your table for corruption.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about forcing recovery.
2017-09-24 13:58:35 7dc InnoDB: Assertion failure in thread 2012 in file buf0lru.cc line 2394
InnoDB: Failing assertion: bpage->buf_fix_count == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
170924 13:58:35 [ERROR] mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, something is
definitely wrong and this may fail.
Server version: 10.1.22-MariaDB key_buffer_size=16777216
read_buffer_size=262144 max_used_connections=1 max_threads=1001
thread_count=1 It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
787106 K bytes of memory Hope that's ok; if not, decrease some
variables in the equation.
Thread pointer: 0x0 Attempting backtrace. You can use the following
information to find out where mysqld died. If you see no messages
after this, something went terribly wrong...
mysqld.exe!my_parameter_handler() mysqld.exe!my_wildcmp_mb_bin()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlInitializeExceptionChain()
ntdll.dll!RtlInitializeExceptionChain() The manual page at
http://dev.mysql.com/doc/mysql/en/crashing.html contains information
that should help you find out what is causing the crash.
I hope someone will help me out
Thanks.
From this content in your question,
"Server version: 10.1.22-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=1001 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787106 K ...."
with max_threads=1001 clue above - check for max_connections in your my.ini or .cnf. Lowering max_connections to = 100 may or may not help get you past the BaseThreadInitThunk() ntdll.dll!
I'm developing on my laptop with wamp and mysql is running fine from weeks. Today after 60 seconds after boot mysql crashes I and find the following error inside the log:
2016-03-17T20:34:37.662021Z 0 [ERROR] InnoDB: Cannot allocate 4294956804 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b74 InnoDB: Assertion failure in thread 11124 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:34:37 UTC - mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=67108864
read_buffer_size=2097152
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 685380 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x103288c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
2016-03-17T20:34:37.682021Z 0 [ERROR] InnoDB: Cannot allocate 4294954524 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b58 InnoDB: Assertion failure in thread 11096 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
To me it seems that there is a memory issue:
[ERROR] InnoDB: Cannot allocate 4294956804 bytes of memory after 60
retries over 60 seconds. OS error: Not enough space (12).
Could it be that the crash is due to this error? It's weird that mysql try to allocate 4Gb of ram, normally it uses more or less 500Mb.
this is my.ini:
innodb_buffer_pool_size = 16M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
I'm running mysql 32 bit on a win7 64bit.
Is this something I can solve changing some variable?
Thanks very much for your help
It was probably a corruption of the InnoDB data. I added
innodb_force_recovery = 2
to my.ini, restarted the DB and I was able to dump all the data and recover it.
Be aware of using this, read the documentation before: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
I had similar problem on a CentOS VPS and Stefano Giacone's answer is basically what I did so it worked after hours of researching and a lot of stress...
Well the steps were:
1) Find my.cnf file (mine was located in /etc/my.cnf) and add the line:
innodb_force_recovery = X
replacing X with a integer from 1 to 6, starting from 1 and then incrementing if MySQL won't start. Setting to 4, 5 or 6 can delete your data so be carefull and read http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html before.
2) Restart MySQL service. Only SELECT will run and that's normal at this point.
3) Dump all your databases/schemas with mysqldump one by one, do not compress the dumps because you'd have to uncompress them later anyway in 6).
4) Move (or delete!) only the bd's directories inside /var/lib/mysql, preserving the individual files in the root.
5) Stop MySQL and then uncomment the line added in 1). Start MySQL.
6) Recover all bd's dumped in 3).
That worked for me, good luck!
I have been working on a problem for a few days now. Our local mediawiki page that sits on our box account, destroyed itself and we've been working to get it online. Using XAMPP Control Panel v3.2.1, the errors were numerous so we decided to update XAMPP (v3.2.2) and move the 'htdocs' and 'mysql/data' files over to the new data base.
First error:
9:50:21 AM [mysql] Attempting to start MySQL app...
9:50:22 AM [mysql] Status change detected: running
9:50:22 AM [mysql] Status change detected: stopped
9:50:22 AM [mysql] Error: MySQL shutdown unexpectedly.
9:50:22 AM [mysql] This may be due to a blocked port, missing dependencies,
9:50:22 AM [mysql] improper privileges, a crash, or a shutdown by another method.
9:50:22 AM [mysql] Press the Logs button to view error logs and check
9:50:22 AM [mysql] the Windows Event Viewer for more clues
9:50:22 AM [mysql] If you need more help, copy and post this
9:50:22 AM [mysql] entire log window on the forums
As it says, I then went to the logs and found this:
2015-11-20 09:50:22 11f8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-11-20 9:50:22 4600 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-20 9:50:22 4600 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-20 9:50:22 4600 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-11-20 9:50:22 4600 [Note] InnoDB: Memory barrier is not used
2015-11-20 9:50:22 4600 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-11-20 9:50:22 4600 [Note] InnoDB: Not using CPU crc32 instructions
2015-11-20 9:50:22 4600 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-11-20 9:50:22 4600 [Note] InnoDB: Completed initialization of buffer pool
2015-11-20 9:50:22 4600 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-20 9:50:22 4600 [Note] InnoDB: The log sequence numbers 1665234 and 1665234 in ibdata files do not match the log sequence number 50125498 in the ib_logfiles!
2015-11-20 9:50:22 4600 [Note] InnoDB: Database was not shutdown normally!
2015-11-20 9:50:22 4600 [Note] InnoDB: Starting crash recovery.
2015-11-20 9:50:22 4600 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: .\phpmyadmin\pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: .\wiki\archive.ibd
InnoDB: Error: could not open single-table tablespace file .\wiki\archive.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
Now this looks like a standard error that I've seen with many different suggestions throughout the web on how to fix it. I will go over them briefly.
The first thing I tried was to follow the suggestions in the log.
The were no permission problems
It is not clear if I need the table or not, OR whether to get rid of phpmyadmin/pma__tracking or archive.ibd. When I got rid of the archive.ibd, the error just past on to another .ibd file.
'innodb_force_recovery=1' was added to my.cnf and this cause a bunch of errors.
The next thing I noticed is that when we built the new database, I got this error in my phpMyAdmin (localhost/phpMyAdmin):
phpMyAdmin error
I'm not sure if this is causing all of my problems or not. I found that people were saying to switch a password to =''. This error might be happening because I'm entering old data folders in a new database. I'm not sure.
The first suggestion on the web was to remove the following files from
\mysql\data:
innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd
The 2nd:
I've tried removing 'ibdata1'
None of these have worked.
I had the same problem. I tried all the solution others has proposed, and unfortunately nothing worked.
After spending hours on searching for the solution in Google I finally found this
Open my.ini (my.cnf on linux-based systems and Mac)
Look for [mysqld]
Just below [mysqld] insert innodb_force_recovery = 1
Start MySQL Service
Stop MySQL Service
Remove the line from my.ini (innodb_force_recovery = 1)
Start MySQL Service
Worked perfect in my case.
I hope this will solve your problem.
I got the same error. These are the steps I followed.
Took the backup of \xampp\mysql\data
Removed all the files and folders from data folder except mysql
Quit and started the XAMPP again.
Move the databases from data folder one by one.
try to rename /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0 to /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0.bkp
and /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1 to /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1.bkp
Solution is for MAC 10.11.3 El Captian
Go to /Applications/XAMPP/xamppfiles/var/mysql/
Delete all random files (except the actual database folders)
Restart Apache and MySQL.
This worked for me.
To use the above (Nesar solution) in MAMP (version >= 4), you must first copy the my.cnf file that is inside MAMP/tmp/mysql to the MAMP/conf folder. Only then will it work.
I had a similar problem with Mamp Pro. For me it turned out the correct .idb-files were not located at "Applications/Mamp...". So taking a closer look at the error-log it showed me the files were located at "/Library/Application Support/appsolute/MAMP PRO/db". As I had problems with a database I wasn't using anymore, I just tried to delete the corresponding folder and it worked out. The next step would have been to delete the files already mentioned by the author.
innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd
But as mentioned deleting the databasefolder worked out great.
Tgr's answer looks appropriate. The message about permissions etc. is a generic one; the actual error message is
2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: .\phpmyadmin\pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: .\wiki\archive.ibd
Your wiki database and phpmyadmin database somehow ended up with the same tablespace ID. Each would work fine if the other wasn't present; as it is now, you'll have to renumber one of them somehow.
"Attempted to open a previously opened tablespace." -- That smells like one of these:
There are two copies of MySQL and both are trying to run.
Windows failed to release an 'open' on one of MySQL's files. I used to see that problem. It was cured by rebooting Windows; later by upgrading Windows.
Another solution for the issue discribed above for MAMP Pro, as I found impossible to edit my.cnf properly :
When InnoDB is crashing, spot in the error message the DB that is causing trouble. Here it is phpmyadmin/pma__tracking so the table is the one with the pma_ extension.
Then go to /Library/Application Support/appsolute/MAMP PRO/db/mysql and remove the folder named after the problem causing DB.
Restart your MAMP server.
Once you restarted with success, you can stop servers again, put back the DB folder where it belongs and start the servers again. Everything should be fine again.
I had the same problem, after use recovery database structure ( http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html )
I remove the archive.ibm file and start mysql.
then create archive table in database.
if someone has problems with any of their corrupt tables, this may be a possible solution to their problem, in my case I had the backup of my database so just delete the tables that are the files .ibd then restart MAMP PRO and mysql started correctly. A database backup must be taken into account. hope this helps someone and doesn't waste a lot of time. regards
after 4 hours i got solution without loos any data, please use below to resolve your issue
I had the same problem. I tried all the solution others has proposed, and unfortunately nothing worked.
After spending hours on searching for the solution in Google I finally found this
Open my.ini (my.cnf on linux centos /etc/my.cnf.d/server.cnf)
Look for [mysqld]
Just below [mysqld] insert innodb_force_recovery = 1
Start MySQL Service
Stop MySQL Service
Remove the line from my.ini (innodb_force_recovery = 1)
Start MySQL Service
Worked perfect in my case.
I hope this will solve your problem.
When adding to table of over 20m rows an index using alter table I'm geting discconected after a while from mysql .
I'm using mysql 5.6 and this is the log file I'm getting:
END OF INNODB MONITOR OUTPUT
============================
InnoDB: ###### Diagnostic info printed to the standard error stream
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
2014-08-31 21:52:17 890 InnoDB: Assertion failure in thread 2192 in file srv0srv.cc line 1748
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
I fixed it by changing the cfg file "my" .
I changed the inno db bufeer to 1500mb and now all good so far.
hope it will help others.