1. 簡述恢復原理
因為文檔中較為詳細的描述,這裡只簡單說明。所有InnoDB的數據都是索引的方式組織的,而且所有的數據都是存儲在16KB的數據塊中。恢復的過程分幾步,分解所有數據文件為單個16KB大小的頁面,根據每個頁面的標記的數據起點開始嘗試匹配,如果與給定表定義的size合適,認為匹配成功,則輸出記錄。
2. 並行的恢復
數據恢復通常是爭分奪秒的,PDRTI工具本身是一個基礎工具,如果使用該工具做做串行恢復,時間會非常長,通過簡單的shell腳本可以讓constraints_parser腳本並行工作,這樣可以大大縮短數據的恢復時間。根據實際經驗,機器稍微好點,實際恢復時間可以縮短到串行的二十分之一。也就是說,原來需要40小時,通過並行可能2個小時就可以了。
以下是兩個並行恢復的腳本,供參考:
代碼如下 復制代碼#!/bin/bash
ws=/u01/recovery
pagedir=/u01/recovery/pages-1372436970/FIL_PAGE_INDEX
logdir=/u01/recovery/log
rectool=/u01/recovery/percona-data-recovery-tool-for-innodb-0.5/constraints_parser
cd `dirname $rectool`
count=0
page_count=353894
page_done=0
startdate=`date +%s`
for d1 in `ls $pagedir`
do
count=$(($count+1))
echo "in page $d2 at dir $d1" > $logdir/$count.log
thedate=`date +%s`
echo "$page_done / $page_count at $thedate from $startdate"
total=`ls -l $pagedir/$d1/|wc -l`
page_done=$(($page_done+$total))
threads=`ps axu|grep parser_jobs|grep -v grep|wc -l`
echo $threads
while [ $threads -gt 48 ];
do
sleep 1
threads=`ps axu|grep parser_jobs|grep -v grep|wc -l`
done
$ws/parser_jobs.sh $pagedir/$d1 > $ws/job.log 2>&1 &
done#!/bin/bash
pagedir=/u01/recovery/pages-1372436970/FIL_PAGE_INDEX
logdir=/u01/recovery/log
rectool=/u01/recovery/percona-data-recovery-tool-for-innodb-0.5/constraints_parser
logfile="$logdir/`basename $1`.log"
echo "$1" > $logfile
if [ -d $1 ];then
for d2 in `ls $1`
do
$rectool -5 -f $1/$d2 >> $logfile 2>/dev/null
done
fi
3. 從索引中恢復
如果知道數據表的索引結構,如果數據部分損壞,但是索引部分完整,可以通過這個辦法提取出來更多的字段信息。
4. 緊急情況下的問題處理
這次下廚房的技術總結中提到,"第一時間停止MySQL防止硬盤繼續寫入這個應急措施是錯誤的",正常如果進程沒有被關閉,進程所打開的文件是不會被覆蓋的,可以通過從/proc文件系統拷貝的方式恢復出當前仍然打開的文件(參考:Recovering files from /Proc)。如果數據文件和日志文件都能夠cp出來,那麼有希望讓MySQL自己啟動,並根據事務日志恢復出當前一致的數據。