关于
Buy Me a Coffee
归档
友链
猫咪
RSS
后台
切换模式
返回顶部
首页
说说
日常
开发
游戏
资源
虚拟货币
首页
说说
日常
开发
游戏
资源
虚拟货币
关于
Buy Me a Coffee
归档
友链
猫咪
RSS
后台
Mac下MySQL错误排查:ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
开发
·
2019-10-06
·
更新于 2020-06-26
LiesAuer
### 起因 原本已经装上的`5.7`版本是正常运行的,后来因为项目的需要,需要换个版本做测试,于是乎就使用`brew`安装了`8.0`版本的MySQL,然后启动后一连接就傻眼了,提示 ``` ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) ``` ### 查错 于是到网上一顿搜索,试了无数种方法都无效,在系统日志里也找不到报错,但是偶然间被我发现了MySQL的日志`/usr/local/var/mysql/pingguoiMac.local.err`,要注意上面的`pingguoiMac`是我Mac的名字,并不是死的。发现里面的日志长达好几兆(我才开了服务没多久),打开粗略看了一下,发现MySQL处于崩溃重启的无限循环中,赶紧`brew services stop mysql`先把服务停了,然后分析奔溃日志,发现第一处的错误是 ``` [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000! 0x7fffb4f0f380 InnoDB: Assertion failure in thread 140736229077888 in file ut0ut.cc line 942 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. 03:42:25 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=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 = 68221 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 0x000000010ada20ae my_print_stacktrace + 58 1 mysqld 0x000000010ad20b87 handle_fatal_signal + 698 2 libsystem_platform.dylib 0x00007fff7c7d7f5a _sigtramp + 26 3 ??? 0x0000000000000000 0x0 + 0 4 libsystem_c.dylib 0x00007fff7c5751ae abort + 127 5 mysqld 0x000000010af8e362 _Z23ut_dbg_assertion_failedPKcS0_m + 161 6 mysqld 0x000000010af90dfd _ZN2ib5fatalD2Ev + 91 7 mysqld 0x000000010af90e39 _ZN2ib5fatalD1Ev + 9 8 mysqld 0x000000010ae3a49f _ZL18fil_node_open_fileP10fil_node_t + 2442 9 mysqld 0x000000010ae43c6a _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 191 10 mysqld 0x000000010ae44351 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 795 11 mysqld 0x000000010ae09f87 _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 384 12 mysqld 0x000000010ae0a0d6 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 59 13 mysqld 0x000000010adf6439 _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 951 14 mysqld 0x000000010af7e442 _Z31trx_rseg_get_n_undo_tablespacesPm + 262 15 mysqld 0x000000010af61e23 _Z34innobase_start_or_create_for_mysqlv + 6904 16 mysqld 0x000000010ae93abc _ZL13innobase_initPv + 3661 17 mysqld 0x000000010a7fbdd9 _Z24ha_initialize_handlertonP13st_plugin_int + 79 18 mysqld 0x000000010ac71375 _ZL17plugin_initializeP13st_plugin_int + 79 19 mysqld 0x000000010ac70e7c _Z40plugin_register_builtin_and_init_core_sePiPPc + 653 20 mysqld 0x000000010ad15f51 _Z11mysqld_mainiPPc + 2931 21 libdyld.dylib 0x00007fff7c4c9015 start + 1 22 ??? 0x0000000000000006 0x0 + 6 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. ``` ### 解决 根据日志推断是数据库坏了,将`/usr/local/var/mysql`重命名`/usr/local/var/mysql_bak`做备份,然后重装MySQL,启动服务,发现日志无报错,使用`mysql -uroot`连接,无异常正常连接,由于我的旧数据库是测试数据,没什么东西的,我的解决方案就暂时到这里,直接不要旧数据了,至于有数据恢复的需求的话,就暂时没去研究了。有需要的话可以尝试将数据库文件覆盖回去(请先了解MySQL数据库文件目录结构,非重要文件应该是不需要覆盖回去的),反正多试试,或者网上找找教程,记得多搞几个备份就行,最重要的是,别把第一份备份弄坏。
如果您觉得文章或项目对您有帮助,戳我请博主喝一杯咖啡叭!
取消回复
提交评论
瞅一瞅叭
域名出售
uterminal.ai
服务器推荐
RackNerd 2C2G $20.98/年(美国 隐藏款)
狗云 1C0.75G ¥150/年(香港 BGP)
最新评论
tinker: 为什么运行一段时间就会停止,重启又恢复!没有报错信息,频道信息和...
pansoo: 大佬,这个只能下载文件吗?能不能保存频道消息
Miller: 最好再多加一个查漏补缺的功能(捂脸(/ω\)),因为抓取了3天才...
Miller: 大佬,好像不会爬取jpeg文件,图片和视频数量对不上,是不是图片...
cola: 大佬,可以爬取电报频道的评论内容嘛
Miller: 大佬我终于会了,用cmd命令cd /d G:\cco,感谢大佬指点!
Miller: https://img13.chkaja.com/files/2...
关于站长
广东 佛山
liesauer#liesauer.net
LiesAuer
CC BY-NC-SA 4.0
粤ICP备16094588号-1
萌ICP备20245567号
Theme
Jasmine
by
Kent Liao