记一次数据崩溃无法启动
admin
2023-04-19 19:04:12
0

场景:
远程拷贝的/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

上一篇:MySQL的查询操作

下一篇:MySQL的基础分部

相关内容

热门资讯

原创 v... 影像的发展进一步推动,不少品牌推出了专业影像手机,拥有2亿像素摄像头、色彩还原摄像头、影像芯片、影像...
荣耀首款自研耳夹式耳机官宣即将... 快科技5月13日消息,日前,荣耀首席营销官关海涛宣布,荣耀全场景团队自研首款耳夹式耳机马上上市,并称...
谷歌推出Googlebooks... IT之家 5 月 13 日消息,2026 年 I/O 开发者大会下周(5 月 19~20 日)召开之...
自控所推动GNC专业智能化升级 来源:滚动播报 (来源:中国航空报) 本报讯 5月6日,航空工业自控所召开 GNC+AI关键技术研发...
华电电力申请数据库访问方法专利... 国家知识产权局信息显示,华电电力科学研究院有限公司申请一项名为“数据库访问方法、装置、设备及介质”的...
苏州率先打造数据流通利用新范式 数据,作为第五大生产要素 具有流动性强、非消耗性、非均质性等特点 苏州率先打造数据流通利用新范式 夯...
伊媒披露伊美新一轮谈判5个先决... 当地时间5月12日,据伊朗法尔斯通讯社援引知情人士消息报道,伊朗对与美国新一轮谈判提出的5个先决条件...
英国将向霍尔木兹海峡多国护航行... 当地时间12日,总台记者从英国国防部获悉,英国将向在霍尔木兹海峡执行任务的多国护航行动提供无人机、战...
强化技术引领场景培育政策保障 ... 5月11日,省长叶建春就脑机接口技术与产业创新工作开展专题调研。他强调,脑机接口是培育未来产业发展新...
上海交大王如竹教授领衔撰写的“... 4月30日,国际制冷学会(IIR,International Institute of Refrig...