drop table 命令，通過 binlog 傳所有從庫(kù)和級(jí)聯(lián)從庫(kù)，整個(gè)集群都執(zhí)行
一、誤刪行
第 24 篇文章?delete 誤刪行，F(xiàn)lashback 恢復(fù)，binlog 拿回原庫(kù)重放。前提binlog_format=row 和 binlog_row_image=FULL。
1.? insert ， binlog event類型是 Write_rows event，改成 Delete_rows event?
2.? delete ，Delete_rows event 改為 Write_rows event；
3.? ?Update_rows ，binlog 記錄數(shù)據(jù)行修改前、后值，對(duì)調(diào)
不是一個(gè)，而是多個(gè)，下面三個(gè)事務(wù)：
(A)delete ...(B)insert ...(C)update ...
Flashback 工具解析 binlog 后，寫回主庫(kù)命令：順序調(diào)過來再執(zhí)行
(reverse C)update? ...(reverse B)delete? ...(reverse A)insert? ...
1.1 不在主庫(kù)上執(zhí)行
恢復(fù)出備份或臨時(shí)庫(kù)，臨時(shí)庫(kù)恢復(fù)回主庫(kù)。
主庫(kù)變更往往是有關(guān)聯(lián)的。發(fā)現(xiàn)數(shù)據(jù)問題的時(shí)間晚了，之前誤操作基礎(chǔ)上，又繼續(xù)修改其他數(shù)據(jù)。單獨(dú)恢復(fù)這幾行數(shù)據(jù)，未經(jīng)確認(rèn)的話，二次破壞。
1.2 事前預(yù)防建議：
1.? sql_safe_updates = on。delete 或update 沒寫 where 條件，或where 里沒包含索引執(zhí)行報(bào)錯(cuò)。
2.? 上線前， SQL 審計(jì)
1.3 sql_safe_updates=on小表數(shù)據(jù)全部刪掉，怎么辦？
(1)delete加上 where 條件，delete 全表很慢，需生成回滾日志、寫 redo、寫 binlog。
(2)truncate table 或者 drop table?，性能好，沒法通過 Flashback 恢復(fù)。
即使binlog_format=row，執(zhí)行這三個(gè)命令時(shí)， binlog 還是 statement 格式。只有truncate/drop 語句，不能恢復(fù)。
二、誤刪庫(kù) / 表
2.1 恢復(fù)條件 &流程：
條件：（1）定期全量備份，加增量日志，（2）實(shí)時(shí)備份 binlog
1.? 最近一次全量備份（一天一備，上次 0 點(diǎn), 中午 12 點(diǎn)誤刪庫(kù)）,恢復(fù)臨時(shí)庫(kù)
2.? binlog日志備份，取出凌晨 0 點(diǎn)之后日志；應(yīng)用臨時(shí)庫(kù)(除誤刪除語句)
2.2操作
1.? 加速：臨時(shí)庫(kù)上多個(gè)庫(kù)，用 mysqlbinlog 命令時(shí)，加–database 參數(shù)，指定誤刪表所在庫(kù)。避免用其他庫(kù)日志。
2.? 跳過 12 點(diǎn)誤操作語句 binlog：
原實(shí)例沒用 GTID ，誤操作之前–stop-position，再–start-position?誤操作后日志執(zhí)行；
用GTID 模式，誤操作命令 GTID 是 gtid1，執(zhí)行 set gtid_next=gtid1;begin;commit; 先把GTID 加到臨時(shí)實(shí)例 GTID 集合，按順序執(zhí)行 binlog 時(shí)自動(dòng)跳過誤操作。
2.3 不夠快原因&辦法：
1. 誤刪表，重放表， mysqlbinlog 不能指定只解析一個(gè)表日志；
2. 解析日志單線程。第 26 篇文章并行復(fù)制的方法，用不上。
加速方法：恢復(fù)臨時(shí)庫(kù)后，臨時(shí)實(shí)例設(shè)置成線上備庫(kù)的從庫(kù)：
start slave 前，執(zhí)行change replication filter replicate_do_table = (tbl_name) 命令，臨時(shí)庫(kù)只同步誤操作表；?用上并行復(fù)制加速
虛線，備庫(kù)刪除binlog ，從 binlog 備份系統(tǒng)中找，再放回備庫(kù)中。
需要binlog 從master.000005 開始的，備庫(kù)上最小master.000007，少兩個(gè)binlog文件。binlog 備份系統(tǒng)中找。 放回：
1.? 備份系統(tǒng)下載 master.000005 和master.000006 這兩個(gè)文件，放備庫(kù)日志目錄；
2.? 日志目錄下的 master.index 文件，開頭加兩行“./master.000005”和“./master.000006”;
3.? 重啟備庫(kù)，讓備庫(kù)重新識(shí)別，正常同步
不可能備份無限，設(shè)定日志保留天數(shù)。做成自動(dòng)化工具，經(jīng)常演練。
三、延遲復(fù)制備庫(kù)
“恢復(fù)時(shí)間不可控”：備份特別大，誤操作時(shí)間距離全量備份時(shí)間長(zhǎng)，一周一備，第 6 天發(fā)生誤操作
搭建延遲復(fù)制的備庫(kù)
延遲復(fù)制備庫(kù)： CHANGE MASTER TO MASTER_DELAY = N 命令，備、主庫(kù) N 秒延遲。
N = 3600，1 小時(shí)內(nèi)發(fā)現(xiàn)，備庫(kù)上執(zhí)行 stop slave，跳過誤操作，恢復(fù)數(shù)據(jù)，縮短時(shí)間。
四、預(yù)防誤刪庫(kù) / 表的方法
（1）不給 truncate/drop 權(quán)限。只讀賬號(hào)，
（2）制定操作規(guī)范：
刪表之前，改表名（加固定后綴_to_be_deleted），確保無影響
管理系統(tǒng)執(zhí)行。只能刪除固定后綴表。
五、rm 刪除數(shù)據(jù)
刪某節(jié)點(diǎn)：HA 系統(tǒng)開始工作，選新主庫(kù)，節(jié)點(diǎn)恢復(fù)接入集群。
全軍覆沒：備份跨機(jī)房（跨城市）。
小結(jié)
預(yù)防遠(yuǎn)比處理意義大：定期檢查備份
show grants 看權(quán)限，過大降低權(quán)限；和 DBA 商量備份周期、是否創(chuàng)建延遲復(fù)制的備庫(kù)
誤刪數(shù)據(jù)事件，什么方法恢復(fù)數(shù)據(jù)呢？經(jīng)驗(yàn)？
從瀏覽器拷貝文本執(zhí)行（不規(guī)范），SQL?截?cái)?/b>（還可能亂碼），執(zhí)行出錯(cuò)。
開發(fā)和執(zhí)行不是一個(gè)人，開發(fā)把腳本及?md5?放git 上，發(fā)給執(zhí)行同學(xué)，執(zhí)行命令之前，確認(rèn) md5。
評(píng)論1
修改生產(chǎn)數(shù)據(jù)，或者添加索引優(yōu)化，先寫好四個(gè)腳本：驗(yàn)證、執(zhí)行、備份、回滾腳本。
升級(jí)mongodb，備份數(shù)據(jù)文件時(shí)，備份指向數(shù)據(jù)文件的軟連接(當(dāng)時(shí)沒注意是軟連接)，刪除后，備份數(shù)據(jù)文件恢復(fù)數(shù)據(jù)時(shí)找不到文件，才發(fā)現(xiàn)備份的是軟連接，
解決辦法：備份節(jié)點(diǎn)恢復(fù)chatrr +i 命令給所有重要文件增加了 i 權(quán)限屬性， root 用戶都無法直接刪除。
評(píng)論2
誤truncate表：
1、創(chuàng)建同版本空mysql實(shí)例，建名字+結(jié)構(gòu)一樣表
2、discard表tablespace
3、之前備份集中 innobackupex --apply-log 并記錄binlog位置（用innobackupex備份的）。還原后找到誤操作表的.ibd文件，copy到新實(shí)例對(duì)應(yīng)位置
4、創(chuàng)建mysql實(shí)例上import tablespace
5、用mysqlbinlog 處理增量數(shù)據(jù)，導(dǎo)出 再導(dǎo)入
評(píng)論3
更新少條件，全表更新，用的是pg，當(dāng)時(shí)dba說沒發(fā)恢復(fù)。業(yè)務(wù)核心表，6000多條。有本地緩存，更新會(huì)發(fā)通知刷新，不要刷緩存。瀏覽器一個(gè)地址下去，內(nèi)存數(shù)據(jù)全部返回瀏覽了。。。
