1. 程式人生 > >rm mysql 資料日誌檔案恢復

rm mysql 資料日誌檔案恢復

系統通過rm 誤刪除了 mysql 資料檔案或日誌: 此時如果有master/slave 或開啟了binlog 日誌還好,如果沒有就悲劇了。 但是如果此時 mysqld 程序存在,並且mysql服務未關閉,通過系統級別可恢復出來。 1,建立一張測試表: [email protected](none)) Mysql >use test; Database changed ([email protected]) Mysql >create table tab_rm_test as select * from mysql.innodb_index_stats; Query OK, 3 rows affected (0.08 sec) Records: 3 Duplicates: 0 Warnings: 0 ([email protected]) Mysql >flush privileges; Query OK, 0 rows affected (0.00 sec) (
[email protected]
) Mysql >show tables;
+----------------+ | Tables_in_test | +----------------+ | tab_rm_test | +----------------+ 1 row in set (0.00 sec) ([email protected]) Mysql >select * from tab_rm_test; +---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+ | database_name | table_name | index_name | last_update | stat_name | stat_value | sample_size | stat_description | +---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+ | test | tab_rm_test | GEN_CLUST_INDEX | 2016-08-19 08:54:47 | n_diff_pfx01 | 0 | 1 | DB_ROW_ID | | test | tab_rm_test | GEN_CLUST_INDEX | 2016-08-19 08:54:47 | n_leaf_pages | 1 | NULL | Number of leaf pages in the index | | test | tab_rm_test | GEN_CLUST_INDEX | 2016-08-19 08:54:47 | size | 1 | NULL | Number of pages in the index | +---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+ 3 rows in set (0.00 sec) 2, 系統下檢視對應的innodb 字尾 *.ibd
[[email protected] mysql]$ cd test/ [[email protected] test]$ ls tab_rm_test.frm tab_rm_test.ibd [[email protected] test]$ ll -l total 108 -rw-rw---- 1 mysql mysql 8886 Aug 19 08:54 tab_rm_test.frm -rw-rw---- 1 mysql mysql 98304 Aug 19 08:54 tab_rm_test.ibd --本次僅測試刪除*.ibd 檔案。 [[email protected]
test]$ rm tab_rm_test.ibd
[[email protected] test]$ ls tab_rm_test.frm 3, 此處很關鍵,確保mysqld 存在,同時MYSQL服務open 狀態。 [[email protected] test]$ netstat -ntlp |grep mysqld (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 :::3351 :::* LISTEN 16788/mysqld --這裡是 16788,之後執行很關鍵一步: ([email protected]) Mysql >insert into tab_rm_test select * from tab_rm_test; Query OK, 3 rows affected (0.01 sec) Records: 3 Duplicates: 0 Warnings: 0 ([email protected]) Mysql >flush privileges; Query OK, 0 rows affected (0.00 sec) --這裡做測試,即使刪除後,只要MYSQL服務存在,DML 不受影響,雖然data 不存在了。 --(這是否存在某種關係系統上,雖然刪除了,但是這個執行緒一致佔有著) 這裡接著上面 16788 標示號: [[email protected] test]$ ll /proc/16 16/ 1601/ 1612/ 16272/ 1628/ 1645/ 1661/ 16788/ [[email protected] test]$ ll /proc/16788/fd fd/ fdinfo/ [[email protected] test]$ ll /proc/16788/fd |grep 'tab_r*' lrwx------ 1 mysql mysql 64 Aug 19 09:00 71 -> /data/mysql/test/tab_rm_test.ibd (deleted) [[email protected] ~]# cd /proc/16788/fd [[email protected] fd]# ls 0 1 10 11 12 13 14 15 16 2 3 31 32 33 36 37 4 5 51 52 6 7 71 8 9 --這裡對應71 也非常重要: 4, 開始處理之前,需要考慮到mysql 執行狀態,和連線會話等。 ([email protected]) Mysql >flush tables with read lock; Query OK, 0 rows affected (0.01 sec) --這一步的作用是讓資料庫沒有寫入的操作,以便完成後面的恢復工作。 怎樣驗證沒有寫入操作,分一下幾步: ([email protected]) Mysql >show variables like 'innodb_max_dirty_pages%'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | innodb_max_dirty_pages_pct | 75 | | innodb_max_dirty_pages_pct_lwm | 0 | +--------------------------------+-------+ 2 rows in set (0.00 sec) ([email protected]) Mysql >set global innodb_max_dirty_pages_pct=0; Query OK, 0 rows affected (0.00 sec) --此引數,快速重新整理至磁碟。 然後檢視binlog 日誌寫入情況,確保FILE 和Position 的值不再變化。 ([email protected]) Mysql >show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000008 | 681 | | mysql | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) 最後檢視innodb 資訊狀態,確保髒頁已經刷入 磁碟,(確保幾項值不再變化) ([email protected]) Mysql >show engine innodb status\G; *************************** 1. row *************************** Type: InnoDB Name: Status: ===================================== 2016-08-19 09:06:17 7fafa3420700 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 27 seconds ----------------- BACKGROUND THREAD ----------------- srv_master_thread loops: 3 srv_active, 0 srv_shutdown, 188679 srv_idle srv_master_thread log flush and writes: 188682 ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 6 OS WAIT ARRAY INFO: signal count 6 Mutex spin waits 5, rounds 0, OS waits 0 RW-shared spins 6, rounds 180, OS waits 6 RW-excl spins 0, rounds 0, OS waits 0 Spin rounds per wait: 0.00 mutex, 30.00 RW-shared, 0.00 RW-excl ------------ TRANSACTIONS ------------ Trx id counter 6421 Purge done for trx's n:o < 6421 undo n:o < 0 state: running but idle ##確保後臺 purge 程序把undo log 全部清除掉,事務ID 要一致。 History list length 4 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 6420, not started MySQL thread id 8, OS thread handle 0x7fafa3420700, query id 134 localhost root init show engine innodb status -------- FILE I/O -------- I/O thread 0 state: waiting for completed aio requests (insert buffer thread) I/O thread 1 state: waiting for completed aio requests (log thread) I/O thread 2 state: waiting for completed aio requests (read thread) I/O thread 3 state: waiting for completed aio requests (read thread) I/O thread 4 state: waiting for completed aio requests (read thread) I/O thread 5 state: waiting for completed aio requests (read thread) I/O thread 6 state: waiting for completed aio requests (write thread) I/O thread 7 state: waiting for completed aio requests (write thread) I/O thread 8 state: waiting for completed aio requests (write thread) I/O thread 9 state: waiting for completed aio requests (write thread) Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] , ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 Pending flushes (fsync) log: 0; buffer pool: 0 183 OS file reads, 58 OS file writes, 28 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s ------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf: size 1, free list len 0, seg size 2, 0 merges ## insert buffer 合併插入快取等於1 merged operations: insert 0, delete mark 0, delete 0 discarded operations: insert 0, delete mark 0, delete 0 Hash table size 276671, node heap has 0 buffer(s) 0.00 hash searches/s, 0.00 non-hash searches/s --- LOG --- Log sequence number 1641009 Log flushed up to 1641009 Pages flushed up to 1641009 Last checkpoint at 1641009 ## 確保這4個值不再變化。 0 pending log writes, 0 pending chkp writes 18 log i/o's done, 0.00 log i/o's/second ---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 137363456; in additional pool allocated 0 Dictionary memory allocated 66358 Buffer pool size 8191 Free buffers 8013 Database pages 178 Old database pages 0 Modified db pages 0 ##確保髒頁數量為 0 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 0, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 167, created 11, written 39 0.00 reads/s, 0.00 creates/s, 0.00 writes/s No buffer pool page gets since the last printout Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 178, unzip_LRU len: 0 I/O sum[0]:cur[0], unzip sum[0]:cur[0] -------------- ROW OPERATIONS -------------- 0 queries inside InnoDB, 0 queries in queue 0 read views open inside InnoDB Main thread process no. 16788, id 140392328288000, state: sleeping Number of rows inserted 6, updated 0, deleted 0, read 15 0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s ---------------------------- # 確保插入,更新,刪除為0 END OF INNODB MONITOR OUTPUT ============================ 1 row in set (0.00 sec) ERROR: No query specified 4, 確認工作完成後,就可以進行恢復操作: [[email protected] fd]# cp 71 /data/mysql/test/tab_rm_test.ibd [[email protected] fd]# cd /data/mysql/test/ [[email protected] test]# ls tab_rm_test.frm tab_rm_test.ibd [[email protected] test]# ls -l total 108 -rw-rw---- 1 mysql mysql 8886 Aug 19 08:54 tab_rm_test.frm -rw-r----- 1 root root 98304 Aug 19 09:08 tab_rm_test.ibd [[email protected] test]# chown mysql:mysql *.ibd [[email protected] test]# chmod 660 tab_rm_test.ibd [roo[email protected] test]# ll -l total 108 -rw-rw---- 1 mysql mysql 8886 Aug 19 08:54 tab_rm_test.frm -rw-rw---- 1 mysql mysql 98304 Aug 19 09:08 tab_rm_test.ibd [[email protected] test]# su - mysql [[email protected] ~]$ /etc/init.d/mysqld restart Shutting down MySQL.... SUCCESS! rm: cannot remove `/var/lock/subsys/mysql': Permission denied Starting MySQL. SUCCESS! ([email protected]) Mysql >use test; Database changed ([email protected]) Mysql >show tables; +----------------+ | Tables_in_test | +----------------+ | tab_rm_test | +----------------+ 1 row in set (0.00 sec) ([email protected]) Mysql >select count(*) from tab_rm_test; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec) -----------THE END------------

相關推薦

rm mysql 資料日誌檔案恢復

系統通過rm 誤刪除了 mysql 資料檔案或日誌: 此時如果有master/slave 或開啟了binlog 日誌還好,如果沒有就悲劇了。 但是如果此時 mysqld 程序存在,並且mysql服務未關閉,通過系統級別可恢復出來。 1,建立一張測試表: [email&#

[MySQL] 利用 MySql日誌檔案 恢復資料

2. 要想通過日誌恢復資料庫,在你的my.cnf檔案裡應該有如下的定義,log-bin=mysql-bin,這個是必須的.binlog-do-db=db_test,這個是指定哪些資料庫需要日誌,如果有多個數據庫就每行一個,如果不指定的話預設就是所有資料庫. [mysqld]  log-bin=mysql

mysql從.ibd檔案恢復資料

最簡單的只需要4步1.建立一張表,表結構與原表結構一致:CREATE TABLE <table_name> ...;2.刪除新建的表空間: ALTER TABLE <table_name> DISCARD TABLESPACE;3.將待恢復的<t

記一次MySQL資料誤刪-恢復體驗

資料誤刪了怎麼辦?本文也許能給您一定的提示。 一、檢視日誌 資料無意中發現不見了,怎麼辦? 也許首先想到的是去查日誌,找到問題原因,但是這個時間有可能會比較長,並且線上的業務在這段時間會收到影響。 因此,先不要去管什麼原因,首先應該做的第一件事情應當是資料恢復,保證正常的業務不受影響,而後再回過來查詢原

mysql資料備份與恢復

#資料備份 或 恢復 #將classwork的資料備份到F盤 檔案命名為classwork.sql doc命令 #預設方式備份 mysqldump -uroot -proot function_cl

資料日誌檔案實時收集框架Flume介紹及其使用

大資料中,我們經常會將一些日誌檔案收集分析,比如網站的日誌檔案等等,我們需要一個工具收集資料並且上傳到HDFS,HIVE,HBASE等大資料倉庫中,Apache為我們提供了一個很好的檔案實時收集框架供我們使用。 一、Flume的介紹 官網的介紹如下:

mysql-bin日誌檔案過大導致磁碟空間不足問題解決方法

在MySQL資料庫中,mysql-bin.000001、mysql- bin.000002等檔案是資料庫的操作日誌,例如UPDATE一個表,或者DELETE一些資料,即使該語句沒有匹配的資料,這個命令也會儲存到日誌檔案中,還包括每個語句執行的時間,也會記錄進去的。 這樣做主

RMAN備份與恢復系列之redo日誌檔案恢復

實驗環境 作業系統 Redhat5.4 x86 資料庫版本 oracle 11gR2 (11.2.0.1.0) 實驗前已經做了RMAN全量備份包括controlfile、spfile 實驗模擬 1. INACTIVE日誌組部分member成員損

MySQL二進位制日誌檔案過期天數設定說明

mysql> set global expire_logs_days=100; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> show warnings; +---------+------+-------------------

mysql 重要日誌檔案總結

作者:丁儀 來源:https://chengxuzhixin.com/blog/post/mysql_zhong_yao_ri_zhi_wen_jian_zong_jie.html 日誌是所有應用的重要資料,MySQL 也有錯誤日誌、查詢日誌、慢查詢日誌、事務日誌等。本文簡單總結下各種日誌,以備查閱。 二

檢視MySQL日誌資料binlog檔案

binlog介紹 binlog,即二進位制日誌,它記錄了資料庫上的所有改變. 改變資料庫的SQL語句執行結束時,將在binlog的末尾寫入一條記錄,同時通知語句解析器,語句執行完畢. binlog格式 基於語句,無法保證所有語句都在從庫執行成功,比如update ... lim

MySQL僅從.frm和.ibd檔案恢復資料

前言 MySQL的資料庫其相關檔案都會存放在安裝目錄下data資料夾下的同命資料夾中,不同的儲存引擎建立的表其檔案也不一樣,下面來認識

mysql InnoDB idata1檔案損壞,單個恢復表格資料

伺服器異常斷電,導致mysql某一個table .idb檔案損壞,在idata1頁存在異常損壞; 在開啟mysql服務一開啟就之後據自動關閉,提示異常服務終端異常; mysql資料維護人員一定要有定時備份資料,利用mysql worhbench 的management

使用.iba檔案恢復mysql資料庫資料

在liunx上操作的 測試資料庫名稱:testdb 恢復的表名:testtable 1、停止mysql  (service mysqld stop)服務,my.conf 加上    innodb_force_recovery=1 ,啟動mysql  (service

MySQL資料庫、系統盤中的大檔案日誌檔案放到掛載資料盤的方法

系統盤中的大檔案 tomcat的日誌檔案 mysql的資料庫 或者 其他大檔案 都可以使用如下方法 1已知資料庫的安裝目錄為“/usr/local/java/mysql”,而資料存放目錄則在“/usr/local/java/data/mysql”中. 2進入“

Mysql 二進位制日誌恢復資料

前幾天因為一個應用系統需要更新,不小心手一抖把自己的部落格的資料庫給刪了,資料庫也沒有備份,當時心裡那個毛焦火辣啊,還好在網上說可以用binlog恢復資料,還好還好,哈哈。 原文地址:小時刻個人技術部落格:http://small.aiweimeng.top/index.php/arc

MySQL如何利用ibd檔案恢復資料

前言 資料庫丟失之痛 磁碟壞道、斷電等意外不是常態,但遇上了就足夠你“驚心動魄”! 如果是資料庫損壞造成的資料丟失,Binlog也不可用了,怎麼辦?~~ 為了在短時間內無損恢復資料以保證業務穩定性,除了利用binlog,我們還修煉了一招新的恢復技能! 正文 還記得我們之前寫過的《只需一招,讓失控的研

mysql 通過data檔案下來恢復資料

補充:正常情況下,建議資料庫備份最好用工具進行備份,通過拷貝資料庫表進行資料遷移,不同的環境會出現各種不同的意外問題。 背景:今天在整理一個網站的時候,作業系統由於系統自動更新導致一直出現系統藍屏宕機,唉,悲劇了,於是重新安裝了系統 windows server 200

mysql通過mysql-bin檔案恢復資料

mysql-bin00xxx檔案(/var/lib/mysql/mysql-bin00xxx)是資料庫的操作日誌檔案,一定情況下可以利用操作日誌檔案來恢復資料,例如一個表中之前插入了1條資料,之後給誤刪除了,這時可以在操作日誌檔案找到之前插入的資料,以此來恢復資料。 my

Oracle資料庫資料檔案rm -rf誤刪除後恢復

Oracle資料庫中表空間的資料檔案在基於OS系統級別被rm -rf 刪除後,只要資料庫在刪除後一直未被shutdown,那麼就可以手動恢復,恢復的前提是Oracle安裝在Linux系統下,下面是一個例項模擬 1. 在資料庫open的時候,直接刪除users表空間中的