【高可用資料庫架構】
一般來說資料庫集群會是主從架構：
或者主主架構：
如果此時主庫宕機，可以：
（1）乙個從庫頂上，重建集群
（2）流量遷移到另乙個主庫
來保證資料的安全性與服務的可用性。
但是，如果人為不小心執行了「刪全庫」操作，命令會同步給其他從（主）庫，導致所有庫上的資料全部丟失，這下怎麼辦呢？
可以問問自己，當這種情況發生的時候：
（1）能不能恢復資料？（應該沒有公司不能）
（2）多久能夠恢復資料？
保證資料的安全性是dba第一要務。
【全量備份+增量備份】
常見的資料庫安全性策略是：全量備份+增量備份。
全量備份：定期（例如乙個月）將庫檔案全量備份
增量備份：定期（例如每天）將binlog增量備份
如果不小心誤刪了全庫，可以這麼恢復：
（1）將最近一次全量備份的全庫找到，拷貝回來（檔案一般比較大），解壓，應用
（2）將最近一次全量備份後，每一天的增量binlog找到，拷貝回來（檔案較多），依次重放
（3）將最近一次增量備份後，到執行「刪全庫」之前的binlog找到，重放
恢復完畢。
為了保證方案的可靠性，建議定期進行恢復演練。
方案優點：能夠找回資料
方案缺點：恢復時間非常長
有沒有更優，更快恢復的方案呢？
【1小時延時從】
使用1小時延時從庫，可大大加速「刪全庫」恢復時間。
什麼是1小時延時從？
如圖所示，增加乙個從庫，這個從庫不是實時與主庫保持同步的，而是每隔1個小時同步一次主庫，同步完之後立馬斷開1小時，這個從庫會與主庫保持1個小時的資料差距。
當「刪全庫」事故發生時，只需要：
（1）應用1小時延時從
（2）將1小時延時從最近一次同步時間到，將執行「刪全庫」之前的binlog找到，重放
快速恢復完畢。
方案優點：能夠快速找回資料
潛在不足：萬一，萬一，萬一，1小時延時從正在連上主庫進行同步的一小段時間內，發生了「刪全庫」事故，那怎麼辦咧？
【雙份1小時延時從】
使用雙份1小時延時從庫，可以避免上述「萬一，萬一，萬一」的事故發生。
什麼是雙份1小時延時從？
如圖所示，兩個1小時延時從，他們連主庫同步資料的時間「岔開半小時」。
這樣，即使乙個延時從連上主庫進行同步的一小段時間內，發生了「刪全庫」事故，依然有另乙個延時從保有半小時之前的資料，可以實施快速恢復。
方案優點：沒有萬一，都能快速恢復資料
潛在不足：資源利用率有點低，為了保證資料的安全性，多了2臺延時從，降低了從庫利用率
【提高從庫效率】
1小時延時從也不是完全沒有用，對於一些「允許延時」的業務，可以使用1小時延時從，例如：
（1）運營後台，產品後台
（2）bi進行資料同步
（3）研發進行資料抽樣，調研
但需要注意的是，畢竟這是從庫，只能夠提供「唯讀」服務喲。
【總結】
保證資料的安全性是dba第一要務，需要進行：
（1）全量備份+增量備份，並定期進行恢復演練，但該方案恢復時間較久，對系統可用性影響大
（2）1小時延時從，雙份1小時延時從能極大加速資料庫恢復時間
（3）個人建議1小時延時從足夠，後台唯讀服務可以連1小時延時從，提高資源利用率
測試之全流程質量保證
測試，只是專案過程中的乙個階段 我們不是軟體的生產者，但是我們是軟體質量的守護者。為了保證我們的產品質量，不能完全依賴於測試，或者依賴於開發 因為產品的質量不是依靠乙個團隊或乙個階段就可以保障的。我們必須在軟體生產的整個流程 每乙個階段進行控制 監管，所以我們提出了 全流程質量保證 1.需求階段 讓...
MySQL 把線上資料庫刪了怎麼辦？
寫在前面 估計二狗子這幾天是大姨夫來了，心情很鬱悶，情緒也很低落，工作的時候也有點心不在焉。讓他發個版本，結果，一行命令下去把線上的資料庫刪了！你沒聽錯 是刪掉了線上的資料庫！運營那邊頓時炸了鍋 怎麼回事？系統不能訪問了！什麼情況啊？很多客戶都在投訴了！儘管運營那邊慌慌張張的不知所措，但是，我們作為...
誤刪了公司資料庫，但我還是活下來了
專欄 九章演算法 www.jiuzhang.com 上週我與同事們進行了一次關於職業生涯中搞砸了一些事情的簡短談話。這確實會淪為他人笑柄，卻更給我們帶來了珍貴的教訓。重要的是，我們應該分享那些曾經的錯誤，這樣其他人就可以從其中學習。下文是最近在我身上發生的例子。1.為什麼有如此多誤刪生產資料庫的事情...