服务器异常宕机引发的mysql故障

1:服务器异常宕机、mysql、mysql_safe都无法启动
查看mysql报如下错误:
2018-03-30 06:25:12 1649 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future r
elease. Please use the full name instead.
2018-03-30 06:25:12 1649 [Note] Plugin 'FEDERATED' is disabled.
2018-03-30 06:25:12 1649 [ERROR] Function 'innodb' already exists
2018-03-30 06:25:12 1649 [Warning] Couldn't load plugin named 'innodb' with soname 'ha_innodb.so'.
2018-03-30 06:25:12 1649 [ERROR] Function 'federated' already exists
2018-03-30 06:25:12 1649 [Warning] Couldn't load plugin named 'federated' with soname 'ha_federated.so'.
2018-03-30 06:25:12 1649 [ERROR] Function 'blackhole' already exists
2018-03-30 06:25:12 1649 [Warning] Couldn't load plugin named 'blackhole' with soname 'ha_blackhole.so'.
2018-03-30 06:25:12 1649 [ERROR] Function 'archive' already exists
2018-03-30 06:25:12 1649 [Warning] Couldn't load plugin named 'archive' with soname 'ha_archive.so'.
2018-03-30 06:25:12 1649 [Note] InnoDB: Using atomics to ref count buffer pool pages
2018-03-30 06:25:12 1649 [Note] InnoDB: The InnoDB memory heap is disabled
2018-03-30 06:25:12 1649 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-03-30 06:25:12 1649 [Note] InnoDB: Memory barrier is not used
2018-03-30 06:25:12 1649 [Note] InnoDB: Compressed tables use zlib 1.2.8
2018-03-30 06:25:12 1649 [Note] InnoDB: Using Linux native AIO
2018-03-30 06:25:12 1649 [Note] InnoDB: Using CPU crc32 instructions
2018-03-30 06:25:12 1649 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2018-03-30 06:25:12 1649 [Note] InnoDB: Completed initialization of buffer pool
2018-03-30 06:25:35 1649 [ERROR] InnoDB: Tried to read 1048576 bytes at offset 1048576. Was only able to read 913408.
InnoDB: Fatal error: cannot read from file. OS error number 17.
2018-03-30 06:25:35 7fcc5aafc780  InnoDB: Assertion failure in thread 140515671525248 in file os0file.cc line 2694
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
22:25:35 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.
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.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=400
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 = 175093 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x555930e2e94c]
/usr/sbin/mysqld(handle_fatal_signal+0x3c2)[0x555930b84e62]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fcc59c81330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fcc590c2c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fcc590c6028]
/usr/sbin/mysqld(+0x815583)[0x555930f3f583]
/usr/sbin/mysqld(_Z28buf_dblwr_init_or_load_pagesiPcb+0x272)[0x5559310105a2]
/usr/sbin/mysqld(+0x883b1c)[0x555930fadb1c]
/usr/sbin/mysqld(+0x7c5bbc)[0x555930eefbbc]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x555930ab3b28]
/usr/sbin/mysqld(+0x4f19e0)[0x555930c1b9e0]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x928)[0x555930c21608]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0xa92)[0x555930aac9b2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fcc590adf45]
/usr/sbin/mysqld(+0x375c2d)[0x555930a9fc2d]
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.

解决办法: 
删除掉数据目录下ibdata*、ib_logfile*文件,

重启后可启动数据库,因数据库是非正常关闭引起的
****所有这类似的情况必须先备份数据库,避免人为操作造成的损坏 
tar -zcf mysqlback20180329.tar.gz mysql
正常启动后mysql 可以正常访问,但是日志报错
2018-03-30 10:59:59 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 10:59:59 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 11:00:00 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists
. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 11:00:00 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 11:00:00 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 11:00:00 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2018-03-30 11:00:00 15939 [Warning] InnoDB: Cannot open table ambari/QRTZ_TRIGGERS from the internal data dictionary of InnoDB though the .frm file for the ta
ble exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

打开此库下面的表发现提示不存在,但是frm和ibd文件都是存在的
mysql的命令行测试发现表状态不对
mysql> check tables QRTZ_TRIGGERS;
+----------------------+-------+----------+--------------------------------------------+
| Table                | Op    | Msg_type | Msg_text                                   |
+----------------------+-------+----------+--------------------------------------------+
| ambari.QRTZ_TRIGGERS | check | Error    | Table 'ambari.QRTZ_TRIGGERS' doesn't exist |
| ambari.QRTZ_TRIGGERS | check | status   | Operation failed                           |
+----------------------+-------+----------+--------------------------------------------+
2 rows in set (0.00 sec)

所以直接退出,查看整个所有库大概有多少张表损坏
mysqlcheck -A -uroot -ppassworkd > /tmp/unnormaltable
**(查单个库和表:mysqlcheck zabbix users -uroot -ppassword)

通过上述命令输出然后在分析大概有哪些表需要做恢复
grep -v ":" /tmp/unnormaltable |awk -F"." '{print $1,$2}'|sort -rn |uniq -c

恢复zabbix库
grep -v ":" /tmp/unnormaltable|grep zabbix |awk -F"." '{print $2}' > tablezabbix

把zabbix库中的文件全部mv到其它目录,导入空表结构

mysql -uroot -ppassword < zabbix.sql

到出表空间,清空idb文件,只剩下frm文件
while read line;do mysql -uroot -ppassword -e "use zabbix;SET FOREIGN_KEY_CHECKS = 0 ;ALTER TABLE $line DISCARD TABLESPACE";done < tablezabbix

ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails ()
SET FOREIGN_KEY_CHECKS = 0

把之前备份的ibd文件重新导入到zabbix目录下
for i in `find myzabbix/ -name *.ibd `;do mv  $i ./zabbix;done
把导入的ibd文件导入表空间
while read line;do mysql -uroot -ppassword -e "use zabbix;ALTER TABLE $line IMPORT TABLESPACE";done < tablezabbix

Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'
导入的过程中如果有的表空间过大的话可能会报错,可以适当优化两个参数
wait_timeout = x 超时时间  如600秒
max_allowed_packet = y 最大允许数据量

整体过程:
1、备份
2、确定哪些表损坏
3、移除损坏表的数据至备份目录
4、创建这些表
5、导出表空间
6、移入刚移出的这些表的ibd文件
7、导入表空间
8、测试

转载于:https://my.oschina.net/u/2343310/blog/1789061

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 当MySQL 8.0宕机导致数据文件损坏时,可以通过以下步骤进行数据文件恢复: 1. 停止MySQL服务:首先,停止MySQL数据库服务,以确保在恢复过程中没有新的写入操作。 2. 备份数据文件:在通过文件恢复之前,应该先备份损坏的数据文件,以防止进一步的数据丢失。 3. 检查错误日志:查看MySQL错误日志,它会记录关于宕机和数据文件损坏的信息。根据错误日志中的提示,了解具体的数据文件损坏情况。 4. 使用数据文件恢复工具:MySQL提供了一些内置工具来恢复损坏的数据文件,如"mysqlcheck"和"myisamchk"。根据错误日志的提示,选择合适的工具对损坏文件进行修复。 5. 修复数据文件:根据提示使用相应的工具对损坏的数据文件进行修复。这些工具会尝试自动修复损坏的数据文件,并恢复它们的完整性。在修复之前,建议先进行数据文件备份。 6. 启动MySQL服务:完成数据文件修复后,重新启动MySQL数据库服务。 7. 数据一致性检查:在启动MySQL服务之后,建议对数据库中的数据进行一致性检查,确保数据的完整性和正确性。 8. 数据恢复验证:通过执行一些测试语句或查询来验证数据文件恢复的结果,确保数据库的功能正常并且数据已经正确恢复。 在进行MySQL 8.0宕机数据文件恢复时,要小心操作,确保对数据进行适当的备份,并参考MySQL官方文档和手册以获得更详细的指导和建议。同时,为了避免宕机和数据文件损坏的情况发生,建议定期备份数据库、使用可靠的硬件设备和监控系统性能。 ### 回答2: MySQL 8.0 宕机后,进行数据文件恢复的步骤如下: 首先,需要确定数据文件的完整性。可以使用MySQL内置的工具如MySQLcheck或者InnoDB crash recovery检查数据文件是否完整。如果数据文件有损坏,需要修复损坏的文件。 其次,为了减少数据丢失的可能性,在宕机恢复之前,需要进行数据备份。可以使用MySQL的备份工具如mysqldump或者MySQL Enterprise Backup。 接下来,根据宕机原因来决定具体的恢复方法。如果是由于崩溃引起的宕机,可以使用InnoDB crash recovery工具进行自动恢复。如果宕机是由于硬件故障或者其他原因引起的,则需要使用冷备份或者热备份进行恢复。 在进行恢复过程中,可以使用MySQL内置的日志文件来回滚未完成的事务,并恢复到宕机前的状态。如果没有进行事务日志的备份,可以参考binlog来进行数据恢复。 最后,当数据库恢复完成后,需要进行一些额外的步骤,如更新MySQL的配置文件,重启MySQL服务等。 总结起来,MySQL 8.0 宕机数据文件的恢复过程包括确定数据文件完整性、数据备份、根据宕机原因选择恢复方法、使用日志文件回滚事务、进行数据恢复、完成后的一些额外操作。有时候可能需要专业人士的帮助来处理复杂的情况。 ### 回答3: 当MySQL 8.0宕机时,进行数据文件恢复主要包括几个步骤。 首先,需要通过查看数据库的错误日志文件来确定宕机的原因。错误日志通常位于MySQL的数据目录下,其命名通常为hostname.err。通过查看错误日志可以了解到宕机原因,并进一步确定后续操作。 接下来,需要进行MySQL实例的恢复。可以通过运行MySQL提供的备份工具mysqldump进行备份数据,或者使用复制功能(如主从复制)来实现数据的冗余。恢复时,可以运行启动命令"mysqld --skip-slave-start"来跳过启动slave线程。 在MySQL宕机后,将其重启到恢复模式下(也称为恢复状态)。 1. 首先,运行启动命令"mysqld --skip-grant-tables",此时MySQL不会验证用户登录信息,可以直接以超级用户(root)身份登录。 2. 接着,登录到MySQL服务器,运行以下命令:ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';来修改root用户的密码。 3. 运行FLUSH PRIVILEGES;来刷新权限。 4. 最后,再次重新启动MySQL服务器。 接下来,可以通过使用mysqldump等工具将备份的数据重新导入到MySQL中,或者使用复制功能来重建冗余数据。当恢复完成后,可以正常启动MySQL服务器,用户可以继续使用数据库服务。 需要注意的是,在MySQL宕机后,及时与数据库管理员或专业人员联系,以便获得更准确和专业的恢复指导和支持。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值