Bug #87837 MySQL 8 does not start after upgrade to 8.03
Submitted: 22 Sep 9:08 Modified: 27 Sep 8:20
Reporter: Peter Laursen (Basic Quality Contributor) Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Installing Severity:S1 (Critical)
Version:8.0.3 OS:Microsoft Windows (10/64 bit)
Assigned to:

[22 Sep 9:08] Peter Laursen
After upgrading from 8.02 to 8.03 using "MySQL Installer" the server will not start.

Error log:

2017-09-22T09:04:18.802243Z 0 [Note] Basedir set to C:\Program Files\MySQL\MySQL Server 8.0\
2017-09-22T09:04:18.804720Z 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2017-09-22T09:04:18.806269Z 0 [Note] C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe (mysqld 8.0.3-rc-log) starting as process 9588 ...
2017-09-22T09:04:18.814011Z 0 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=SH-WIN10-bin' to avoid this problem.
2017-09-22T09:04:18.822421Z 0 [Note] InnoDB: Adjusting innodb_buffer_pool_instances from 8 to 1 since innodb_buffer_pool_size is less than 1024 MiB
2017-09-22T09:04:18.823950Z 0 [Note] Plugin 'FEDERATED' is disabled.
2017-09-22T09:04:18.876011Z 1 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2017-09-22T09:04:18.876437Z 1 [Note] InnoDB: Uses event mutexes
2017-09-22T09:04:18.876651Z 1 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier
2017-09-22T09:04:18.876989Z 1 [Note] InnoDB: Compressed tables use zlib 1.2.11
2017-09-22T09:04:18.877508Z 1 [Note] InnoDB: Number of pools: 1
2017-09-22T09:04:18.877835Z 1 [Note] InnoDB: Using CPU crc32 instructions
2017-09-22T09:04:18.880336Z 1 [Note] InnoDB: Initializing buffer pool, total size = 8M, instances = 1, chunk size = 8M
2017-09-22T09:04:18.881327Z 1 [Note] InnoDB: Completed initialization of buffer pool
2017-09-22T09:04:18.897941Z 1 [Note] InnoDB: Using 'tablespaces.open.2' max LSN: 15530394
2017-09-22T09:04:18.904526Z 1 [Note] InnoDB: Applying a batch of 0 redo log records ...
2017-09-22T09:04:18.904830Z 1 [Note] InnoDB: Apply batch completed!
2017-09-22T09:04:18.930335Z 1 [Note] InnoDB: Opened 2 existing undo tablespaces.
2017-09-22T09:04:19.018565Z 1 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2017-09-22T09:04:19.018903Z 1 [Note] InnoDB: Creating shared tablespace for temporary tables
2017-09-22T09:04:19.019542Z 1 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2017-09-22T09:04:19.082777Z 1 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
2017-09-22T09:04:19.103016Z 1 [Note] InnoDB: Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
2017-09-22T09:04:19.105006Z 1 [Note] InnoDB: 8.0.3 started; log sequence number 15557675
2017-09-22T09:04:19.107270Z 1 [ERROR] [FATAL] InnoDB: Table flags are 0x4800 in the data dictionary but the flags in file mysql.ibd are 0x800!
2017-09-22T09:04:19.108507Z 1 [ERROR] InnoDB: Assertion failure: ut0ut.cc:738
InnoDB: thread 10996
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.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

How to repeat:
see above

Suggested fix:
no clue
[22 Sep 9:15] Peter Laursen
Setting innodb_force_recovery = 1 (https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html) 
... did not help.

I have no important data there so I can uninstall completely and do a fresh install.  I'll just wait a little while in case you need more info from my environment.
[22 Sep 10:15] Peter Laursen
This is an "S1" category ('denial of service'), obviously.
[22 Sep 11:19] Peter Laursen
It seems that mysql.idb is gone? 

C:\ProgramData\MySQL\MySQL Server 8.0\Data\mysql>dir
 Volume in drive C is Win10
 Volume Serial Number is 0805-A57A

 Directory of C:\ProgramData\MySQL\MySQL Server 8.0\Data\mysql

18-07-2017  12:11    <DIR>          .
18-07-2017  12:11    <DIR>          ..
08-09-2017  19:29                35 general_log.CSM
18-07-2017  12:11                 0 general_log.CSV
18-07-2017  12:11             8.896 general_log_188.sdi
08-09-2017  19:29                35 slow_log.CSM
18-07-2017  12:11                 0 slow_log.CSV
18-07-2017  12:11            18.289 slow_log_189.sdi
               6 File(s)         27.255 bytes
               2 Dir(s)  70.312.484.864 bytes free

C:\ProgramData\MySQL\MySQL Server 8.0\Data\mysql>
[22 Sep 11:28] Shane Bester
I believe this is expected.  First Note in here:

That being said,  I'm not sure why the installer tries to upgrade non-GA versions at all.
[22 Sep 12:28] Peter Laursen
I have now uninstalled (including deleting data files) and installed 8.03 from scratch and it works as expected.

I now see the "mysql.ibd" file is in C:\ProgramData\MySQL\MySQL Server 8.0\Data and not in C:\ProgramData\MySQL\MySQL Server 8.0\Data\mysql. So my comment on the missing file can be ignored (though I still think the file should rather be in C:\ProgramData\MySQL\MySQL Server 8.0\Data\mysql).
[26 Sep 9:15] Peter Laursen
@Shane .. I know that non-GA versions may not be "updateable".

But in such case the Installer should know this and prompt user do do a complete uninstall of old version.
[27 Sep 5:29] Chiranjeevi Battula
Hello Peter,

Thank you for the bug report.
Verified as described on MySQL for Windows Installer with 8.0.3 version.

[27 Sep 8:20] Peter Laursen
I have another concern: If MySQL 8.03 changes some InnoDB internals and changes prevent upgrade from previous versions, what will happen when 8.x goes GA? 

Will upgrade from 5.7 to 8.0 also not be possible?