Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
10.3.13
Description
2021-05-27 10:09:01 0 [ERROR] InnoDB: Operating system error number 11 in a file operation.
2021-05-27 10:09:01 0 [ERROR] InnoDB: Error number 11 means 'Resource temporarily unavailable'
2021-05-27 10:09:01 0 [Note] InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/
2021-05-27 10:09:01 0 [ERROR] InnoDB: Cannot open datafile './ibdata1'
2021-05-27 10:09:01 0 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2021-05-27 10:09:01 0 [ERROR] InnoDB: Plugin initialization aborted with error Cannot open a file
2021-05-27 10:09:01 0 [Note] InnoDB: Starting shutdown...
2021-05-27 10:09:03 0 [ERROR] Plugin 'InnoDB' init function returned error.
2021-05-27 10:09:03 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2021-05-27 10:09:03 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-05-27 10:09:03 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2021-05-27 10:09:03 0 [ERROR] Aborting
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
Activity
The "resource temporary unavailable" errors are a second mariadb instance starting while the first is still running.
Looking at the crash this may have been a memory allocation failure (usually insufficient memory) in page_cur_insert_rec_low. Does this occur repeatability?
On the crash above, there has been a significant number of errors fixed since 10.3.13 was released in 21 Feb 2019.
If not, does the latest version in the 10.3 series resolve the issue?
If that fails, can you please attempt to get a full stack trace from the latest version - https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/#analyzing-a-core-file-with-gdb-on-linux .
I suspect that this corruption was introduced by MDEV-11369 and fixed in MDEV-19916 (MariaDB Server 10.3.17, 10.4.7) almost 2 years ago.
2021-05-27 10:10:01 2 [ERROR] InnoDB: Page old data size 8709 new data size 8901, page old max ins size 7490 new max ins size 7298
2021-05-27 10:10:01 2 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
2021-05-27 10:10:01 0x7fc572375700 InnoDB: Assertion failure in file /mysql_log/soft/mariadb-10.3.13/storage/innobase/page/page0page.cc line 863
InnoDB: Failing assertion: cur2
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
210527 10:10:01 [ERROR] mysqld got signal 6 ;
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.