Bug #102711 Getting Semaphore wait has lasted > 600 seconds error while using MySql(5.7.31)
Submitted: 23 Feb 2021 21:40 Modified: 25 Feb 2021 6:10
Reporter: Abiel Dereje Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Errors Severity:S3 (Non-critical)
Version:5.7.31 OS:Windows
Assigned to: CPU Architecture:Other (Intel i5)
Tags: errors

[23 Feb 2021 21:40] Abiel Dereje
Description:
I'll be honest i don't really have any experience with this error so 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 ;

How to repeat:
Not sure how to reproduce since this error occurs upon startup without any indicator of why it's failing
[24 Feb 2021 13:30] MySQL Verification Team
Hi Mr. Dereje,

Thank you for your bug report.

However, this is not a bug.

The error that you report in the title is expected behaviour in the situations with high concurrency. The frequency of getting that error depends on the level of concurrency, design of your schemas, design of your transactions and configuration settings.

What we can easily conclude from your report is that settings are definitely wrong. You can find out much more about this problem in our Reference Manual.

Not a bug.
[25 Feb 2021 6:10] Abiel Dereje
what do adjustments do you suggest i make to the settings i ask because the mods i made to those values in the description for my config file i've recently reset to the original values and this issue still persists i've looked at the mysql keeps crashing article in the reference manual but most of those workarounds don't apply to me since they require access to the mysql console and i don't have that since the service won't start. Also i notice you mention the schema as a potential issue i know i imported a group of tables into to my database and overwrote a couple of predefined tables in the phpmydadmin database provided by wampserver one of them being this table with this transaction: 
 DROP TABLE IF EXISTS `columns_priv`;
CREATE TABLE IF NOT EXISTS `columns_priv` (
  `Host` char(60) COLLATE utf8_bin NOT NULL DEFAULT '',
  `Db` char(64) COLLATE utf8_bin NOT NULL DEFAULT '',
  `User` char(32) COLLATE utf8_bin NOT NULL DEFAULT '',
  `Table_name` char(64) COLLATE utf8_bin NOT NULL DEFAULT '',
  `Column_name` char(64) COLLATE utf8_bin NOT NULL DEFAULT '',
  `Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `Column_priv` set('Select','Insert','Update','References') CHARACTER SET utf8 NOT NULL DEFAULT ''
) 
could this be the issue?
[25 Feb 2021 13:06] MySQL Verification Team
Hi Mr. Dereje,

DDL can not be the issue, unless there are concurrent queries running on the table that is to be dropped.

Regarding settings, see our Reference Manual. However, the most frequent cause of the semaphore wait is the design and the implementation of the application that accesses MySQL server.