标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
分类目录归档:MySQL恢复
[MySQL异常恢复]mysql delete 数据恢复
在mysql(innodb引擎)中,有些时候犹豫误操作导致表中数据被删除,从而导致不可挽回的损失,本文模拟在数据库被误delete的情况下,实现较为完美删除,当然在实际中可能有少量不覆盖或者无法恢复回来,但是在覆盖不多或者未覆盖的情况下,可以实现绝大多数甚至全部恢复.因此在发生误操作时候,应当第一时间保护现场,尽可能防止复写导致不可挽回的损失.在测试恢复过程中,由于mysql和操作系统编码问题,折腾了很久,感谢Lunar的指点
创建模拟表并插入数据
mysql> CREATE TABLE `sms_send_record_del` ( -> `messageId` varchar(30) NOT NULL, -> `tokenId` varchar(20) NOT NULL, -> `mobile` varchar(14) default NULL, -> `msgFormat` int(1) NOT NULL, -> `msgContent` varchar(1000) default NULL, -> `scheduleDate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -> `deliverState` int(1) default NULL, -> `deliverdTime` timestamp NOT NULL default '0000-00-00 00:00:00', -> PRIMARY KEY (`messageId`) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Query OK, 0 rows affected (0.00 sec) mysql> insert into sms_send_record_del select * from sms_send_record; Query OK, 11 rows affected (0.00 sec) Records: 11 Duplicates: 0 Warnings: 0 mysql> checksum table sms_send_record_del; +---------------------------------+------------+ | Table | Checksum | +---------------------------------+------------+ | sms_service.sms_send_record_del | 2258631583 | +---------------------------------+------------+ 1 row in set (0.00 sec) mysql> checksum table sms_send_record; +-----------------------------+------------+ | Table | Checksum | +-----------------------------+------------+ | sms_service.sms_send_record | 2258631583 | +-----------------------------+------------+ 1 row in set (0.00 sec)
确定innodb文件对应位置
mysql> SHOW VARIABLES LIKE 'datadir'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | datadir | /var/lib/mysql/ | +---------------+-----------------+ 1 row in set (0.00 sec) mysql> SHOW VARIABLES LIKE 'innodb_file_per_table'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | OFF | +-----------------------+-------+ 1 row in set (0.00 sec) mysql> SHOW VARIABLES LIKE 'innodb_data_file_path'; +-----------------------+------------------------+ | Variable_name | Value | +-----------------------+------------------------+ | innodb_data_file_path | ibdata1:10M:autoextend | +-----------------------+------------------------+ 1 row in set (0.00 sec)
删除表记录
模拟错误操作,误删除表所有数据
mysql> delete from sms_send_record_del; Query OK, 11 rows affected (0.00 sec)
解析ibdata1文件
[root@web103 mysql_recovery]# ./stream_parser -f /var/lib/mysql/ibdata1 Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 Opening file: /var/lib/mysql/ibdata1 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 File information: total size, in bytes: 161480704 (154.000 MiB) ID of device containing file: 2049 Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 File information: ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) Opening file: /var/lib/mysql/ibdata1 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 File information: blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 ID of device containing file: 2049 inode number: 1344553 protection: 100660 (regular file) number of hard links: 1 user ID of owner: 27 group ID of owner: 27 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 315712 time of last access: 1440599559 Wed Aug 26 22:32:39 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) time of last access: 1440601884 Wed Aug 26 23:11:24 2015 time of last modification: 1440601853 Wed Aug 26 23:10:53 2015 time of last status change: 1440601853 Wed Aug 26 23:10:53 2015 total size, in bytes: 161480704 (154.000 MiB) Size to process: 161480704 (154.000 MiB) All workers finished in 0 sec
分析数据字典
mysql> show tables -> ; +----------------+ | Tables_in_test | +----------------+ | SYS_COLUMNS | | SYS_FIELDS | | SYS_INDEXES | | SYS_TABLES | +----------------+ 4 rows in set (0.00 sec) mysql> select * from SYS_TABLES; +----------------------------------------+----+-------------+------+--------+---------+--------------+-------+ | NAME | ID | N_COLS | TYPE | MIX_ID | MIX_LEN | CLUSTER_NAME | SPACE | +----------------------------------------+----+-------------+------+--------+---------+--------------+-------+ | recover/t_delete | 74 | 2 | 1 | 0 | 0 | | 0 | | recover/t_delete1 | 84 | 2 | 1 | 0 | 0 | | 0 | | recover/t_xifenfei | 75 | 2 | 1 | 0 | 0 | | 0 | | recover/zx_users | 89 | 85 | 1 | 0 | 0 | | 0 | | sms_service/sms_send_record | 36 | 8 | 1 | 0 | 0 | | 0 | | sms_service/sms_send_record_del | 90 | 8 | 1 | 0 | 0 | | 0 | | SYS_FOREIGN | 11 | -2147483644 | 1 | 0 | 0 | | 0 | | SYS_FOREIGN_COLS | 12 | -2147483644 | 1 | 0 | 0 | | 0 | | test/SYS_COLUMNS | 86 | 7 | 1 | 0 | 0 | | 0 | | test/SYS_FIELDS | 88 | 3 | 1 | 0 | 0 | | 0 | | test/SYS_INDEXES | 87 | 7 | 1 | 0 | 0 | | 0 | | test/SYS_TABLES | 85 | 8 | 1 | 0 | 0 | | 0 | | test/zx_users | 43 | 85 | 1 | 0 | 0 | | 0 | | xifenfei/t_delete | 44 | 8 | 1 | 0 | 0 | | 0 | | xifenfei/t_xifenfei | 59 | 2 | 1 | 0 | 0 | | 0 | +----------------------------------------+----+-------------+------+--------+---------+--------------+-------+ 39 rows in set (0.00 sec) mysql> select * from SYS_INDEXES WHERE TABLE_ID=90; +----------+-----+---------+----------+------+-------+---------+ | TABLE_ID | ID | NAME | N_FIELDS | TYPE | SPACE | PAGE_NO | +----------+-----+---------+----------+------+-------+---------+ | 90 | 110 | PRIMARY | 1 | 3 | 0 | 2955 | +----------+-----+---------+----------+------+-------+---------+ 1 row in set (0.00 sec)
找回被删除记录
[root@web103 mysql_recovery]# ./c_parser -5Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000110.page \ [root@web103 mysql_recovery]# -t dictionary/sms_send_record_del.sql >/tmp/t_1.txt 2>/tmp/t_1.sql
加载数据并验证
mysql> use sms_service; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> source /tmp/t_1.sql Query OK, 0 rows affected (0.00 sec) Query OK, 11 rows affected, 8 warnings (0.01 sec) Records: 11 Deleted: 0 Skipped: 0 Warnings: 8 mysql> checksum table sms_send_record_del; +---------------------------------+------------+ | Table | Checksum | +---------------------------------+------------+ | sms_service.sms_send_record_del | 2258631583 | +---------------------------------+------------+ 1 row in set (0.00 sec)
发生误操作之时,请尽可能保护现场,防止覆盖导致无可挽回的损失.
[MySQL异常恢复]恢复数据字典表讲解
在以前的文章中说过mysql的数据字典的恢复(使用工具直接抽取MySQL数据字典,缺少SYS_FIELDS表),主要的数据字典有一下几个,在本文中主要对这些数据字典的意义进行一些讲解,为大家更深一步了解mysql恢复处理思路
MySQL恢复字典表
mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | SYS_COLUMNS | | SYS_FIELDS | | SYS_INDEXES | | SYS_TABLES | +----------------+ 4 rows in set (0.00 sec)
SYS_TABLES
这个表是mysql恢复的最核心的表之一,主要是记录数据库在InnoDB中表的信息。它默认写在InnoDB的index_ids为1的里面,它的根页在8号page上,他的主要列结构为:
mysql> desc SYS_TABLES; +--------------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+---------------------+------+-----+---------+-------+ | NAME | varchar(255) | NO | PRI | | | | ID | bigint(20) unsigned | NO | | 0 | | | N_COLS | int(10) | YES | | NULL | | | TYPE | int(10) unsigned | YES | | NULL | | | MIX_ID | bigint(20) unsigned | YES | | NULL | | | MIX_LEN | int(10) unsigned | YES | | NULL | | | CLUSTER_NAME | varchar(255) | YES | | NULL | | | SPACE | int(10) unsigned | YES | | NULL | | +--------------+---------------------+------+-----+---------+-------+ 8 rows in set (0.00 sec)
NAME:顾名思义,就是表的名字,但是注意他记录的格式是db/table,例如:xifenfei/zx_users,表示为xifenfei数据库中的zx_users表
ID:表的编号
N_COLS:表一共包含的列的数量
TYPE, MIX_ID, MIX_LEN 和 CLUSTER_NAME列,对于数据库恢复无任何意义不做描述
SPACE:表空间的标示列. 例如: ibdata1 是 SPACE 0, ibdata2 是 SPACE 1, 每一个 ibd 文件都有自己的表空间标示.
SYS_INDEXES
这个也是mysql恢复的最核心表之一,主要是记录InnoDB的index信息,它默认InnoDB的index_ids为3的里面,他的主要结构为:
mysql> desc SYS_INDEXES; +----------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+---------------------+------+-----+---------+-------+ | TABLE_ID | bigint(20) unsigned | NO | PRI | 0 | | | ID | bigint(20) unsigned | NO | PRI | 0 | | | NAME | varchar(120) | YES | | NULL | | | N_FIELDS | int(10) unsigned | YES | | NULL | | | TYPE | int(10) unsigned | YES | | NULL | | | SPACE | int(10) unsigned | YES | | NULL | | | PAGE_NO | int(10) unsigned | YES | | NULL | | +----------+---------------------+------+-----+---------+-------+ 7 rows in set (0.00 sec)
TABLE_ID:表标示列,为SYS_TABLES.ID
ID:为InnoDB中的index的编号,这个在恢复中非常重要,恢复之时需要根据这个去定位具体的文件
NAME:主要表的index的名字,有PRIMARY 和 普通列的index信息,一般恢复之时我们选择PRIMARY
N_FIELDS:表名index包含列的数量,在mysql恢复中不重要
TYPE:恢复之中使用不到该列,不做说明
PAGE:用途等同SYS_TABLES.SPACE
PAGE_NO:标示为每个index的root page的page号,关于index中的page结构如下图所示
SYS_COLUMNS
这个表主要记录数据库中表的列的情况,它存储在index_id 2中.主要用它来确定需要恢复表的列的情况,如果你知道完全的列结构,该表不是MySQL恢复所必须的,它的主要结构为:
mysql> desc SYS_COLUMNS; +----------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+---------------------+------+-----+---------+-------+ | TABLE_ID | bigint(20) unsigned | NO | PRI | NULL | | | POS | int(10) unsigned | NO | PRI | NULL | | | NAME | varchar(255) | YES | | NULL | | | MTYPE | int(10) unsigned | YES | | NULL | | | PRTYPE | int(10) unsigned | YES | | NULL | | | LEN | int(10) unsigned | YES | | NULL | | | PREC | int(10) unsigned | YES | | NULL | | +----------+---------------------+------+-----+---------+-------+ 7 rows in set (0.00 sec)
TABLE_ID:表标示列,为SYS_TABLES.ID
POS:该列所在表中的位置,该值从0开始
NAME:列的名字
MTYPE 和 PRTYPE:主要是为了记录列的类型,出现此类问题主要是由于InnoDB最初并不是为MySQL而设计,到了后面为更好支持MySQL,因此出现了两种情况.
LEN:列的长度.这个需要注意编码,比如数据库是utf8编码,定义的varchar(10),实际该处长度显示为30,因为每个除英文外的字符编码为3个byte.
PREC:有些特殊类型中,列的精确度定义
SYS_FIELDS
记录所有index的列的分布信息,它存储在index_id 4中,该表不是MySQL恢复所必须的,它的主要结构为:
mysql> desc SYS_FIELDS; +----------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+---------------------+------+-----+---------+-------+ | INDEX_ID | bigint(20) unsigned | NO | PRI | NULL | | | POS | int(10) unsigned | NO | PRI | NULL | | | COL_NAME | varchar(255) | YES | | NULL | | +----------+---------------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
INDEX_ID:index的标志,等同SYS_INDEXES.ID
POS:列在index中的位置,从0开始
COL_NAME:列的名称
通过上述相关表和列,然后结合MySQL相关恢复工具,就可以从底层在InnoDB出现问题,或者误操作之时提供恢复处理.
MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)
昨天晚上接到一个网络服务请求,由于不小心点击了自己产品软件上面的清空数据功能(这个工具确实需要小心,在Oracle恢复案例中,也有xx企业erp该功能导致数据被删除请求恢复),导致MySQL数据库被直接drop database掉了,之前没有做任何备份,只是发生故障之后,他们立即封存现场,备份出来了ibdata1文件。接到请求之后,通过让其把ibdata1文件发给过来,通过MySQL recovery工具进行分析恢复,经过6个小时的处理,基本上实现核心数据0丢失.
解析ibdata1(innodb文件)
[root@localhost recovery_MySQL]# ./stream_parser -f /tmp/ibdata1 Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 Opening file: /tmp/ibdata1 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 File information: time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 ID of device containing file: 2055 inode number: 97257 protection: 100644 total size, in bytes: 18874368 (18.000 MiB) (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 Size to process: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: Size to process: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) time of last access: 1440083236 Thu Aug 20 23:07:16 2015 number of hard links: 1 user ID of owner: 0 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 group ID of owner: 0 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 total size, in bytes: 18874368 (18.000 MiB) Size to process: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 group ID of owner: 0 device ID (if special file): 0 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 blocksize for filesystem I/O: 4096 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 number of blocks allocated: 36920 Opening file: /tmp/ibdata1 total size, in bytes: 18874368 (18.000 MiB) File information: Size to process: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 blocksize for filesystem I/O: 4096 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 number of blocks allocated: 36920 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 Opening file: /tmp/ibdata1 total size, in bytes: 18874368 (18.000 MiB) File information: Size to process: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 Opening file: /tmp/ibdata1 File information: total size, in bytes: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 Size to process: 18874368 (18.000 MiB) (regular file) number of hard links: 1 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 user ID of owner: 0 group ID of owner: 0 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 Opening file: /tmp/ibdata1 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 device ID (if special file): 0 File information: blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 total size, in bytes: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) Size to process: 18874368 (18.000 MiB) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 Opening file: /tmp/ibdata1 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 File information: time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 ID of device containing file: 2055 total size, in bytes: 18874368 (18.000 MiB) inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 Size to process: 18874368 (18.000 MiB) group ID of owner: 0 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 device ID (if special file): 0 blocksize for filesystem I/O: 4096 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 number of blocks allocated: 36920 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 Size to process: 18874368 (18.000 MiB) File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 user ID of owner: 0 group ID of owner: 0 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 device ID (if special file): 0 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 total size, in bytes: 18874368 (18.000 MiB) Size to process: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 device ID (if special file): 0 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 blocksize for filesystem I/O: 4096 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 number of blocks allocated: 36920 total size, in bytes: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: Size to process: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: Size to process: 18874368 (18.000 MiB) ID of device containing file: 2055 inode number: 97257 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 protection: 100644 (regular file) time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 number of hard links: 1 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 total size, in bytes: 18874368 (18.000 MiB) number of blocks allocated: 36920 Size to process: 18874368 (18.000 MiB) time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Size to process: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Size to process: 18874368 (18.000 MiB) Opening file: /tmp/ibdata1 File information: ID of device containing file: 2055 inode number: 97257 protection: 100644 (regular file) number of hard links: 1 user ID of owner: 0 group ID of owner: 0 device ID (if special file): 0 blocksize for filesystem I/O: 4096 number of blocks allocated: 36920 time of last access: 1440083236 Thu Aug 20 23:07:16 2015 time of last modification: 1440062236 Thu Aug 20 17:17:16 2015 time of last status change: 1440081904 Thu Aug 20 22:45:04 2015 total size, in bytes: 18874368 (18.000 MiB) Size to process: 18874368 (18.000 MiB) All workers finished in 0 sec [root@localhost recovery_MySQL]# cd pages-ibdata1 [root@localhost pages-ibdata1]# ls -l total 16 drwxr-xr-x 2 root root 4096 Aug 20 22:53 FIL_PAGE_INDEX drwxr-xr-x 2 root root 4096 Aug 20 22:53 FIL_PAGE_TYPE_BLOB [root@localhost pages-ibdata1]# cd FIL_PAGE_INDEX [root@localhost FIL_PAGE_INDEX]# ls -l total 9924 -rw-r--r-- 1 root root 32768 Aug 20 22:53 0000000000000001.page -rw-r--r-- 1 root root 278528 Aug 20 22:53 0000000000000002.page -rw-r--r-- 1 root root 32768 Aug 20 22:53 0000000000000003.page -rw-r--r-- 1 root root 32768 Aug 20 22:53 0000000000000004.page -rw-r--r-- 1 root root 32768 Aug 20 22:53 0000000000000005.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000011.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000012.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000013.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000014.page -rw-r--r-- 1 root root 2883584 Aug 20 22:53 0000000000000065.page -rw-r--r-- 1 root root 475136 Aug 20 22:53 0000000000000066.page -rw-r--r-- 1 root root 737280 Aug 20 22:53 0000000000000067.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000068.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000069.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000070.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000071.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000072.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000073.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000074.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000075.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000076.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 0000000000000077.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000078.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000079.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000080.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000081.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000082.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000083.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000084.page -rw-r--r-- 1 root root 753664 Aug 20 22:53 0000000000000085.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000086.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000087.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000088.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000089.page -rw-r--r-- 1 root root 901120 Aug 20 22:53 0000000000000110.page -rw-r--r-- 1 root root 2097152 Aug 20 22:53 0000000000000115.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000116.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000117.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000118.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000119.page -rw-r--r-- 1 root root 49152 Aug 20 22:53 0000000000000120.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000121.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000122.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000123.page -rw-r--r-- 1 root root 98304 Aug 20 22:53 0000000000000124.page -rw-r--r-- 1 root root 16384 Aug 20 22:53 18446744069414584320.page [root@localhost FIL_PAGE_INDEX]#
分析数据字典
[root@localhost recovery_MySQL]# ./recover_dictionary.sh Generating dictionary tables dumps... OK Creating test database ... Warning: Using a password on the command line interface can be insecure. OK Creating dictionary tables in database test: SYS_TABLES ... Warning: Using a password on the command line interface can be insecure. OK SYS_COLUMNS ... Warning: Using a password on the command line interface can be insecure. OK SYS_INDEXES ... Warning: Using a password on the command line interface can be insecure. OK SYS_FIELDS ... Warning: Using a password on the command line interface can be insecure. OK All OK Loading dictionary tables data: SYS_TABLES ... Warning: Using a password on the command line interface can be insecure. 34 recs OK SYS_COLUMNS ... Warning: Using a password on the command line interface can be insecure. 3061 recs OK SYS_INDEXES ... Warning: Using a password on the command line interface can be insecure. 206 recs OK SYS_FIELDS ... Warning: Using a password on the command line interface can be insecure. 206 recs OK All OK
关于MySQL数据字典恢复,也可以参考另外一篇文章:使用工具直接抽取MySQL数据字典
查看数据库中记录情况
[root@localhost recovery_MySQL]# MySQL -uroot -p123456 Warning: Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 34954 Server version: 5.6.21 MySQL Community Server (GPL) Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MySQL> show tables; +----------------+ | Tables_in_test | +----------------+ | SYS_COLUMNS | | SYS_FIELDS | | SYS_INDEXES | | SYS_TABLES | +----------------+ 4 rows in set (0.00 sec) MySQL> SELECT NAME,ID from SYS_TABLES; +-------------------------+----+ | NAME | ID | +-------------------------+----+ | cnywmcom/zx_account_log | 31 | | cnywmcom/zx_area_code | 32 | | cnywmcom/zx_goods_group | 33 | | cnywmcom/zx_manage_type | 34 | | cnywmcom/zx_order_goods | 35 | | cnywmcom/zx_order_info | 36 | | cnywmcom/zx_param | 37 | | cnywmcom/zx_users | 46 | | cnywmcom/zx_user_type | 38 | | SYS_FOREIGN | 11 | | SYS_FOREIGN_COLS | 12 | +-------------------------+----+ 11 rows in set (0.00 sec) MySQL> select * from SYS_INDEXES; +----------+-----+-----------------+----------+------+-------+---------+ | TABLE_ID | ID | NAME | N_FIELDS | TYPE | SPACE | PAGE_NO | +----------+-----+-----------------+----------+------+-------+---------+ | 11 | 11 | ID_IND | 1 | 3 | 0 | 46 | | 11 | 12 | FOR_IND | 1 | 0 | 0 | 47 | | 11 | 13 | REF_IND | 1 | 0 | 0 | 48 | | 12 | 14 | ID_IND | 2 | 3 | 0 | 49 | | 31 | 65 | PRIMARY | 1 | 3 | 0 | 50 | | 31 | 66 | user_id | 1 | 0 | 0 | 216 | | 32 | 67 | PRIMARY | 1 | 3 | 0 | 52 | | 33 | 68 | PRIMARY | 1 | 3 | 0 | 205 | | 34 | 69 | PRIMARY | 1 | 3 | 0 | 54 | | 35 | 70 | PRIMARY | 1 | 3 | 0 | 55 | | 35 | 71 | order_id | 1 | 0 | 0 | 56 | | 35 | 72 | goods_id | 1 | 0 | 0 | 57 | | 36 | 73 | PRIMARY | 1 | 3 | 0 | 59 | | 36 | 74 | order_sn | 1 | 2 | 0 | 60 | | 36 | 75 | user_id | 1 | 0 | 0 | 61 | | 36 | 76 | order_status | 1 | 0 | 0 | 62 | | 36 | 77 | shipping_status | 1 | 0 | 0 | 63 | | 36 | 78 | pay_status | 1 | 0 | 0 | 192 | | 36 | 79 | shipping_id | 1 | 0 | 0 | 193 | | 36 | 80 | pay_id | 1 | 0 | 0 | 194 | | 36 | 81 | extension_code | 2 | 0 | 0 | 195 | | 36 | 82 | agency_id | 1 | 0 | 0 | 203 | | 37 | 83 | PRIMARY | 1 | 3 | 0 | 196 | | 38 | 84 | PRIMARY | 1 | 3 | 0 | 206 | | 46 | 120 | PRIMARY | 1 | 3 | 0 | 58 | | 46 | 121 | user_name | 1 | 2 | 0 | 256 | | 46 | 122 | email | 1 | 0 | 0 | 257 | | 46 | 123 | parent_id | 1 | 0 | 0 | 258 | | 46 | 124 | flag | 1 | 0 | 0 | 259 | +----------+-----+-----------------+----------+------+-------+---------+ 29 rows in set (0.00 sec)
通过这里,我们就可以明确的知道,我们需要恢复的表的page是多少了,这里举例说明恢复表cnywmcom.zx_account_log,我们需要去分析65号page
分析表恢复
[root@localhost recovery_MySQL]# ./c_parser -5f pages-ibdata1/FIL_PAGE_INDEX/0000000000000065.page -t dictionary/zx_account_log.sql|more -- Page id: 223, Format: COMPACT, Records list: Invalid, Expected records: (0 7) 0B0C2000101C 55000230000000 zx_account_log 2979181 270888 "0"0"0.00" "0.00" "0.00" 2147483649 "" 0 "" "0.00" "-10643256.27" "06." "06." "0782 7251.51" "0.5" "0.5" "0.5" "0.5" 000000042228 00000001040135 zx_account_log 561 1 "0.00" "0.00" "0.00" "1.00" "0.00" 1436840718 "会员注册" 99 "13818289939" "1.00" "0.00" "0.00" "0.00 " "0.00" "0.00" "0.00" "0.00" "0.00" 000000042228 0000000104015A zx_account_log 562 136 "0.00" "0.00" "0.00" "1.00" "0.00" 1436841067 "会员注册" 99 "17828025855" "1.00" "0.00" "0.00" "0.00 " "0.00" "0.00" "0.00" "0.00" "0.00" 000000042228 0000000104017F zx_account_log 563 137 "0.00" "0.00" "0.00" "1.00" "0.00" 1436842239 "会员注册" 99 "18617157667" "1.00" "0.00" "0.00" "0.00 " "0.00" "0.00" "0.00" "0.00" "0.00" 000000042228 000000010401A4 zx_account_log 564 139 "0.00" "0.00" "0.00" "1.00" "0.00" 1436846738 "会员注册" 99 "18113070688" "1.00" "0.00" "0.00" "0.00 " "0.00" "0.00" "0.00" "0.00" "0.00" 000000042228 000000010401C9 zx_account_log 565 1 "0.00" "0.00" "0.00" "1.00" "0.00" 1436848523 "会员注册" 99 "13623646573" "1.00" "0.00" "0.00" "0.00 " "0.00" "0.00" "0.00" "0.00" "0.00"
至此该表的数据已经恢复出来,剩下任务就是把数据保存为文件,并且导入到新库中.然后依次处理相关表.至此完成这次drop database的恢复.在恢复过程中,遇到不少坑,比如有些记录在对应的page中无法找到,需要进行额外处理.对于乱码问题需要进一步处理等.通过一系列的恢复,给客户恢复了所有核心表,实现核心数据0丢失.通过这次的恢复,已经证明我们不光是Oracle恢复中的行业强者,在MySQL数据库的各种故障中,我们也有立足之地.如果有MySQL数据库的恢复(误删除数据/delete,误删除表/drop table,误截断表/truncate table,误删除数据库/drop database,MySQL不能启动,ibdata1文件损坏/丢失等MySQL各种恢复)请求,如果您遇到MySQL恢复问题无法自行解决,请联系我们提供专业服务,最大程度减小您的损失:
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
发表在 MySQL恢复
标签为 ibdata1 恢复, mysql delete 恢复, mysql drop database恢复, mysql drop table 恢复, mysql truncate 恢复, MySQL恢复
评论关闭