MySQL Bugs: #87837: MySQL 8 does not start after upgrade to 8.03

Bug #87837	MySQL 8 does not start after upgrade to 8.03
Submitted:	22 Sep 2017 9:08	Modified:	21 Dec 2017 8:27
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	8.0.3	OS:	Windows (10/64 bit)
Assigned to:		CPU Architecture:	Any

Description:
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

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.

This is an "S1" category ('denial of service'), obviously.

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>

I believe this is expected.  First Note in here:
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-3.html

That being said,  I'm not sure why the installer tries to upgrade non-GA versions at all.

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).

@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.

Hello Peter,

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

Thanks,
Chiranjeevi.

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?

Posted by developer:
 
Upgrades between 8.0.x milestones and release candidates can't be expected to work, since we reserve the right to do major incompatible changes between these versions.

We will support upgrade from 5.7 to 8.0 GA.

https://bugs.mysql.com/bug.php?id=90881 marked as duplicate of this one.

Hi, everyone!

Is there any way to recover the databases, after performing the inappropriate upgrade?

I have upgraded MySQL Server from 8.0.2 to 8.0.12 recently and now it is not clear, what I can do to get the server to the working state.
My problem seems to be nearly the same as, because of receiving the same error: [MySQL Bugs: #90881: mysql won't start](https://bugs.mysql.com/bug.php?id=90881).

Best regards,
Sergey Brunov.