一、資料庫為什麼會被刪？
同事小L最近負責整理資料庫初始化指令碼，在匯出演示環境的資料庫指令碼後，在另外的伺服器上執行該資料庫指令碼，最後由於操作的時候開啟的視窗過多，沒有注意到環境，當時他開啟了很多視窗，有演示環境，也有自己試驗環境，也有開發環境，一堆視窗，最後執行的時候發現執行錯了，將演示環境給幹掉了，演示環境有我們大量的資料，主要用於給客戶演示用的，資料非常重要。
二、資料庫被刪後，第一時間採取的措施是什麼？
資料庫被刪後，第一時間採取的措施是想辦法恢復，但由於binlog未開啟以及定時備份資料庫指令碼也沒有，最後無法恢復，只得經理採取一些措施來解決這個問題了。
三、我的反思以及從中發現存在哪些問題？
雖然說直接責任人並不是我，但我對此也有一定的間接責任。
這次刪庫事件我發現最大的問題就是資料庫安全策略做的不夠全面。資料庫安全策略包含物理安全、訪問控制、資料備份等。
1.物理安全
物理安全是安全防範的基本，主要是指保證資料庫伺服器、資料庫所在環境、相關網路的物理安全性。
2.訪問控制
訪問控制是基本安全性的核心。它包括了帳號管理、密碼策略、許可權控制、使用者認證等方面，主要是從與帳號相關的方面來維護資料庫的安全性。
3.資料備份
定期的進行資料備份是減少資料損失的有效手段，能讓資料庫遭到破壞(惡意或者誤操作)後，恢復資料資源。這也是資料庫安全策略的一個重要部分。
這次問題主要出在訪問控制和資料備份上面。訪問控制沒有做好，導致開發人員人人都能對演示環境(演示環境等同於生產環境)、測試環境、開發環境的資料庫進行庫的CRUD以及庫中的表CRUD等。通常來說，資料庫以及資料庫中的表以及具體欄位不能隨意進行新增、刪除、修改等，特別是對於等同於生產環境的演示環境。
訪問控制只是資料庫安全策略的一種手段，但這種手段還需與資料備份相結合，才能稱的上是雙重保障。
四、針對發現的問題我的解決辦法是什麼？
針對訪問控制層面，我的解決辦法是:
以演示環境(等同於生產環境)為例，限制資料庫為內網訪問且對應的使用者只能訪問所授權的資料庫，命令如下:
GRANT ALL PRIVILEGES ON 資料庫名稱.* TO '資料庫特定使用者'@'192.168.52.317' IDENTIFIED BY '資料庫特定使用者密碼' WITH GRANT OPTION; FLUSH PRIVILEGES; EXIT;
如果其它微服務需要連線該資料庫但又處於不同的伺服器環境下，也可通過上面ip進行控制，只不過需要新建對應的使用者。
因為一些需求可能需要公網訪問該資料庫，也可以採取上面的措施進行，目的是為了更精細化的控制許可權。
也許有人覺得敲命令來控制似乎很麻煩，別擔心，有一個工具就已經替我們解決了這個問題(資料庫訪問控制)，那就是phpmyadmin。
關於Linux配置安裝phpmyadmin，可以參考我寫的如下文章:
Ubuntu16.04下安裝配置phpmyadmin
nginx上配置phpmyadmin
centos7之安裝wordpress（雖然是安裝wordpress，不過這裡用到的是在phpmyadmin裡建庫以及新增使用者授權等）
針對資料備份層面，我的解決辦法是兩個:
第一個，定期備份，指令碼自動化備份(需結合定時任務)，感興趣的朋友可以閱讀我的這篇文章:mysql常用備份命令和shell備份指令碼
，
為防止萬一加一個定期打包備份的sql指令碼並遠端傳輸到另外一臺伺服器上面，關於遠端壓縮傳輸檔案可以參考我的這篇文章:
Linux遠端傳輸檔案免密碼
Linux關於壓縮和解壓縮例項
。
第二個，實時備份，從資料庫本身入手，開啟binlog。
在my.conf配置如下即可:
[mysqld] # 開啟binlog log-bin=mysql-bin server-id=1 binlog_format=ROW
修改完配置記得重啟mysql。
登入mysql檢視binlog是否開啟，執行如下命令即可:
show variables like 'log_%';
效果圖如下(說明binlog已開啟):
就目前來說，我已經落地了兩個，一個是實時備份(開啟binlog)，另外一個是定時備份(結合指令碼和定時任務)。
五、總結
不經意間想起了歐陽修寫的《五代史伶官傳序》其中有一句我印象很深刻，”夫禍患常積於忽微，而智勇多困於所溺”。在此之前已經就有了一個前車之鑑，一位Java同事的阿里雲伺服器因資料庫密碼過於簡單被黑客綁架(需要花比特幣才能贖回)，當時針對此我採取了一些措施，但措施並不全面，這次刪庫事件或許就是來自之前的警告。