We installed Wamp 3.3.0 64 bit on Windows Datacenter Server 2019 and had nothing but problems with MySQL crashing. Here are the details:
Description:
1) The server did NOT crash running a specific query.
2) The log file generated an error "Operating system error number 1460 in a file operation." and "Assertion failure: os0file.cc:7022:slot->is_reserved thread 9968"
3) The MySQL attempted a backtrace and came back with " File .\undo_002: 'aio write' returned OS error 1560. Cannot continue operation"
4) The MySQL instance crashed.
5) I expected MySQl would recover from this operation but it did not.
6) We have searched your bug database and stack over flow, no one has this issue
It happens once a week but there is no way to reproduce. CPU spikes to
100% and then MySQL crashes. We then have to stop and start the service
for it to recover. Brand new server 24GB ram with SSD drives 4 CPU
Sockets and 16 Virtual Processors running on Hypervison with average CPU
of 28%
MySQL Bug reporting said it's a bug with v 8.0.30 and to rename the jemalloc to force the system to use the old malloc.
That did not work, any advise? Should we go back to the 32bit version and MySQL 5.7?
Description:
1) The server did NOT crash running a specific query.
2) The log file generated an error "Operating system error number 1460 in a file operation." and "Assertion failure: os0file.cc:7022:slot->is_reserved thread 9968"
3) The MySQL attempted a backtrace and came back with " File .\undo_002: 'aio write' returned OS error 1560. Cannot continue operation"
4) The MySQL instance crashed.
5) I expected MySQl would recover from this operation but it did not.
6) We have searched your bug database and stack over flow, no one has this issue
It happens once a week but there is no way to reproduce. CPU spikes to
100% and then MySQL crashes. We then have to stop and start the service
for it to recover. Brand new server 24GB ram with SSD drives 4 CPU
Sockets and 16 Virtual Processors running on Hypervison with average CPU
of 28%
MySQL Bug reporting said it's a bug with v 8.0.30 and to rename the jemalloc to force the system to use the old malloc.
That did not work, any advise? Should we go back to the 32bit version and MySQL 5.7?