關於MySQL啟動時,丟失資料檔案不報錯的現象
最近,我做了一個實驗,就是想驗證mysql在丟失表資料檔案的情況下,資料庫是否能正常啟動,發現啟動正常。
個人感覺mysql這麼做不太安全,因為管理員可能都不知道丟失資料檔案了。不過,還好,可以觀察錯誤日誌檔案來發現丟失資料檔案的資訊。所以,我們在啟動mysql的過程中,一定別忘了仔細觀察錯誤日誌檔案,以便及時發現資料庫潛在問題。
下面就是我的過程:
1、關閉MySQL資料庫
[root@drbd-01 db1]# service mysqld stop
Shutting down MySQL (Percona Server).......................[確定]...
2、刪除MySQL的一個資料檔案
[root@drbd-01 db1]# cd /data/mysql/data/db1
[root@drbd-01 db1]# mv t1.ibd t1.ibd.bak
[root@drbd-01 db1]# mv t1.frm t1.frm.bak
[root@drbd-01 db1]# ls
db.opt t1.frm.bak t1.ibd.bak
3、重新啟動MySQL
[root@drbd-01 db1]# service mysqld start
Starting MySQL (Percona Server).............................................................. [確定]
在丟失資料檔案 t1.ibd的情況下,資料庫居然啟動起來了(這在oracle裡面簡直是不允許的)
4、驗證
(root@localhost)[(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| db1 |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.17 sec)
(root@localhost)[(none)]> use db1;
Database changed
(root@localhost)[db1]> show tables;
Empty set (0.00 sec)
發現t1表果真不存在了。
(root@localhost)[db1]> create table t1 (id int);
ERROR 1813 (HY000): Tablespace for table '`db1`.`t1`' exists. Please DISCARD the tablespace before IMPORT.
又不讓建立t1表,好尷尬。
5、檢視錯誤日誌(還好錯誤日誌告訴我們資料檔案曾經存在但現在丟了)
[root@drbd-01 db1]# tail -100 /data/mysql/logs/mysql-error.log
InnoDB: directories yourself, InnoDB does not create them.
2016-01-08 16:43:12 10462 [ERROR] InnoDB: Could not find a valid tablespace file for 'db1/t1'. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2016-01-08 16:43:12 10462 [ERROR] InnoDB: Tablespace open failed for '"db1"."t1"', ignored.
2016-01-08 16:43:12 10462 [Note] InnoDB: 128 rollback segment(s) are active.
2016-01-08 16:43:12 10462 [Note] InnoDB: Percona XtraDB () 5.6.27-76.0 started; log sequence number 1689915
2016-01-08 16:43:13 10462 [ERROR] InnoDB: Failed to find tablespace for table '"db1"."t1"' in the cache. Attempting to load the tablespace with space id 7.
2016-01-08 16:43:13 7f266daba700 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
2016-01-08 16:43:13 10462 [ERROR] InnoDB: Could not find a valid tablespace file for 'db1/t1'. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2016-01-08 16:43:13 10462 [Note] Server hostname (bind-address): '*'; port: 3306
2016-01-08 16:43:13 10462 [Note] IPv6 is available.
6、結論
在MySQL資料庫啟動時,管理員別忘了仔細觀察你的錯誤日誌,以便及時發現問題。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28916011/viewspace-1973991/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫啟動時丟失資料檔案模擬實驗資料庫
- 資料庫資料恢復—MongoDB資料庫檔案丟失,啟動報錯的資料恢復案例資料庫資料恢復MongoDB
- MongoDB資料庫報錯,資料庫檔案丟失資料恢復案例MongoDB資料庫資料恢復
- 關於丟失表空間資料檔案的處理方式
- . 資料庫臨時表空間的資料檔案的丟失資料庫
- 資料檔案丟失的恢復
- [求助]exp時丟失了一個資料檔案?
- 資料檔案損壞、丟失
- 模擬資料檔案丟失
- dfm檔案資料丟失問題
- 資料檔案丟失如何恢復
- 當資料檔案表空間丟失的時候怎麼恢復該資料檔案
- 關於資料庫丟失控制檔案的測試資料庫
- RMAN完全恢復丟失的資料檔案
- 普通資料檔案丟失的恢復方法
- 資料檔案丟失損壞的恢復--
- 【mysql】關於連線mysql資料庫時出現的時區錯誤time zoneMySql資料庫
- 歸檔模式下資料檔案丟失的恢復模式
- Oracle歸檔檔案丟失導致OGG不用啟動Oracle
- rman恢復:資料檔案丟失,控制檔案丟失,聯機日誌檔案丟失(非當前使用與當前使用)
- 關於建立Android工程R檔案丟失的問題Android
- 電腦檔案丟失資料恢復資料恢復
- 引數檔案控制檔案和資料檔案丟失的恢復
- 新建的表空間(或資料檔案)丟失以及控制檔案丟失,有新建表空間(或資料檔案)前的控制文
- 如何解決路由器啟動配置檔案丟失路由器
- 找回丟失的檔案
- 丟失Oracle中資料檔案Ora時的解決辦法Oracle
- 備份恢復之資料檔案丟失
- dataguard之物理備庫丟失資料檔案
- Oracle undo 表空間資料檔案丟失強制啟動資料庫(沒有未提交的事務)Oracle資料庫
- sock鎖檔案導致的MySQL啟動失敗MySql
- rman 恢復---歸檔丟失and資料檔案損壞
- 恢復測試:擁有當時的全部歸檔,控制檔案,恢復丟失的資料檔案。
- Sqlserver關於備份報錯提示某個資料檔案不線上it is not online的解決方法SQLServer
- Sql Server資料庫檔案丟失的恢復方法SQLServer資料庫
- 資料檔案丟失的恢復(改變目錄)
- 撤消表空間資料檔案丟失的恢復.
- UNDO表空間資料檔案丟失處理(二)正常關閉資料庫資料庫