我的编程空间,编程开发者的网络收藏夹
学习永远不晚

记一次数据崩溃无法启动

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

记一次数据崩溃无法启动

场景:
远程拷贝的/var/lib/mysql/*的所有文件打包后拖到本地后无法启动。(导表因为数据库太大导表相当漫长,偷懒了....启动时一同报错....),

版本:
sys:
Linux console 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
DB:
Server version: 5.5.60-MariaDB MariaDB Server

报错信息:
数据库日志:

#tailf /var/log/mariadb/mariadb.log
Server version: 5.5.60-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 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 = 0x0 thread_stack 0x48000
190119 12:54:23 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
190119 12:55:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
190119 12:55:54 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10885 ...
190119 12:55:54 InnoDB: The InnoDB memory heap is disabled
190119 12:55:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
190119 12:55:54 InnoDB: Compressed tables use zlib 1.2.7
190119 12:55:54 InnoDB: Using Linux native AIO
190119 12:55:54 InnoDB: Initializing buffer pool, size = 128.0M
190119 12:55:54 InnoDB: Completed initialization of buffer pool
190119 12:55:54 InnoDB: highest supported file format is Barracuda.
190119 12:55:54  InnoDB: Starting crash recovery from checkpoint LSN=25825591529
InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
190119 12:55:54  InnoDB: Starting final batch to recover 15 pages from redo log
190119 12:55:54 [ERROR] mysqld got signal 11 ;
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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 5.5.60-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 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

服务状态:

#systemctl status mariadb
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2019-01-19 12:49:08 CST; 3s ago
  Process: 9550 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 9549 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 9517 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
 Main PID: 9549 (code=exited, status=0/SUCCESS)

Jan 19 12:49:06 console systemd[1]: Starting MariaDB database server...
Jan 19 12:49:06 console mariadb-prepare-db-dir[9517]: Database MariaDB is probably initialized in /var/lib/mysql alre
Jan 19 12:49:06 console mariadb-prepare-db-dir[9517]: If this is not the case, make sure the /var/lib/mysql is empty 
Jan 19 12:49:06 console mysqld_safe[9549]: 190119 12:49:06 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Jan 19 12:49:06 console mysqld_safe[9549]: 190119 12:49:06 mysqld_safe Starting mysqld daemon with databases from /va
Jan 19 12:49:08 console systemd[1]: mariadb.service: control process exited, code=exited status=1
Jan 19 12:49:08 console systemd[1]: Failed to start MariaDB database server.
Jan 19 12:49:08 console systemd[1]: Unit mariadb.service entered failed state.
Jan 19 12:49:08 console systemd[1]: mariadb.service failed.

解决方式:

(1)修改配置文件:
添加参数:
innodb_force_recovery = 6 (此项由1---6个级别一次往上修改参数在失败的情况下)
innodb_purge_threads = 0

(2)修改刚才解压的文件属主属组为mysql用户。

我的数据库配置文件:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

lower_case_table_name=1
character_set_server=utf8
skip_name_resolve
bind-address = 0.0.0.0

innodb_force_recovery = 6  
innodb_purge_threads = 0

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

记一次数据崩溃无法启动

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

记一次 .NET某实验室自动进样系统崩溃分析

既然是程序的崩溃,自然是有原因的,皮裤套棉裤,必定有缘故,不是皮裤太薄就是棉裤没毛,用 !analyze -v 观察下异常信息。

Mysql数据库意外崩溃导致表数据文件损坏无法启动的问题解决

问题故障:Mysql数据库意外崩溃,一直无法启动数据库。报错日志:启动报错:service mysqld restartERROR! MySQL server PID file could not be found!Starting MySQL. ERROR!
Mysql数据库意外崩溃导致表数据文件损坏无法启动的问题解决
2022-02-07

ceph mon无法启动-rocksdb数据损坏

一、问题描述rocksdb数据库发生异常导致mon进程无法拉起。二、问题现象:mon异常第一次call trace信息如下: Jul 31, 2020 @ 19:36:31.000 node-3 ceph ceph-mon 228,237 2020-0
ceph mon无法启动-rocksdb数据损坏
2019-06-15

phpstudy数据库无法启动在如何解决

如果phpstudy数据库无法启动,您可以尝试以下几种解决方法:检查端口是否被占用:打开cmd命令窗口,输入命令netstat -ano,查看是否有已经占用了数据库端口(默认是3306端口),如果有,可以尝试关闭占用程序或者修改数据库端口。
2023-10-24

Mysql无法启动情况下怎么恢复数据

如果MySQL无法启动,但数据文件仍然存在,您可以尝试以下方法来恢复数据:检查错误日志:首先查看MySQL的错误日志文件,通常位于MySQL的数据目录下,查看是否有特定的错误信息提示。检查MySQL配置文件:确保MySQL的配置文件(通常是
Mysql无法启动情况下怎么恢复数据
2024-04-09

一次Oracle修改最大连接数,导致oracle重启后无法登陆实例

这是一次本地压力测试,由于默认Oracle 10g的数据库最大连接数是150。但是要程序的压力测试要用到300。于是我参考网上资料,执行下面两行命令,修改最大连接数后,重启oracle服务器,就发生了错误提示oracle无法登陆。 step 1: 修改最大连接
一次Oracle修改最大连接数,导致oracle重启后无法登陆实例
2018-03-16

编程热搜

目录