homebrew installed mysql#5.7 does not start - mysql

Question

I had to move from mysql (8.0.29) to mysql#5.7. MySQL in its newest formula does not compile any longer on my machine, because the machine is running Mojave in order to have native Aperture support.
I installed mysql#5.7 and changed path in my .zshrc to point to the new /usr/local/opt/mysql#5.7/bin.
After this I am still unable to start MySQL. When I run brew services list, I get:
mysql#5.7 stopped USER ~/Library/LaunchAgents/homebrew.mxcl.mysql#5.7.plist
When I try to run /usr/local/opt/mysql/bin/mysqld_safe --datadir=/usr/local/var/mysql I get:
√ ~ % /usr/local/opt/mysql/bin/mysqld_safe --datadir=/usr/local/var/mysql
2022-10-07T17:06:21.6NZ mysqld_safe Logging to '/usr/local/var/mysql/MACHINE.DOMAIN.TLD.err'.
2022-10-07T17:06:21.6NZ mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
/usr/local/opt/mysql/bin/mysqld_safe: line 199: 9704 Abort trap: 6 env MYSQLD_PARENT_PID=9530 nohup /usr/local/opt/mysql/bin/mysqld --basedir=/usr/local/opt/mysql --datadir=/usr/local/var/mysql --plugin-dir=/usr/local/opt/mysql/lib/plugin --log-error=MACHINE.DOMAIN.TLD.err --pid-file=mMACHINE.DOMAIN.TLD.pid < /dev/null >> /usr/local/var/mysql/MACHINE.DOMAIN.TLD.err 2>&1
2022-10-07T17:06:21.6NZ mysqld_safe mysqld from pid file /usr/local/var/mysql/MACHINE.DOMAIN.TLD.pid ended
When I check the error log file MACHINE.DOMAIN.TLD.err, I get the following output:
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68222 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
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...
stack_bottom = 0 thread_stack 0x40000
0 mysqld 0x0000000101a676a9 my_print_stacktrace + 58
1 mysqld 0x00000001019e5473 handle_fatal_signal + 698
2 libsystem_platform.dylib 0x00007fff6d0b6b5d _sigtramp + 29
3 ??? 0x0000000103ae5380 0x0 + 4356723584
4 libsystem_c.dylib 0x00007fff6cf706a6 abort + 127
5 mysqld 0x0000000101c568b9 _Z23ut_dbg_assertion_failedPKcS0_m + 161
6 mysqld 0x0000000101c5929b _ZN2ib5fatalD2Ev + 91
7 mysqld 0x0000000101c592d9 _ZN2ib5fatalD1Ev + 9
8 mysqld 0x0000000101affc6d _ZL18fil_node_open_fileP10fil_node_t + 2435
9 mysqld 0x0000000101b0946b _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 191
10 mysqld 0x0000000101b09b71 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 796
11 mysqld 0x0000000101ad0dfc _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 415
12 mysqld 0x0000000101ad0f53 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 56
13 mysqld 0x0000000101abc5d4 _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 971
14 mysqld 0x0000000101c464d4 _Z31trx_rseg_get_n_undo_tablespacesPm + 251
15 mysqld 0x0000000101c296ab _Z34innobase_start_or_create_for_mysqlv + 6608
16 mysqld 0x0000000101b589d3 _ZL13innobase_initPv + 3636
17 mysqld 0x00000001014cde2e _Z24ha_initialize_handlertonP13st_plugin_int + 78
18 mysqld 0x0000000101931b46 _ZL17plugin_initializeP13st_plugin_int + 81
19 mysqld 0x000000010193164a _Z40plugin_register_builtin_and_init_core_sePiPPc + 706
20 mysqld 0x00000001019da4e2 _Z11mysqld_mainiPPc + 2918
21 libdyld.dylib 0x00007fff6cecb3d5 start + 1
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2022-10-07T16:36:18.6NZ mysqld_safe mysqld from pid file /usr/local/var/mysql/MACHINE.DOMAIN.TLD.pid ended
2022-10-07T16:36:28.6NZ mysqld_safe Logging to '/usr/local/var/mysql/MACHINE.DOMAIN.TLD.err'.
2022-10-07T16:36:28.6NZ mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
2022-10-07T16:36:29.201378Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2022-10-07T16:36:29.201633Z 0 [Note] /usr/local/opt/mysql#5.7/bin/mysqld (mysqld 5.7.39) starting as process 8643 ...
2022-10-07T16:36:29.205774Z 0 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2022-10-07T16:36:29.207723Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-10-07T16:36:29.207755Z 0 [Note] InnoDB: Uses event mutexes
2022-10-07T16:36:29.207775Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-10-07T16:36:29.207791Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2022-10-07T16:36:29.210674Z 0 [Note] InnoDB: Number of pools: 1
2022-10-07T16:36:29.210835Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-10-07T16:36:29.212601Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-10-07T16:36:29.224493Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-07T16:36:29.273548Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2022-10-07 18:36:29 0x110a1e5c0 InnoDB: Assertion failure in thread 4574012864 in file ut0ut.cc line 921
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/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:36:29 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
I really hope someone can point me into the right direction. Maybe you cannot switch your databases back to 5.7 from 8?
Update
When I delete my v8 DB and try to run mysqld --initialize I get:
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicuuc.70.dylib
Referenced from: /usr/local/bin/mysqld
Reason: image not found
zsh: abort mysqld --initialize

Answer 1

After restoring the whole /usr/local directory from Timemachine to a state before updating and upgrading Homebrew and its formulae, everything appears to be working again.
I do not know what caused my dysfunctional system. I suspect that, when I upgraded single formulae or when I installed a new formulae last week, something must have gone wrong.
The symptoms were, that single apps refused to run by complaining about the missing library /usr/local/opt/icu4c/lib/libicuuc.70.dylib. In fact icu4c had been upgraded to version 71.1.
Restoring the whole directory /usr/local returned all the apps, which I discovered as non working to a running state. I haven't run a brew update or brew upgrade yet.