一般來說資料庫集群會是主從架構：
或者主主架構：
如果此時主庫宕機，可以：
乙個從庫頂上，重建集群來保證資料的安全性與服務的可用性。流量遷移到另乙個主庫
但是，如果人為不小心執行了「刪全庫」操作，命令會同步給其他從（主）庫，導致所有庫上的資料全部丟失，這下怎麼辦呢？
可以問問自己，當這種情況發生的時候：
能不能恢復資料？（應該沒有公司不能）常見的資料庫安全性策略是：全量備份+增量備份。多久能夠恢復資料？
保證資料的安全性是dba第一要務。
全量備份：定期（例如乙個月）將庫檔案全量備份
增量備份：定期（例如每天）將binlog增量備份
如果不小心誤刪了全庫，可以這麼恢復：
（1）將最近一次全量備份的全庫找到，拷貝回來（檔案一般比較大），解壓，應用
（2）將最近一次全量備份後，每一天的增量binlog找到，拷貝回來（檔案較多），依次重放
（3）將最近一次增量備份後，到執行「刪全庫」之前的binlog找到，重放
恢復完畢。
為了保證方案的可靠性，建議定期進行恢復演練。
方案優點：能夠找回資料
方案缺點：恢復時間非常長
有沒有更優，更快恢復的方案呢？
使用1小時延時從庫，可大大加速「刪全庫」恢復時間。
什麼是1小時延時從？
增加乙個從庫，這個從庫不是實時與主庫保持同步的，而是每隔1個小時同步一次主庫，同步完之後立馬斷開1小時，這個從庫會與主庫保持1個小時的資料差距。
當「刪全庫」事故發生時，只需要：
（1）應用1小時延時從
（2）將1小時延時從最近一次同步時間到，將執行「刪全庫」之前的binlog找到，重放
快速恢復完畢。
方案優點：能夠快速找回資料
潛在不足：萬一，萬一，萬一，1小時延時從正在連上主庫進行同步的一小段時間內，發生了「刪全庫」事故，那怎麼辦咧？
使用雙份1小時延時從庫，可以避免上述「萬一，萬一，萬一」的事故發生。
什麼是雙份1小時延時從？
如圖所示，兩個1小時延時從，他們連主庫同步資料的時間「岔開半小時」。
這樣，即使乙個延時從連上主庫進行同步的一小段時間內，發生了「刪全庫」事故，依然有另乙個延時從保有半小時之前的資料，可以實施快速恢復。
方案優點：沒有萬一，都能快速恢復資料
潛在不足：資源利用率有點低，為了保證資料的安全性，多了2臺延時從，降低了從庫利用率
1小時延時從也不是完全沒有用，對於一些「允許延時」的業務，可以使用1小時延時從，例如：
（1）運營後台，產品後台
（2）bi進行資料同步
（3）研發進行資料抽樣，調研
但需要注意的是，畢竟這是從庫，只能夠提供「唯讀」服務喲。
保證資料的安全性是dba第一要務，需要進行：
（1）全量備份+增量備份，並定期進行恢復演練，但該方案恢復時間較久，對系統可用性影響大
（2）1小時延時從，雙份1小時延時從能極大加速資料庫恢復時間
（3）個人建議1小時延時從足夠，後台唯讀服務可以連1小時延時從，提高資源利用率
參考
快速備份，還原資料庫。
備份資料庫，backup database csq to disk d csq.bak with format,name 放款前 資料庫離線 alter database csq set offline with rollback immediate 還原由backup備份的資料庫 restore ...
MySQL 資料備份與還原
一 資料備份 1 使用mysqldump命令備份 mysqldump命令將資料庫中的資料備份成乙個文字檔案。表的結構和表中的資料將儲存在生成的文字檔案中。mysqldump命令的工作原理很簡單。它先查出需要備份的表的結構，再在文字檔案中生成乙個create語句。然後，將表中的所有記錄轉換成一條ins...
MySQL 資料備份與還原
1 使用mysqldump命令備份 mysqldump命令將資料庫中的資料備份成乙個文字檔案。表的結構和表中的資料將儲存在生成的文字檔案中。mysqldump命令的工作原理很簡單。它先查出需要備份的表的結構，再在文字檔案中生成乙個create語句。然後，將表中的所有記錄轉換成一條insert語句。然...