MySQL Bugs: #96092: Corrupted

Bug #96092	Corrupted
Submitted:	4 Jul 2019 12:10	Modified:	9 Aug 2019 12:27
Reporter:	M F	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.7.14	OS:	Any
Assigned to:	MySQL Verification Team	CPU Architecture:	Any

Description:
I restarted the server but couldn't get it back up. The log below is when innodb_force_recovery is set to 1. If i try to delete the ib_log files, the server will start up but there are tables which i cannot access with this error - InnoDB: Cannot open table <schema>/<table> from the internal data dictionary
 of InnoDB though the .frm file for the table exists. 

-----
2019-07-04T11:52:15.654381Z 0 [Note] InnoDB: Database was not shutdown normally!
2019-07-04T11:52:15.654381Z 0 [Note] InnoDB: Starting crash recovery.
2019-07-04T11:52:15.669945Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859652514816
2019-07-04T11:52:16.044962Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859657757696
2019-07-04T11:52:16.419956Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859663000576
2019-07-04T11:52:16.779303Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859668243456
2019-07-04T11:52:17.138700Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859673486336
2019-07-04T11:52:17.513670Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859678729216
2019-07-04T11:52:17.904317Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859683972096
2019-07-04T11:52:18.263661Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859689214976
2019-07-04T11:52:18.638654Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859694457856
2019-07-04T11:52:19.013697Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859699700736
2019-07-04T11:52:19.404271Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859704943616
2019-07-04T11:52:19.779266Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 859710186496
2019-07-04T11:52:20.029288Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 11:52:20 UTC - mysqld got exception 0xc0000005 ;
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=8388608
read_buffer_size=131072
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 = 68011 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...
2019-07-04T11:52:20.029288Z 0 [ERROR] InnoDB: Probable data corruption on page 24356. Original record on that page;
2019-07-04 21:52:20 0x41a42019-07-04T11:52:20.029288Z 0 [ERROR] InnoDB: Probable data corruption on page 24373. Original record on that page;
  InnoDB: Assertion failure in thread 16804 in file page0cur.cc line 1305
InnoDB: We intentionally generate a memory trap.

How to repeat:
Hosted in wampserver and restarted from there. I does not restart and running mysqlid in command prompt gives me that error.

Hi Mr. F,

Thank you for your bug report.

From what you have provided us with, we do not quite see why do you think that this is a bug. In the early days of InnoDB SE, there were bugs leading to corruption. Those bugs were sorted out for quite some time now.

What you observe can come from three main causes.

First, your ACID settings are not 100 % safe. That includes setting InnoDB for doublewrite, with all checksumming available (like crc32), enabling full InnoDB flushing, having DIRECT method of flushing, flushing neighbours and using strict ACID settings in your InnoDB configuration. 

Second, beside the above, your filesystem should be mounted with no caching what so ever. Furthermore, all the caches on the disk controller and disk should be turned off. Last, but not least, your filesystems containing tables and logs should not be cached by OS , at all ....

Third, even if you have done all of the above, there might be a flaw in your hardware, whether RAM, disk, controller or elsewhere. The flaw can be discovered by diagnostic hardware. But, much more often, these errors might occur infrequently, due to problems in refreshing dynamic RAM modules. You will not have these problems if you are using ECC RAM, 2 bits checking 1 bit correcting. Also if you are using RAID 10 disk subsystem.

Do you have all these prerequisites in place ????

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".