記一次mysql的重大失誤處理
今天下午，客戶端突然有人反應歷史記錄消失了，當時一臉懵逼，不知道咋回事
之後研發看了看，說那張表的數據沒有了，只有13多的，之前的數據都清空了
頓時慌了，這是把運維往死裏搞
開始解決問題
首先這是一個我們自建的數據庫，開啓了binlog，做了主從，但從庫是剛剛做的，就是前天剛做的，之前都是沒有的
不過備份了數據，數據量75G，是個全量備份，不知道怎麼能只獲取其中一張表的數據，而且消失了兩天的數據。。。
追究問題：研發寫的代碼邏輯問題，使用的是delete語句對數據庫操作，一般都會添加where條件，但沒有邏輯判斷強制where條件。（劃重點）
建議：研發禁用delete語句，改爲update語句
找到最新的binlog文件，然後對此進行分析
定位到了刪除語句delete，確實有一條沒有where條件。。。最後發現刪了不止一張表，幸好只有3張表，數據量是1w，1w，8w。數據量不大
使用mysqlbinlog mysql-bin.000057 | grep -iw “delete” 再過濾表名，定位到刪除語句，同時確定了原因就是以爲沒有加刪除條件導致的後果。
解決思路：
定位到最後一條刪除語句的position，在找到第一條的position,將binlog轉化爲sql語句，然後導入數據庫，即將刪除之前的語句進行恢復，然後導入到從庫（從庫先斷開）
備份變成insert語句，最後在主庫上執行insert插入（不確定對主鍵有沒有影響）
將對應的庫的名稱，和所執行的定位導出爲sql
mysqlbinlog mysql-bin.000057 --start-position=132161008 --stop-position=769321368 --database=xxxxxxxDb > rollback.sql
基本就是按這個操作來得，因爲沒有備份，不敢輕易在主庫上執行sql，怕對線上數據有影響，儘量使損失最小。
一個坑就是start-position點怎麼查找的。現將之前的備份導出到一個乾淨的庫，將這個庫的內容導出。然後找出當時binlog的position，最後再執行mysqlbinlog mysql-bin.000057 --start-position=132161008 --stop-position=769321368 --database=xxxxxxxDb > insert.sql 得到insert語句，再將語句在新庫上執行，然後導出數據庫，即獲得當時刪除前的所有數據，然後在導入到線上數據庫
中途有諮詢過dba和網友，給了一些建議，包括了美團開發的工具flashback，但最後還是選擇了這種方式，那幾種方法都測試失敗了，爲了穩妥，還是用了上面的方法。