Hello,
We have an application which consists of multiple web services in IIS on a Windows machine with MySQL 8.4.6 LTS. Customers can run the application on-premises or in a Windows Azure VM. This is the reason we run MySQL in a VM instead of a managed service; to have only one deployment model.
We see now that when the Windows updates are run (which is done automatically on Azure) that the amount of IOps can exceed what the VHD supports; this seems to cause data stalling. This makes everything run slower (to be expected), but we see that MySQL gets the following error:
2025-11-04T22:07:52.621305Z 0 [Warning] [MY-012638] [InnoDB] Retry attempts for writing partial data failed.
2025-11-04T22:07:52.824534Z 0 [ERROR] [MY-012639] [InnoDB] Write to file .\#innodb_redo\#ib_redo104 failed at offset 2802688, 512 bytes should have been written, only 0 were written. Operating system error number 0. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2025-11-04T22:07:52.828597Z 0 [ERROR] [MY-012640] [InnoDB] Error number 0 means 'No error'
2025-11-04T22:07:52.875391Z 0 [ERROR] [MY-013864] [InnoDB] [FATAL] Error 100 encountered when writing to the redo log file: .\#innodb_redo\#ib_redo104.
2025-11-04T22:07:52.916697Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: log0write.cc:2118:ib::fatal triggered thread 6516
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/8.4/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2025-11-04T22:07:52Z UTC - mysqld got exception 0x16 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
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...
7ff7e466fd08 mysqld.exe!?my_print_stacktrace@@YAXPEBEK@Z()
7ff7e382b1d1 mysqld.exe!?my_server_abort@@YAXXZ()
7ff7e382af13 mysqld.exe!?my_server_abort@@YAXXZ()
7ff7e465a57a mysqld.exe!?my_abort@@YAXXZ()
7ff7e4830459 mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e4783ab3 mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e495315f mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e4952ec9 mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e495198d mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e47b30a4 mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ff7e47b32f9 mysqld.exe!?zstd_mem_res_free@Zstd_dec@compression@event@binlog@mysql@@CAXPEAX0@Z()
7ffe5b58268a ucrtbase.dll!_o_exp()
7ffe5bff7ac4 KERNEL32.DLL!BaseThreadInitThunk()
7ffe5edfa8c1 ntdll.dll!RtlUserThreadStart()
And the mysql service stops and needs manual action to resume.
Our question:
Are there settings that can prevent this from happening? Note that the high IOps moment is only for a certain amount of time, so is there a way to make MySQL more durable during these times? We can accept transient errors, since we have retry-policies, but when the service stops, we need a manual action.
Thanks in advance.