mysqldump表损坏问题

遇到的问题:
mysqldump: Error 1194: Table ‘user‘ is marked as crashed and should be repaired when dumping table `user` at row: 1161435

登陆到数据库:
mysql> select count(*) from user;
+----------+
| count(*) |
+----------+
|  1840589 | 
+----------+
1 row in set (0.00 sec)
mysql> repair table user;
+--------------+--------+----------+------------------------------------------------+
| Table        | Op     | Msg_type | Msg_text                                       |
+--------------+--------+----------+------------------------------------------------+
| txtotal.user | repair | warning  | Number of rows changed from 1840589 to 1161435 | 
| txtotal.user | repair | status   | OK                                             | 
+--------------+--------+----------+------------------------------------------------+
2 rows in set (50.04 sec)
mysql> select count(*) from user;        
+----------+
| count(*) |
+----------+
|  1161435 | 
+----------+
1 row in set (0.20 sec)
mysql> check table  user;        
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| txtotal.user | check | status   | OK       | 
+--------------+-------+----------+----------+
1 row in set (15.05 sec)

数据表已经修复完成,只是记录从原来的1840589 条减少到了1161435 条,不是太清楚还有没有更好的方法去实现修复。

本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u1/38871/showart_1996523.html

时间: 2025-01-12 00:49:37

mysqldump表损坏问题的相关文章

MySQL数据库表损坏后的修复方法

步骤:1.sql语句:check table tabTest; 如果出现的结果说Status是OK,则不用修复,如果有Error2.Linux执行: myisamchk -r -q /var/lib/mysql/db/test.MYI 3.sql语句:repair table tabTest; 4.sql语句:check table tabTest; Status是OK就修复好了 非Linux上:直接 参考:有两种方法,一种方法使用mysql的check table和repair table 的

sql 2008R2系统表损坏

某客户单位,一台运行服务器突然出现故障不能进入系统,里面有运行的用友数据库,出现故障后自己公司DBA以及运维折腾了将近一星期后来能够进入系统了发现数据库已经无法正常使用,且所有之前6月份备份都损坏了,最近的备份也只有4月30号的,询问那边做过什么操作时,客户已经描述不清,无奈只能让客户发库过来看,客户是用友U8数据库运行平台为2008r2. 对数据MDF文件进行损坏发现很多物理页面损坏,先直接重建日志DBCC检测一下看看,在2008R2平台下重建日志之后发现DBCC语句根本无法查询跟运行,直接报

MySQL表损坏预防与修复

1.       表损坏的原因分析 以下原因是导致mysql 表毁坏的常见原因: 1. 服务器突然断电导致数据文件损坏. 2. 强制关机,没有先关闭mysql 服务. 3. mysqld 进程在写表时被杀掉. 4. 使用myisamchk 的同时,mysqld 也在操作表. 5. 磁盘故障. 6. 服务器死机. 7. mysql 本身的bug . 2.       表损坏的症状 一个损坏的表的典型症状如下: 1 .当在从表中选择数据之时,你得到如下错误: Incorrect key file f

MYSQL Truncate 引发数据表损坏案例分析

最近发布到市场的版本频繁出现数据库表损坏的情况,具体的现象是select表提示表不存在,但是查看data文件,对应表的ibd和frm文件都在. 通过对多个故障的统计,找到几个频繁出现损坏的表,在分析过程中,发现这些数据表都使用了truncate清除数据,所以怀疑是truncate操作的问题. 设计如下过程来验证这个分析结果: 1. 创建存储过程如下,对一张表模拟频繁调用TRUNCATE DROP PROCEDURE IF EXISTS prcTest5;CREATE PROCEDURE prcT

mysql.user表重置密码后出现表损坏问题

首先是发现了mysql数据库无论输入什么密码,都会直接进入数据库,没有验证.接下来开始入坑: 1 知道是因为my.ini文件中有    skip-grant-tables      可是当时不知道密码忘记了还是user表已经出现了异常,密码一直错误. 2 第二步,修改密码,可是mysql版本是5.7,按照password无法修改密码.于是直接在可视乎里加了一个password列,噩梦出现,password倒是加上了,密码列也修改成功了.skip也删除了,mysql也进去了,可是就是无法使用数据库

mysql 5.6 myisam 引擎表损坏

告警日志发现报错 2016-12-05 13:01:23 27830 [ERROR] /usr/sbin/mysqld: Table './user/t_customer' is marked as crashed and should be repaired 2016-12-05 13:01:23 27830 [ERROR] /usr/sbin/mysqld: Table './user/t_customer' is marked as crashed and should be repair

普通用户二进制安装mariadb10.1.16 mysql库表损坏修改

1)mariadb日志: 10:36:48 140397816809216 [Note] InnoDB: Dumping buffer pool(s) not yet started 2016-09-01 10:36:48 140510705071872 [Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file 

解决SMON_SCN_TO_TIME_AUX表损坏故障

同事在给客户做数据库巡检的过程中,发现其中一个数据库的alert日志中报了一个坏块的错误信息,具体如下: Reading datafile '+DATA_DW/xtdw/datafile/sysaux.295.819217697' for corruption at rdba: 0x0081140e (file 2, block 70670) Read datafile mirror 'DATA_DW_CD_05_DWCEL02' (file 2, block 70670) found same

Mysql 5.7.20 mysql innodb 系统表损坏带来的问题

早上上班后,mysql服务器遇到点小问题,在排查故障过程查看mysql错误日志过程中发现有几个innodb 表无法打开,使用desc查看有关表的表结构提示表不存在,show tables 可以查到一下五个表,以下是具体的报错信息: 2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/innodb_index_stats from the internal data dictionary of InnoDB tho