Description:
In MySQL 5.7, it was possible to have a lost+found directory present in the MySQL datadir, and to use ignore_db_dirs to avoid issues with it.
However, in 8.0, this variable has been removed, and the in-place upgrade will fail with messages like:
==============================
2023-02-27T22:26:36.930648Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.32) starting as process 6662
2023-02-27T22:26:36.938288Z 1 [System] [MY-011012] [Server] Starting upgrade of data directory.
2023-02-27T22:26:36.938341Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-02-27T22:26:37.336609Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2023-02-27T22:26:37.720977Z 2 [ERROR] [MY-010520] [Server] Invalid (old?) table or database name 'lost+found'
2023-02-27T22:26:37.722570Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2023-02-27T22:26:37.722611Z 0 [ERROR] [MY-010119] [Server] Aborting
2023-02-27T22:26:39.178801Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.32) MySQL Community Server - GPL.
==============================
The workaround is to remove that directory, but I wonder if it should be possible to deal with it in a cleaner way?
Note that if we have a lost+found directory in a clean (non-upgraded) MySQL 8.0 install, it correctly detects lost+found as a directory it needs to ignore.
How to repeat:
Install MySQL 5.7, and make sure that there is a lost+found directory in its datadir, and use ignore_db_dirs to avoid issues with it.
Do an in-place upgrade to MySQL 8.0 to get issues as seen above.
Suggested fix:
Ignore these issues if they stem from a directory named lost+found, and issue a Warning message instead.