Mac 使用mysql出现ERROR [MY-013183][InnoDB] Assertion failure以及找不到my.cnf的解决过程

在一次电脑莫名宕机，强制重启后，重启mysql，又启动我的django程序时遇到了以下报错：

2020-04-07T02:08:28.681772Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: '/tmp/mysqlx.sock' bind-address: '::' port: 33060
2020-04-07T02:08:36.359052Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:1224:table2 == NULL thread 123145436229632
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.
02:08:36 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7f93089cc200
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 = 700007fb6f48 thread_stack 0x46000
0   mysqld                              0x000000010e027d5c my_print_stacktrace(unsigned char const*, unsigned long) + 60
1   mysqld                              0x000000010d43600c handle_fatal_signal + 428
2   libsystem_platform.dylib            0x00007fff6969242d _sigtramp + 29
3   mysqld                              0x000000010f41a008 icu_59::RegexCompile::findCaseInsensitiveStarters(int, icu_59::UnicodeSet*)::RECaseFixData + 349816
4   libsystem_c.dylib                   0x00007fff69567a1c abort + 120
5   mysqld                              0x000000010e3f5147 ut_dbg_assertion_failed(char const*, char const*, unsigned long) + 343
6   mysqld                              0x000000010e17341a dict_table_add_to_cache(dict_table_t*, unsigned long, mem_block_info_t*) + 506
7   mysqld                              0x000000010e197365 dict_table_t* dd_open_table_one<dd::Table>(dd::cache::Dictionary_client*, TABLE const*, char const*, dd::Table const*, THD*, std::__1::deque<char const*, ut_allocator<char const*> >&) + 6741
8   mysqld                              0x000000010e1894e8 dict_table_t* dd_open_table<dd::Table>(dd::cache::Dictionary_client*, TABLE const*, char const*, dd::Table const*, THD*) + 72
9   mysqld                              0x000000010e23acf4 ha_innobase::open(char const*, int, unsigned int, dd::Table const*) + 2372
10  mysqld                              0x000000010cfc0097 handler::ha_open(TABLE*, char const*, int, int, dd::Table const*) + 87
11  mysqld                              0x000000010d3d150a open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, dd::Table const*) + 3562
12  mysqld                              0x000000010d23f39d open_table(THD*, TABLE_LIST*, Open_table_context*) + 3245
13  mysqld                              0x000000010d244453 open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) + 2003
14  mysqld                              0x000000010d24689d open_tables_for_query(THD*, TABLE_LIST*, unsigned int) + 109
15  mysqld                              0x000000010d3290e1 Sql_cmd_dml::prepare(THD*) + 209
16  mysqld                              0x000000010d32992b Sql_cmd_dml::execute(THD*) + 331
17  mysqld                              0x000000010d2e03e1 mysql_execute_command(THD*, bool) + 4225
18  mysqld                              0x000000010d2ddec2 mysql_parse(THD*, Parser_state*) + 1074
19  mysqld                              0x000000010d2dc77d dispatch_command(THD*, COM_DATA const*, enum_server_command) + 7213
20  mysqld                              0x000000010d2dd714 do_command(THD*) + 420
21  mysqld                              0x000000010d41dc34 handle_connection(void*) + 388
22  mysqld                              0x000000010e46b6e6 pfs_spawn_thread(void*) + 230
23  libsystem_pthread.dylib             0x00007fff6969de65 _pthread_start + 148
24  libsystem_pthread.dylib             0x00007fff6969983b thread_start + 15

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f93089c9428): SELECT `django_apscheduler_djangojob`.`id`, `django_apscheduler_djangojob`.`name`, `django_apscheduler_djangojob`.`next_run_time`, `django_apscheduler_djangojob`.`job_state` FROM `django_apscheduler_djangojob` WHERE `django_apscheduler_djangojob`.`name` = 'scheduler.views.my_job'
Connection ID (thread ID): 8
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.

其中重点的几句是：

2020-04-07T02:08:36.359052Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:1224:table2 == NULL thread 123145436229632
InnoDB: We intentionally generate a memory trap.

InnoDB: We intentionally generate a memory trap.

Connection ID (thread ID): 8
Status: NOT_KILLED

从网上搜了下发现这种大多是因为突然宕机造成的数据库数据出了问题，我这块出错的表是在django的apscheduler中，在运行时这部分表的确会不断进行查询等操作，所以突遇意外也是很有可能的。

解决方法首选是修改 innodb_force_recovery 的值，这个值的说明如下：

innodb_force_recovery 会影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后，可以对表进行

select,create,drop操作,但insert,update或者delete这类操作是不允许的。

值为1：(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
值为2：(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
值为3：(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
值为4：(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
值为5：(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
值为6：(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

查看目前innodb_force_recovery的值

我首先是用mysql -u root -p 登入了mysql
mysql> use sys;进入到系统数据库
使用以下语句查看innodb_force_recovery的值
mysql> show variables like '%innodb_force_recovery%'；

发现目前为0

查找my.cnf或者my.ini文件

网上修改此值的方法是修改my.ini或者my.cnf文件，但是我怎么搜都找不到自己的my.cnf文件。
查找命令如下：
mysql --help --verbose | grep my.cnf
会出现以下类似路径
vi了每个路径，发现内容都是空的，就表示没找到。【如果有内容，那应该就是你的配置文件啦】

Mac添加my.cnf文件

一查是因为mac新版本的mysql没有my.cnf了，需要的话可以自己加。于是，我按照 mac添加my.cnf文件 的内容，自己加了my.cnf文件，注意加的路径从上面查找出来的路径中选一个就行～
我选择了/etc/my.cnf

sudo vim /etc/my.cnf
注意一定要有sudo，不然wq保存时会提示private啥啥，无法保存！
执行此命令后，esc，wq保存【此处命令来源请自行查询vim指令】
之后从finder中找到这个my.cnf，把上面链接中的my.cnf内容复制进去，重启下mysql。
重启成功后，再mysql> show variables like '%innodb_force_recovery%'；发现是0，因为我们默认的就是0。

修改my.cnf文件

在[mysqld]下面加上一行 innodb_force_recovery = 1 ，建议从1开始试，未成功再变成2、3、4…我理解的是，数字越大，恢复的数据就离最新版本越远。
然后保存my.cnf，重启mysql
此时mysql> show variables like '%innodb_force_recovery%' 发现变成了1.

然后按照启动我的django程序，发现可以正常启动了。应该是恢复程序生效了。

innodb_force_recovery 改回0

之后记得把my.cnf里的 innodb_force_recovery 值改回0，重启mysql。
django程序依旧可以正常启动。

棒呆！