Open SimeonZ opened 1 year ago
I encountered a similar issue, and in response, I uninstalled MySQL, restarted MacOS and subsequently reinstalled it. This course of action effectively resolved the problem for me.
@sineld but with the uninstall will I lose the existing databases? I want to save existing databases that I cant access at this moment.
@SimeonZ try to connect and back it up with command line. I've done that before reinstalling.
@sineld tried but the same error occurs: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Please fill out the detail below, it helps me investigate the bug:
Driver (Ex: PostgreSQL 10.0): MySQL 8.0.12
DBngin build number: Version 6.4 (64)
macOS version: Monterey 12.6.2
The steps to reproduce this issue: I start the MySQL8 server with DBngin it went green but I can't connect. In parallel I have MySQL5 and it works fine.
I opened the file mysqld.local.err and this is the last content:
`2023-05-11T12:18:06.764549Z 0 [System] [MY-010931] [Server] /Users/Shared/DBngin/mysql/8.0.12/bin/mysqld: ready for connections. Version: '8.0.12' socket: '/tmp/mysql_3306.sock' port: 3306 MySQL Community Server - GPL. 2023-05-11T12:18:07.765227Z 0 [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: dict0dict.cc:3308:for_table || ref_table InnoDB: thread 13188177920 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. 12:18:07 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.
key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=1 max_threads=151 thread_count=1 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 67870 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f8561015200 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 = 312139ee0 thread_stack 0x46000 0 mysqld 0x00000001059c35ec my_print_stacktrace(unsigned char, unsigned long) + 60 1 mysqld 0x0000000104e20e76 handle_fatal_signal + 678 2 libsystem_platform.dylib 0x00007ff81f306dfd _sigtramp + 29 3 ??? 0x0000000000000000 0x0 + 0 4 libsystem_c.dylib 0x00007ff81f23cd24 abort + 123 5 mysqld 0x0000000105d5007c ut_dbg_assertion_failed(char const, char const, unsigned long) + 252 6 mysqld 0x0000000105aff86b dict_foreign_add_to_cache(dict_foreign_t, char const, bool, bool, dict_err_ignore_t) + 1659 7 mysqld 0x0000000105b172df dd_table_load_fk_from_dd(dict_table_t, dd::Table const, char const, dict_err_ignore_t, bool) + 1439 8 mysqld 0x0000000105b1cd9b dict_table_t dd_open_table_one(dd::cache::Dictionary_client , TABLE const, char const, dd::Table const, THD, std::1::deque<char const, ut_allocator<char const> >&) + 7963
9 mysqld 0x0000000105b0e05c dd_table_open_on_dd_obj(dd::cache::Dictionary_client, dd::Table const&, dd::Partition const, char const, dict_table_t&, THD) + 1996
10 mysqld 0x0000000105b0f2ca dd_table_open_on_id_low(THD, MDL_ticket*, unsigned long long) + 1738
11 mysqld 0x0000000105b0ea42 dd_table_open_on_id(unsigned long long, THD, MDL_ticket*, bool, bool) + 2018
12 mysqld 0x0000000105ce1755 row_purge_step(que_thr_t) + 773
13 mysqld 0x0000000105ca4997 que_run_threads(que_thr_t) + 855
14 mysqld 0x0000000105d0c39f srv_worker_thread() + 671
15 mysqld 0x0000000105d1b844 void std::1::thread_proxy<std::1::tuple<std::1::unique_ptr<std::1::thread_struct, std::__1::default_delete<std::1::__thread_struct> >, Runnable, void ()()> >(void) + 52
16 libsystem_pthread.dylib 0x00007ff81f2f14e1 _pthread_start + 125
17 libsystem_pthread.dylib 0x00007ff81f2ecf6b thread_start + 15
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0): is an invalid pointer Connection ID (thread ID): 0 Status: NOT_KILLED
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. ` Is there any way to fix this or can I somehow extract the existing databases inside so I don't lose them?