mysql 崩溃

InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!

有资料说，将my.cnf增加一行“innodb_force_recovery = 4”，让mysql强制恢复innodb，或使用“innodb_force_recovery = 3”，将数据表内容单个导出再新建库并汇入，应该就可以了，如果不行可以测试一下。

时间： 2024-08-24 13:24:02

mysql 崩溃的相关文章

MySQL崩溃恢复过程常见错误分析

最近在和一个同事争论MySQL崩溃恢复中的一些常见错误时出现了一些分歧,他认为一些参数的设置会导致MySQL出现崩溃后恢复不起来的问题,但对此,我却不认同,虽然一些参数的设定会导致数据丢失,但应该不会引起数据库崩溃之后无法恢复的情况,因此,就想整理出MySQL崩溃恢复的过程来加深学习! 图一 mysql WAL过程在正常情况下,数据写入会先写入redo_buffer_pool,然后在写入redo_log_file,这中间如果由于参数设置不当,可能会发生丢失,但不影响主机的崩溃恢复,但有以下两种

“Too many connections”引起MySQL崩溃并启动失败

问题描述: 在部署一套新环境的时候,rancher-server上有14个镜像包一起升级,主要是微服务的写入和查询程序,基本上都是需要去连接MySQL的程序.可能是由于大并发连接数据库,最后起来的几个服务就报错了,docker容器启动失败,报的是MySQL的错误,打印了很长一串sql语句,最后有一个"too many connections". 然后登录MySQL查看当前的最大连接数设置,发现MySQL已经无法登录: [[email protected] ~]# mysql -u ro

磁盘空间不够导致mysql崩溃重启

起因: 群里有人提了句pt-ioprofile,我不知道,就查了查,想测一测,想以后可能会有帮助. 为了能看到效果,我选择了我虚拟机上最大的压测表Sbtest1,该表有100w数据,执行update sbtest1 set k=k+1; 并且通过pt-ioprofile查看到了想要的结果,然后就干别的去了,下午了,看update sbtest1 set k=k+1;这个窗口的光标还闪着,以为还没执行完,不停地回车,crtl c,各种不好用.过了一会儿,报错了,并且提示mysql已经重启了. 我去

MySQL崩溃恢复与组提交

Ⅰ.binlog与redo的一致性(原子) 由内部分布式事务保证我们先来了解下,当一个commit敲下后,内部会发生什么? 步骤操作 step1 InnoDB做prepare redo log(fsync) step2 Sever层写binlog(fsync) step3 InnoDB层commit redo log(fsync) 第一步写的redo file,写入的是trxid而不是page的变化(show binlog events in 'xxx'),准确的说写在undo页上第三步写

MySQL之——崩溃-修复损坏的innodb：innodb_force_recovery

转: https://blog.csdn.net/l1028386804/article/details/77199194 一.问题描述今天在线运行的一个mysql崩溃了. 查看错误日志,如下: ----------------------------------------- 161108 11:36:45 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var 2017-08-15 11:36:

【mysql】关于IO/内存方面的一些优化

这里使用的是mysql Ver 14.14 Distrib 5.6.19, for Linux (i686) using EditLine wrapper 一.mysql目录文件 ibdata1:系统表空间包含数据字典.回滚日志/undolog等 (insert buffer segment/double write segment/rollback segment/index segment/dictionary segment/undo segment) ib_logfile0/ib_

【原创】MySQL性能优化-I/O相关配置参数

本文介绍InnoDB和MyISAM两种存储引擎的I/O相关参数配置. 1.InnoDB I/O相关配置 Innodb是一种事务型的存储引擎,为了减少提交事务时产生的io开销,innodb采用了写日志的方式,也就是在事务提交的时候会先写入事务日志中 ,而不是每次都把修改或者数据刷新到数据文件中,这样做是为了提高io的性能,因为事务的修改,使数据和索引文件通常都会映射到表空间随机的位置,所以刷新数据变更到数据文件会产生大量随机io,而记录日志是顺序io,一旦事务日志安全的写到磁盘中,数据就算是持久

MYSQL事务及存储引擎对比

Innodb支持事务,而myisam不支持事务. 事务的定义: 当多个用户访问同一份数据时,一个用户在更改数据的过程中可能有其他用户同时发起更改请求,为保证数据的更新从一个一致性状态变更为另一个一致性状态,这时有必要引入事务的概念. Mysql提供了多种引擎支持Innodb和BDB.Innodb存储引擎事务主要通过UNDO日志和REDO日志实现,Myisam和memory引擎则不支持事务.下图分别给出三种mysql引擎的区别和特性: Myisam存储引擎:由于该引擎不支持事务.也不支持外键,所以

MySQL设计规范与性能优化

引言 MySQL是目前使用最为广泛的关系型数据库之一,如果使用得当,可支撑企业级高并发.高可靠服务,使用不当甚至连并发量略高的个人网站都难以支撑: 就算使用了缓存,大量的数据库访问依旧在所难免,即使设置了较长的缓存有效期,而且缓存命中率较理想,但缓存的创建和过期后的重建都是需要访问数据库的: 本文主要从MySQL表结构设计规范和MySQL自身性能优化两方面来讨论该如何对MySQL数据库进行优化: MySQL表结构设计规范 1. 数据库设计命名规范 (1)数据库,数据表一律使用前缀,前缀名称一般不