關於mysql單表ibd文件恢復的信息

本文目錄一覽:

如何從ibd文件中恢複數據

在使用獨立表空間的情況下,如果不慎使得innodb存儲引擎的元數據文件ibdata損壞,我們還可以挽救寶貴的數據.因為在innodb使用獨立表空間的情況下,ibdata文件會記錄每個innodb表的id,只要使得ibd中的表id和ibdata文件中記錄的表id相同,就能夠打開表,讀取到數據.

#創建表

CREATE TABLE `ibdtest` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `fid` int(11) NOT NULL COMMENT ‘表b中的id’,

  `content` char(255) NOT NULL COMMENT ‘操作內容,系統生成’,

  `mark` char(255) NOT NULL COMMENT ‘備註’,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

#添加數據

INSERT ibdtest (fid,content,mark) VALUES (1,’1′,’1′),(2,’2′,’2′);

SELECT * FROM ibdtest;

關閉MySQL將ibdtest.ibd copy出來,放到其他資料庫中來模擬災難.

[root@localhost ~]#/opt/soft/mysql/bin/mysqladmin -p123456 shutdown

120130 18:31:50 mysqld_safe mysqld from pidfile /opt/soft/mysql/60137.localdomain.pid ended

[1]+ Done                    /opt/soft/mysql/bin/mysqld_safe–defaults-file=/opt/soft/mysql/config/my.cnf –user=mysql

[root@localhost ~]# cd /home/soft/mysql/data/test/

[root@localhost test]# ll

total 1296

-rw-rw—-. 1 mysql mysql  8612 Jan 18 00:06 a.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 18 00:24 a.ibd

-rw-rw—-. 1 mysql mysql  8624 Jan 30 08:34 area.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 08:36 area.ibd

-rw-rw—-. 1 mysql mysql  8642 Jan 18 00:05 b.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 18 00:08 b.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 18:27 ibdtest.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 18:28 ibdtest.ibd

-rw-rw—-. 1 mysql mysql  8728 Jan  6 16:23 testa.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 10 04:10 testa.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 14:30 testmc.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 14:30 testmc.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 13:54 testme.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 13:55 testme.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 14:40 testmm.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 14:45 testmm.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 13:40 testmu.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 13:40 testmu.ibd

-rw-rw—-. 1 mysql mysql  8693 Jan 30 11:08 testmv.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 30 11:10 testmv.ibd

-rw-rw—-. 1 mysql mysql  8694 Jan  4 21:55 testuser.frm

-rw-rw—-. 1 mysql mysql 98304 Jan  4 22:04 testuser.ibd

-rw-rw—-. 1 mysql mysql  8644 Jan 14 21:55 user.frm

-rw-rw—-. 1 mysql mysql 98304 Jan 14 21:55 user.ibd

[root@localhost test]# cp ibdtest.ibd /home/download/

[root@localhost test]# cd /home/download/

#vim打開ibd,使用16進位查看

[root@localhost download]# vim -b ibdtest.ibd 

:%!xxd

從下圖中能看到 此表在 當前mysql資料庫中的id為0x10,即16.

此時,我們假設災難發生,ibdata損壞…

只剩下了ibdtest.ibd文,我們跳轉到另一個mysql伺服器上,用同樣的建表語句創建ibdtest表.

這時我們打開這個mysql伺服器下的ibdtest.ibd看看:

這個表的id為0x16,即為22,那麼,我們只需將原有的ibdtest.ibd表id修改為0x16即可.

出保存的時候一定要記得使用:%!xxd  -r

退出保存.

並將修改好的文件覆蓋掉新的ibdtest.ibd即可,

此mysql伺服器會認為該表損毀,無法打開,沒關係,修改innodb_force_recovery = 6,

重啟mysql服務:

Select下,就知道數據是否恢復了沒有:

此時,無法執行寫操作,應儘快將數據dump出來,修改innodb_force_recovery = 0,重啟服務,創建新表後,把數據倒回去就ok了.恢複數據就不演示了.

mysql怎麼通過frm和ibd文件還原數據

有兩種方法,一種方法使用mysql的check table和repair table 的sql語句,另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。 1. check table 和 repair table 登陸mysql 終端: mysql -uxxx…

MySQL恢複數據為什麼這麼慢

MySQL 在崩潰恢復時,會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性,如果 MySQL 中包含了大量表,這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關,表總數越大,崩潰恢復時間越長。另外磁碟 IOPS 也會影響崩潰恢復時間,像這裡開發庫的 HDD IOPS 較低,因此面對大量的表空間,校驗速度就非常緩慢。另外一個發現,MySQL 8 下正常啟用時居然也會進行表空間校驗,而故障恢復時則會額外再進行一次表空間校驗,等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性,即表數量超過 5W 時,會啟用多線程掃描,加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛?查閱了資料,方法主要有兩種:

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ,那麼 validate = false,即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1,也就是強制恢復跳過壞頁,就可以跳過校驗,然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程,快速啟動 MySQL,個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了,只需要打開一個 ibdata 文件即可,大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後,感覺共享表空間在很多業務環境下,反而更有優勢。

臨時冒出另外一種解決想法,即用 GDB 調試崩潰恢復,通過臨時修改 validate 變數值讓 MySQL 跳過表空間驗證過程,然後讓 MySQL 正常關閉,重新啟動就可以正常啟動了。但是實際測試發現,如果以 debug 模式運行,確實可以臨時修改 validate 變數,跳過表空間驗證過程,但是 debug 模式下代碼運行效率大打折扣,反而耗時更長。而以非 debug 模式運行,則無法修改 validate 變數,想法破滅。

mysql資料庫怎麼恢復單個表啊?

Navicat Premium 上 可以備份單張表,備份出來的sql文件是 一些列的 insert into 語句。然後 你可以通過 date source(可能是這樣的,你百度下吧,很久之前用的了 忘記了) 這個命令在 mysql 命令 裡面 將單張表恢復。整個 資料庫備份也差不多。

記得採納啊

mysql資料庫被破壞,只剩下ibd文件時如何恢復

在使用獨立表空間的情況下,如果不慎使得innodb存儲引擎的元數據文件ibdata損壞,我們還可以挽救寶貴的數據.因為在innodb使用獨立表空間的情況下,ibdata文件會記錄每個innodb表的id,只要使得ibd中的表id和ibdata文件中記錄的表id相同,就能夠打開表,讀取到數據.

#創建表

CREATE TABLE `ibdtest` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `fid` int(11) NOT NULL COMMENT ‘表b中的id’,  `content` char(255) NOT NULL COMMENT ‘操作內容,系統生成’,  `mark` char(255) NOT NULL COMMENT ‘備註’,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

#添加數據INSERT ibdtest (fid,content,mark) VALUES (1,’1′,’1′),(2,’2′,’2′);SELECT * FROM ibdtest;

系統崩潰後,關於MYSQL恢復資料庫的問題!求救啊!

MySQL 在崩潰恢復時,會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性,如果 MySQL 中包含了大量表,這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關,表總數越大,崩潰恢復時間越長。另外磁碟 IOPS 也會影響崩潰恢復時間,像這裡開發庫的 HDD IOPS 較低,因此面對大量的表空間,校驗速度就非常緩慢。另外一個發現,MySQL 8 下正常啟用時居然也會進行表空間校驗,而故障恢復時則會額外再進行一次表空間校驗,等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性,即表數量超過 5W 時,會啟用多線程掃描,加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛?查閱了資料,方法主要有兩種:

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ,那麼 validate = false,即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1,也就是強制恢復跳過壞頁,就可以跳過校驗,然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程,快速啟動 MySQL,個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了,只需要打開一個 ibdata 文件即可,大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後,感覺共享表空間在很多業務環境下,反而更有優勢。

臨時冒出另外一種解決想法,即用 GDB 調試崩潰恢復,通過臨時修改 validate 變數值讓 MySQL 跳過表空間驗證過程,然後讓 MySQL 正常關閉,重新啟動就可以正常啟動了。但是實際測試發現,如果以 debug 模式運行,確實可以臨時修改 validate 變數,跳過表空間驗證過程,但是 debug 模式下代碼運行效率大打折扣,反而耗時更長。而以非 debug 模式運行,則無法修改 validate 變數,想法破滅。

原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/287346.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
小藍的頭像小藍
上一篇 2024-12-23 13:07
下一篇 2024-12-23 13:07

相關推薦

發表回復

登錄後才能評論