【问题标题】:Mysql ibdata1 is broken, cannot start the serviceMysql ibdata1坏了,无法启动服务
【发布时间】:2018-05-22 23:18:24
【问题描述】:

我正在将旧 sql 导入现有架构。但是mysql服务突然停止了。现在我无法启动该服务。似乎 ibdata1 文件以某种方式损坏。这是我得到的日志。我尝试了几种方法,比如在my.cnf中添加innodb_force_recovery,杀死所有的mysql进程。它们都不起作用。

有人可以帮忙吗?提前致谢!!

我认为我发布了错误的日志。这是真正的日志:

========================

2017-12-08T17:56:24.927955Z 0 [注意] InnoDB:使用 CPU crc32 指令
2017-12-08T17:56:24.929802Z 0 [注意] InnoDB:初始化缓冲池,总大小 = 128M,实例 = 1,块大小 = 128M
2017-12-08T17:56:24.942256Z 0 [注意] InnoDB:缓冲池初始化完成
2017-12-08T17:56:24.961017Z 0 [注意] InnoDB:支持的最高文件格式是梭子鱼。
2017-12-08T17:56:24.962154Z 0 [注意] InnoDB:日志扫描已通过检查点 lsn 16417491586
2017-12-08T17:56:24.962169Z 0 [注意] InnoDB:进行恢复:扫描到日志序列号 16417493278
2017-12-08T17:56:24.963433Z 0 [注意] InnoDB:数据库未正常关闭!
2017-12-08T17:56:24.963443Z 0 [注意] InnoDB:开始崩溃恢复。
2017-12-08T17:56:24.996387Z 0 [注意] InnoDB:开始将一批日志记录应用到数据库...
InnoDB:百分比进度:70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2017-12-08T17:56:25.501869Z 0 [注意] InnoDB:应用批处理完成
2017-12-08T17:56:25.626479Z 0 [注意] InnoDB:删除临时表空间数据文件:“ibtmp1”
2017-12-08T17:56:25.626508Z 0 [注意] InnoDB:为临时表创建共享表空间
2017-12-08T17:56:25.626637Z 0 [注意] InnoDB:将文件“./ibtmp1”大小设置为 12 MB。物理上将文件写满;请稍候...
2017-12-08T17:56:25.649790Z 0 [注意] InnoDB:文件 './ibtmp1' 大小现在为 12 MB。
2017-12-08T17:56:25.650460Z 0 [注意] InnoDB:找到 96 个重做回滚段。 96 个重做回滚段处于活动状态。
2017-12-08T17:56:25.650469Z 0 [注意] InnoDB:32 个非重做回滚段处于活动状态。
2017-12-08T17:56:25.650670Z 0 [注意] InnoDB:等待清除开始
2017-12-08T17:56:25.655806Z 0 [错误] InnoDB:文件操作中的操作系统错误号 13。
2017-12-08T17:56:25.655825Z 0 [错误] InnoDB:错误表示 mysqld 没有该目录的访问权限。
2017-12-08 12:56:25 0x7000049f8000 InnoDB:文件 fil0fil.cc 第 896 行中的线程 123145379872768 中的断言失败
InnoDB:断言失败:成功
InnoDB:我们故意生成内存陷阱。

InnoDB:向http://bugs.mysql.com提交详细的错误报告。
InnoDB:如果您遇到重复的断言失败或崩溃,甚至
InnoDB:mysqld 启动后,可能有
InnoDB:InnoDB 表空间损坏。请参考
InnoDB:http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB:关于强制恢复。
17:56:25 UTC - mysqld 收到信号 6 ;
这可能是因为您遇到了错误。这个二进制文件也有可能
或者它所链接的库之一已损坏,构建不正确,
或配置错误。此错误也可能是由硬件故障引起的。
尝试收集一些有助于诊断问题的信息。
由于这是一次崩溃并且肯定有问题,因此信息
收集过程可能会失败。

key_buffer_size=8388608
读取缓冲区大小=131072
max_used_connections=0
最大线程数=151
thread_count=0
连接数=0
mysqld 可能最多可以使用
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68218 K 字节内存
希望没关系;如果不是,请减少方程中的一些变量。

线程指针:0x7f9792000000
尝试回溯。您可以使用以下信息来了解
mysqld死的地方。如果您在此之后没有看到任何消息,则说明发生了问题
大错特错...
stack_bottom = 7000049f7e20 thread_stack 0x40000
0 mysqld 0x000000010caa714a my_print_stacktrace + 58
1 mysqld 0x000000010ca039d0 handle_fatal_signal + 688
2 libsystem_platform.dylib 0x00007fffb8d52b3a _sigtramp + 26
3 mysqld 0x000000010d3bac17 _ZZN10binary_log4Uuid9to_stringEPKhPcE11byte_to_hex + 41879
4 libsystem_c.dylib 0x00007fffb8bd7420 中止 + 129
5 mysqld 0x000000010ccfd9c1 _Z23ut_dbg_assertion_failedPKcS0_m + 161
6 mysqld 0x000000010cb623bc _ZL18fil_node_open_fileP10fil_node_t + 3948
7 mysqld 0x000000010cb6d962 _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 194
8 mysqld 0x000000010cb6e418 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 1096
9 mysqld 0x000000010cb27073 _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 387
10 mysqld 0x000000010cb27288 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 56
11 mysqld 0x000000010cb0bb7a _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 1290
12 mysqld 0x000000010cae91e8 _Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t + 4008
13 mysqld 0x000000010cc97824 _Z21row_search_on_row_refP10btr_pcur_tmPK12dict_table_tPK8dtuple_tP5mtr_t + 164
14 mysqld 0x000000010cc956a6 _ZL34row_purge_remove_clust_if_poss_lowP12purge_node_tm + 438
15 mysqld 0x000000010cc93a68 _Z14row_purge_stepP9que_thr_t + 1944
16 mysqld 0x000000010cc55919 _Z15que_run_threadsP9que_thr_t + 937
17 mysqld 0x000000010ccd9c4d _Z9trx_purgemmb + 2973
18 mysqld 0x000000010ccc2d57 srv_purge_coordinator_thread + 2871
19 libsystem_pthread.dylib 0x00007fffb8d5c93b _pthread_body + 180
20 libsystem_pthread.dylib 0x00007fffb8d5c887 _pthread_body + 0
21 libsystem_pthread.dylib 0x00007fffb8d5c08d thread_start + 13

尝试获取一些变量。
某些指针可能无效并导致转储中止。
查询 (0):是一个无效的指针
连接 ID(线程 ID):0
状态:NOT_KILLED

【问题讨论】:

标签: mysql innodb recovery


【解决方案1】:

在将innodb_file_format_max 设置为Antelope 而不是默认的Barraccudainnodb_force_recovery 设置为2 (SRV_FORCE_NO_BACKGROUND) 之后mysqld 10.2.17-MariaDB 在我的开发环境中运行正常。

mysqld --innodb-force-recovery=2 --innodb-file-format-max=Antelope

正如innodb_force_recovery 中所述,在生产中使用这种方法是不明智的。

【讨论】:

    猜你喜欢
    • 2018-05-11
    • 2019-07-17
    • 2017-05-23
    • 1970-01-01
    • 1970-01-01
    • 2011-04-23
    • 1970-01-01
    • 2013-12-08
    • 2021-10-18
    相关资源
    最近更新 更多