誤操作引發對日常操作MySQL 的思考

  作為一名DBA需要有着嚴謹的工作态度。

      兩台測試DB  Server A, Server B， 預設存儲引擎InnoDB.有這樣一個需求：需要将A中所有的表結構同步到B中。當時是這樣做的： mysqldump -no-data......

      導出mysql表的檔案後結果又将這些檔案應用到了Server A 中，可想而知A中的 data已經被清空啦。由于是測試DB，資料量不大，用備份+binlog完全可以恢複的過來。但處于謹慎，得出第一個總結：對于新增加的表或者修改表結構的情況，要應用到其他DB的話，最好使用上 --skip-add-drop-table(甯原有重複表的報錯，也不要産生删除資料的情況)

      這時候我們另一個熱心長的同學，将MySQL重新開機啦。少了一個binlog日志檔案。當時心想，資料肯定會丢失一部分。丢失binlog日志的原因是由于設定了expire_logs_days(binlog在多久之後沒有改動的話會被删除)。由此得出第二個總結：由于設定expire_logs_days 無法确定檔案删除的具體日期，改為purge binary logs 方式進行手動删除。對于線上主從複制的情況，更應如此，原先設定的expire_logs_days=15（需要檢查 各個slave應用binlog 的具體位置）

      在将binlog應用到DB中時，報duplicate key的錯誤而中斷。引起的原因是 原來的表中某個字段隻是普通索引，後來改為非唯一索引。沒有辦法隻好手動修改從binlog解析出的檔案。由此得出第三個結論：為了防止在 有schema 變更之後 恢複資料時發生錯誤，可以考慮每天進行flush logs 一次。将範圍縮減到最小。mysqlbinlog 進行解析的時候 可以單個檔案進行解析。 可以利用 confluence 類西的工具将 對表的變更做實時更新記錄。對自己的DB有充分的掌握。

       最終還是我們需要多總結，态度很重要，形成一個良好的規範。

                                                                                      2012-10-24   15：40

       對于誤删除表空間的情況，可以參考：

       http://hcymysql.blog.51cto.com/5223301/1004810

       誤删除資料可以參考使用taobao 資料閃回方案！

       http://www.penglixun.com/tech/database/mysql_flashback_feature.html

       http://www.taobaodba.com/html/1430_mysql%E7%9A%84%E6%95%B0%E6%8D%AE%E6%81%A2%E5%A4%8D.html

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1035828，如需轉載請自行聯系原作者