建站
咨詢
售后
建站咨詢
新聞中心
MySQL是一個流行的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，它提供了高可用性和可擴(kuò)展性，使得它成為處理大型數(shù)據(jù)集的首選工具。但在使用MySQL時，不可避免地會遇到一些問題，比如意外刪除了一個數(shù)據(jù)庫。這時，需要找到合適的方法來恢復(fù)誤刪的數(shù)據(jù)庫。
創(chuàng)新互聯(lián)建站專注于岫巖企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計,商城系統(tǒng)網(wǎng)站開發(fā)。岫巖網(wǎng)站建設(shè)公司,為岫巖等地區(qū)提供建站服務(wù)。全流程按需制作網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)
1. 備份恢復(fù)
如果您定期備份數(shù)據(jù)庫，則可以使用備份來恢復(fù)誤刪的數(shù)據(jù)庫。停止MySQL服務(wù)，然后將備份文件復(fù)制到存放數(shù)據(jù)文件的目錄。接著，啟動MySQL服務(wù)并運行以下命令：
“`
mysql -u root -p
“`
輸入密碼后，運行以下命令：
“`
mysql> source /var/lib/mysql/backupfile.sql
“`
其中，backupfile.sql是您剛剛復(fù)制到MySQL數(shù)據(jù)目錄的備份文件名。運行該命令后，數(shù)據(jù)庫將被還原為備份文件的狀態(tài)。
2. 日志恢復(fù)
如果數(shù)據(jù)庫誤刪后沒有備份文件，可以使用MySQL的日志文件進(jìn)行恢復(fù)。MySQL使用二進(jìn)制日志文件（binlog）來記錄數(shù)據(jù)庫中的所有更改。因此，我們可以通過查看binlog文件中的記錄來還原誤刪的數(shù)據(jù)庫。以下是恢復(fù)誤刪的數(shù)據(jù)庫的步驟：
停止MySQL服務(wù)，并找到MySQL數(shù)據(jù)目錄中的binlog文件。默認(rèn)情況下，在Ubuntu系統(tǒng)中，binlog文件位于/var/log/mysql/mysql-bin.*。您可以使用以下命令查找binlog文件：
“`
mysql> SHOW BINARY LOGS;
“`
此命令將顯示所有可用的MySQL二進(jìn)制日志文件。選擇最近的binlog文件，然后使用以下命令查看所有的更新記錄：
“`
mysqlbinlog /var/lib/mysql/mysql-bin.00000X > /tmp/updates.sql
“`
其中，mysql-bin.00000X是binlog文件名，/tmp/updates.sql是輸出文件名。運行以上命令后，將生成一個包含所有更新記錄的SQL文件。您可以修改該文件以刪除誤刪除的內(nèi)容，然后執(zhí)行以下命令將記錄重新應(yīng)用到數(shù)據(jù)庫中：
“`
mysql
“`
運行該命令后，數(shù)據(jù)庫將被還原到誤刪之前的狀態(tài)。
3. 數(shù)據(jù)恢復(fù)工具
如果以上兩種方法都不能恢復(fù)誤刪的數(shù)據(jù)庫，您可以嘗試使用數(shù)據(jù)恢復(fù)工具。有很多數(shù)據(jù)恢復(fù)工具可用于MySQL，如EaseUS Data Recovery Wizard和Disk Drill等。
這些工具使用高級算法掃描MySQL數(shù)據(jù)目錄，并嘗試從損壞、刪除、格式化或分區(qū)丟失的文件中恢復(fù)誤刪的數(shù)據(jù)庫。雖然這些工具可能不是100%成功，但它們可能是你的最后一條救命稻草。
MySQL誤刪數(shù)據(jù)庫是常見的錯誤之一，但它并不是不可逆轉(zhuǎn)。備份恢復(fù)、日志恢復(fù)和數(shù)據(jù)恢復(fù)工具是三種可用的方法，可以幫助您解決這個問題。在使用MySQL時，建議定期備份數(shù)據(jù)庫，并確保有一個有效的恢復(fù)策略。
相關(guān)問題拓展閱讀：
- 把mysql數(shù)據(jù)庫刪了，請問可以恢復(fù)嗎
- Mysql Innodb數(shù)據(jù)庫誤刪除了文件，怎么恢復(fù)？
把mysql數(shù)據(jù)庫刪了，請問可以恢復(fù)嗎
1.如果有備份，洞春兆恢復(fù)備份數(shù)據(jù)就可以。
2.如果在企業(yè)管理器里刪除了數(shù)據(jù)庫，如果有備份，恢納租復(fù)備份數(shù)據(jù)就可以。
3. 如果你是在程序里卸載sql程序，數(shù)據(jù)就在sql安裝目錄里，附加數(shù)據(jù)庫就可以了。
4.如果備份數(shù)據(jù)都沒有，可以找個硬盤數(shù)據(jù)恢復(fù)森鍵公司。
2.如者伏果在企業(yè)管理器里刪除了數(shù)據(jù)庫，如果有備份，恢復(fù)備份數(shù)據(jù)就可以。3.如果你是在程序里卸載sql程序，數(shù)據(jù)就在sql安首明攜裝槐賣目錄里，附加數(shù)據(jù)庫就可以了。
每個 DBA 是不是都有過刪庫的經(jīng)歷？刪庫了沒有備份怎散高么辦？備份恢復(fù)后無法啟動服務(wù)什么情況？表定義損壞數(shù)據(jù)無法讀取怎么辦？
我曾遇到某初創(chuàng)互聯(lián)網(wǎng)企業(yè)，因維護(hù)人員不規(guī)范的備份恢復(fù)操作，導(dǎo)致系統(tǒng)表空間文件被初始化，上萬張表無法讀取，花了數(shù)小時才搶救回來。
當(dāng)你發(fā)現(xiàn)數(shù)據(jù)無法讀取時，也許并非數(shù)據(jù)丟失了，可能是 DBMS 找不到描述數(shù)據(jù)的信息。
背景
先來了解下幾張關(guān)鍵的 InnoDB 數(shù)據(jù)字典表，衫基它們保存了部分表定義信息，在我們恢復(fù)表結(jié)構(gòu)時需要用到。
SYS_TABLES 描述 InnoDB 表信息CREATE TABLE `SYS_TABLES` (`NAME` varchar(255) NOT NULL DEFAULT ”, 表名`ID` bigint(20) unsigned NOT NULL DEFAULT ‘0’, 表id`N_COLS` int(10) DEFAULT NULL,`TYPE` int(10) unsigned DEFAULT NULL,`MIX_ID` bigint(20) unsigned DEFAULT NULL,`MIX_LEN` int(10) unsigned DEFAULT NULL,`CLUSTER_NAME` varchar(255) DEFAULT NULL,`SPACE` int(10) unsigned DEFAULT NULL, 表空間idPRIMARY KEY (`NAME`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_INDEXES 描述 InnoDB 索引信息CREATE TABLE `SYS_INDEXES` ( `TABLE_ID` bigint(20) unsigned NOT NULL DEFAULT ‘0’, 與sys_tables的id對應(yīng) `ID` bigint(20) unsigned NOT NULL DEFAULT ‘0’, 索引id `NAME` varchar(120) DEFAULT NULL,索引名稱 `N_FIELDS` int(10) unsigned DEFAULT NULL, 索引包含字段的個數(shù) `TYPE` int(10) unsigned DEFAULT NULL, `SPACE` int(10) unsigned DEFAULT NULL, 存儲索引的表空間id `PAGE_NO` int(10) unsigned DEFAULT NULL, 索引的root page id PRIMARY KEY (`TABLE_ID`,`ID`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_COLUMNS 描述 InnoDB 表沖塌尺的字段信息CREATE TABLE `SYS_COLUMNS` ( `TABLE_ID` bigint(20) unsigned NOT NULL, 與sys_tables的id對應(yīng) `POS` int(10) unsigned NOT NULL, 字段相對位置 `NAME` varchar(255) DEFAULT NULL, 字段名稱 `MTYPE` int(10) unsigned DEFAULT NULL, 字段編碼 `PRTYPE` int(10) unsigned DEFAULT NULL, 字段校驗類型 `LEN` int(10) unsigned DEFAULT NULL, 字段字節(jié)長度 `PREC` int(10) unsigned DEFAULT NULL, 字段精度 PRIMARY KEY (`TABLE_ID`,`POS`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_FIELDS 描述全部索引的字段列CREATE TABLE `SYS_FIELDS` ( `INDEX_ID` bigint(20) unsigned NOT NULL, `POS` int(10) unsigned NOT NULL, `COL_NAME` varchar(255) DEFAULT NULL, PRIMARY KEY (`INDEX_ID`,`POS`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;./storage/innobase/include/dict0boot.h 文件定義了每個字典表的 index id，對應(yīng) id 的 page 中存儲著字典表的數(shù)據(jù)。
這里我們需要借助 undrop-for-innodb 工具恢復(fù)數(shù)據(jù)，它能讀取表空間信息得到 page，將數(shù)據(jù)從 page 中提取出來。
# wget yum install -y gcc flex bison# make# make sys_parser
# ./sys_parser 讀取表結(jié)構(gòu)信息
sys_parser databases/table
stream_parser 讀取 InnoDB page 從 ibdata1 或 ibd 或分區(qū)表
# ./stream_parserYou must specify file with -f optionUsage: ./stream_parser -f Where: -hPrint this help -V or -g – Print debug information -s size – Amount of memory used for disk cache (allowed examples 1G 10M). Default 100M -Tretrieves only pages with index id = NM (N – high word, M – low word of id) -t size – Size of InnoDB tablespace to scan. Use it only if the parser can’t determine it by himself.
c_parser 從 innodb page 中讀取記錄保存到文件
# ./c_parserError: Usage: ./c_parser -4|-5|-6 -f -t table.sql Where -f — InnoDB page or directory with pages(all pages should have same index_id) -t — CREATE statement of a table -o — Save dump in this file. Otherwise print to stdout -l — Save SQL statements in this file. Otherwise print to stderr -h — Print this help -d — Process only those pages which potentially could have deleted records (default = NO) -D — Recover deleted rows only (default = NO) -U — Recover UNdeleted rows only (default = YES) -V — Verbose mode (lots of debug information)innodb_datafile is in REDUNDANT formatinnodb_datafile is in COMPACT formatinnodb_datafile is in MySQL 5.6 format -T — retrieves only pages with index id = NM (N – high word, M – low word of id) -b — Directory where external pages can be found. Usually it is pages-XXX/FIL_PAGE_TYPE_BLOB/ -i — Read external pages at their offsets from . -p prefix — Use prefix for a directory name in LOAD DATA INFILE command
接下來，我們演示場景的幾種數(shù)據(jù)恢復(fù)場景。
場景1：drop table
是否啟用了 innodb_file_per_table 其恢復(fù)方法有所差異，當(dāng)發(fā)生誤刪表時，應(yīng)盡快停止MySQL服務(wù)，不要啟動。若 innodb_file_per_table=ON，更好只讀方式重新掛載文件系統(tǒng)，防止其他進(jìn)程寫入數(shù)據(jù)覆蓋之前塊設(shè)備的數(shù)據(jù)。
如果評估記錄是否被覆蓋，可以表中某些記錄的作為關(guān)鍵字看是否能從 ibdata1 中篩選出。
# grep WOODYHOFFMAN ibdata1
Binary file ibdata1 matches
也可以使用 bvi（適用于較小文件）或 hexdump -C（適用于較大文件）工具
以表 sakila.actor 為例CREATE TABLE `actor` (`actor_id` allint(5) unsigned NOT NULL AUTO_INCREMENT,`first_name` varchar(45) NOT NULL,`last_name` varchar(45) NOT NULL,`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`actor_id`),KEY `idx_actor_last_name` (`last_name`)) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8
首先恢復(fù)表結(jié)構(gòu)信息1. 解析系統(tǒng)表空間獲取 page 信息
./stream_parser -f /var/lib/mysql/ibdata1
2. 新建一個 schema，把系統(tǒng)字典表的 DDL 導(dǎo)入
cat dictionary/SYS_* | mysql recovered
3. 創(chuàng)建恢復(fù)目錄
mkdir -p dumps/default
4. 解析系統(tǒng)表空間包含的字典表信息，
./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/01.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2> dumps/default/SYS_TABLES.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/02.page -t dictionary/SYS_COLUMNS.sql > dumps/default/SYS_COLUMNS 2> dumps/default/SYS_COLUMNS.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/03.page -t dictionary/SYS_INDEXES.sql > dumps/default/SYS_INDEXES 2> dumps/default/SYS_INDEXES.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/04.page -t dictionary/SYS_FIELDS.sql > dumps/default/SYS_FIELDS 2> dumps/default/SYS_FIELDS.sql
5. 導(dǎo)入恢復(fù)的數(shù)據(jù)字典
cat dumps/default/*.sql | mysql recovered
6. 讀取恢復(fù)后的表結(jié)構(gòu)信息
./sys_parser -pmsandbox -d recovered sakila/actor
由于 5.x 版本 innodb 引擎并非完整記錄表結(jié)構(gòu)信息，會丟失 AUTO_INCREMENT 屬性、二級索引和外鍵約束， DECIMAL 精度等信息。
若是 mysql 5.5 版本 frm 文件被從系統(tǒng)刪除，在原目錄下 touch 與原表名相同的 frm 文件，還能讀取表結(jié)構(gòu)信息和數(shù)據(jù)。若只有 frm 文件，想要獲得表結(jié)構(gòu)信息，可使用 mysqlfrm –diagnostic /path/to/xxx.frm，連接 mysql 會顯示字符集信息。
innodb_file_per_table=OFF
因為是共享表空間模式，數(shù)據(jù)頁都存儲在 ibdata1，可以從 ibdata1 文件中提取數(shù)據(jù)。
1. 獲取表的 table id，sys_table 存有表的 table id，sys_table 表 index id 是1，所以從01.page 獲取表 id./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/01.page -t dictionary/SYS_TABLES.sql | grep sakila/actorB28 2AD4D SYS_TABLES “sakila/actor” 0 “”B28 2AD4D SYS_TABLES “sakila/actor” 0 “” 0
2. 利用 table id 獲取表的主鍵 id，sys_indexes 存有表索引信息，innodb 索引組織表，找到主鍵 id 即找到數(shù)據(jù)，sys_indexes 的 index id 是3，所以從03.page 獲取主鍵 id
./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/03.page -t dictionary/SYS_INDEXES.sql | grepBABCA SYS_INDEXES”PRIMARY”BAC3C SYS_INDEXES”idx_actor_last_name”BABCA SYS_INDEXES”PRIMARY”BAC3C SYS_INDEXES”idx_actor_last_name”
3. 知道了主鍵 id，就可以從對應(yīng) page 中提取表數(shù)據(jù)，并生成 sql 文件。
./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/76.page -t sakila/actor.sql > dumps/default/actor 2> dumps/default/actor_load.sql
4. 最后導(dǎo)入恢復(fù)的數(shù)據(jù)
cat dumps/default/*.sql | mysql sakila
更多詳細(xì)情況點擊
網(wǎng)頁鏈接
Mysql Innodb數(shù)據(jù)庫誤刪除了文件，怎么恢復(fù)？
數(shù)據(jù)非常重要的話建議還是找專業(yè)的地方恢復(fù)，自己嘗試恢復(fù)的話很可能導(dǎo)致數(shù)據(jù)損壞無法恢復(fù)的
經(jīng)常性備份，如果binlog在的話，試試看……
– 恢復(fù)策略
前面說到未提交的事務(wù)和回滾了的事務(wù)也會記錄Redo Log，因此在進(jìn)行恢復(fù)時,這些事務(wù)要進(jìn)行特殊的的處理.有2中不同的恢復(fù)策略：
A. 進(jìn)行恢復(fù)時，只重做已經(jīng)提梁襪如交了的事務(wù)。
B. 進(jìn)行恢復(fù)時，重做所有事務(wù)包括未提交的事務(wù)和回滾了的事務(wù)。然后通過Undo Log回滾那些未提交的事務(wù)。
– InnoDB存儲引擎的恢復(fù)機(jī)制
MySQL數(shù)據(jù)庫InnoDB存儲引擎使用了B策略, InnoDB存儲引擎中的恢復(fù)機(jī)制有幾個特點：
A. 在重做Redo Log時，并不關(guān)心事務(wù)性。 恢復(fù)時，沒有BEGIN，也沒有COMMIT,ROLLBACK的行為。也不關(guān)心每個日志是哪個事務(wù)的。盡管事務(wù)ID等事務(wù)相關(guān)的內(nèi)容會記入Redo Log，這些內(nèi)容只是被當(dāng)作要操作的數(shù)據(jù)的一部分。
B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫Redo Log之前將對應(yīng)的Undo Log寫入磁盤。Undo和Redo Log的這種關(guān)聯(lián)，使得持久化變得復(fù)雜起來。為了降低復(fù)雜度，InnoDB將Undo Log看好燃作數(shù)據(jù)，因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以像數(shù)據(jù)一樣緩存起來，而不用再redo log之前寫入磁盤了。
包含Undo Log操作的Redo Log，看起來是這樣的：
記錄1: >
記錄2:
記錄3: >
記錄4:
記錄5: >
記錄6:
C. 到這里，還有一個問題沒有弄清楚。既然Redo沒有事務(wù)性，那豈不是會重新執(zhí)行被回滾了的事務(wù)？確實是這樣。同時Innodb也會將事務(wù)回滾時的操作也記錄到redo log中?；貪L操作本質(zhì)上也是對數(shù)據(jù)進(jìn)行修改，因此回滾時對數(shù)據(jù)的操作也會記錄到Redo Log中。
一個回滾了的事務(wù)的Redo Log，看起來是這樣的：
記錄1: >
記錄2:
記錄3: >
記錄4:
記錄5: >
記錄6:
記錄7:
記錄8:
記錄9:
一個被回滾了的事務(wù)在恢復(fù)時的操作就是先redo再undo，因此不會破壞數(shù)據(jù)的一致性.
– InnoDB存儲引擎中相關(guān)的函數(shù)
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
還原也是有節(jié)點的，
既然只有前5、6天的備份，那腔此搜還原的話也只能還原到前伍歷5、扒燃6天的情況了。
個人認(rèn)為：重要的數(shù)據(jù)備份的頻率更好調(diào)高一點，以免出現(xiàn)問題時造成不必須的損失。
bin-log也沒了嗎
mysql回復(fù)誤刪數(shù)據(jù)庫的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于mysql回復(fù)誤刪數(shù)據(jù)庫,解決方法：MySQL誤刪數(shù)據(jù)庫后如何恢復(fù)？,把mysql數(shù)據(jù)庫刪了，請問可以恢復(fù)嗎,Mysql Innodb數(shù)據(jù)庫誤刪除了文件，怎么恢復(fù)？的信息別忘了在本站進(jìn)行查找喔。
創(chuàng)新互聯(lián)網(wǎng)絡(luò)推廣網(wǎng)站建設(shè)，網(wǎng)站設(shè)計，網(wǎng)站建設(shè)公司，網(wǎng)站制作，網(wǎng)頁設(shè)計，1500元定制網(wǎng)站優(yōu)化全包，先排名后付費，已為上千家服務(wù)，聯(lián)系電話：13518219792
標(biāo)題名稱：解決方法：MySQL誤刪數(shù)據(jù)庫后如何恢復(fù)？(mysql回復(fù)誤刪數(shù)據(jù)庫)
本文URL：http://www.5511xx.com/article/djoisje.html
