接著昨天的分析，今天將備份檔案拷貝到另一台ecs伺服器上進行異機恢復，花費了5個多小時（網路傳輸2個小時左右，innobackupex --copy-back3個多小時），成功恢復了資料庫。
之前懷疑是本機的ecs雲硬碟有問題，這裡將磁碟上的檔案拷貝到其他ecs伺服器上，將該塊硬碟重新分割槽（parted）和mkfs.ext4，將磁碟重新掛載到/data目錄下，從新初始化資料庫成功（之前初始化資料庫有問題），這裡成功了（有點高興，確實磁碟有問題，但什麼問題還沒有確認）。
從其他ecs上將備份的檔案拷貝回本機的/data目錄下，在拷貝檔案的同時，沒有確認雲硬碟是否正常掛載成功（還是粗心了），趕緊通過df -h和mount命令檢視一下，what？磁碟沒有掛載成功，資料庫初始化在系統盤上，拷貝回來的檔案在系統盤上，趕緊中斷了遠端拷貝（防止系統盤撐爆），再次通過mount /dev/vdb1 /data沒有報錯，但磁碟還是沒有掛載上，這裡將/dev/vdb1掛載到/data01則沒有問題，接著初始化資料庫，成功了，接著執行innobackupex 恢復資料庫，後台程序正常執行，應該是沒什麼問題了。
1、為什麼重新分割槽和格式化磁碟後，無法將磁碟掛載到原目錄(這時沒有重啟ecs伺服器試試)
2、沒有搞清楚/dev/vdb1到底出了什麼問題，導致無法通過mysql_install_db初始化資料庫(對//dev/vdb1能正常讀寫)
1、應該提前進行異機恢復，驗證備份是否有效
2、懷疑本機ecs磁碟有問題，可以將磁碟上的所有檔案拷貝到其它ecs上，對磁碟進行重新格式化測試
3、磁碟掛載時太粗心了，mount /dev/vdb /data執行後沒有立即確認，差點導致系統盤撐爆
4、ecs共享磁碟具體問題沒有排查清楚
通過阿里雲binlog備份恢復被刪除的資料
某天早上公司測試人員，寫了一條坑爹的delete from語句，沒在測試環境執行，直接在生產庫執行導致目標表資料全部被刪除 部分業務出現問題，廣告無法正常展示，需及時恢復業務。2.通過下面命令讀取binlog二進位制檔案 mysqlbinlog database prod base64 output...
阿里雲RDS資料本地恢復
阿里雲rds資料本地恢復。阿里雲 rds 資料庫在本地資料庫中恢復 將阿里雲 rds 的資料庫匯出的全量備份檔案 data.tar.gz 傳到本地 系統 centos6.2 mysql mysql 5.6.35 rds backup extract wget chmod x rds backup e...
阿里雲mysql備份資料恢復
操作只供參考，實際操作中可能出現不同的報錯或其它提示 wget 2 增加許可權 chmod x hins1540971 xtra 20160918230904.tar.gz 3 使用rds解壓指令碼，解壓rds備份檔案，如下 sh rds backup extract.sh f home hins1...