0. 數據庫運維作些什麼

一. 數據庫生命週期
結合軟件生命週期、項目的開展，數據庫的生命週期大體可分爲這麼幾個階段。

1. 規劃
在立項後，對於數據庫平臺的軟硬件選型，以及大體的數據庫架構。
1.1 配置多少臺服務器，服務器的內存大小/磁盤空間、IOPS/CPU核數/網絡帶寬等；
1.2 選擇的操做系統/數據庫產品/第三方工具，及相應版本；
1.3 總體架構，好比是否考慮：HA, Scale out, load balance, 讀寫分離等策略。

2. 開發
開發的工做，一般是在開發/測試環境上進行的，測試結束後搬到生產環境。
2.1 數據庫設計；
2.2 SQL編程及調試；
2.3 開發過程當中的SQL優化。

3. 實施
開發的數據庫程序到生產環境的部署。到這裏，基本是項目上線了。後面就進入了運維階段。
3.1 前期規劃時數據庫物理架構的部署；
3.2 開發/測試完成的數據庫程序部署。

二. 運維作些什麼
從上面的圖來看，運維是項目上線後的工做。看看從項目上線開始，運維都作了什麼。
1. 部署環境
1.1 數據庫安裝（若是服務器太多，能夠選擇靜默安裝）；
1.2 參數配置（操做系統、數據庫實例、數據庫參數）；
1.3 權限分配（登陸、數據庫用戶權限）。

2. 備份/還原
對於數據庫來講，有個可用的備份是很是重要的，防止有數據損壞，用戶誤操做等形成的數據丟失。保證了數據的存在，運維纔有意義，不然其餘工做作的再好也是白搭。

3. 監控
對於運維來講，首先要保證數據庫的運行，而後就是運行中系統的性能。因此監控主要分爲這兩點：
3.1 數據庫運行狀態，有沒有什麼數據庫中斷或異常、錯誤或警告？
3.2 數據庫性能，有沒有什麼性能問題或者性能隱患？

4. 故障處理
在監控過程當中發現，或者系統用戶反饋出來的數據庫錯誤或者警告，進行診斷並修復。

5. 性能優化
在監控過程當中發現，或者系統用戶反饋出來的數據庫性能問題，進行優化。

6. 容災
容災只是手段，最終仍是爲了保證系統的可用性，一般選擇的策略有：故障轉移集羣、鏡像、日誌傳送、異地備份等。
若是在實施時，已經部署了容災策略，那麼這時只要作一些狀態監視便可。
也有系統是在上線一段時間以後，才補充部署容災策略的。

7. 升級/遷移
7.1 升級
一般是在本機進行，硬件不變，好比：更換操做系統、數據庫的版本、打補丁；
7.2 遷移
一般是須要升級硬件，好比：更換新的服務器，因此把數據庫搬到新的服務器上；
也有在本機「遷移」，只是爲了移動數據庫文件的位置。
7.3 遷移+升級
不過不少時候，都是在遷移中作升級，也就是換了新的服務器，也換了軟件版本。

8. 健康檢查
一般叫作巡檢或者Health Check。多是天天、每個月、每一年的。
事實上若是把巡檢的內容作到天天、每小時、甚至每X分鐘，那就是一個準實時的系統監控。

9. 系統用戶反饋的數據庫問題
用戶反饋出來的任何數據庫問題，須要DBA去作處理，即使有時診斷出來並不是數據庫的問題。
從廣義上來看，除去數據庫開發外的其餘任務，都應該算在運維職責以內。

問：那麼數據庫運維到底都有哪些平常任務？
答：把上面的每項任務要作的事情一個個羅列出來就能夠了。
好比，3.1 數據庫運行狀態監控包括：
(1) 數據庫服務器是否可用；
(2) 數據庫服務是否啓用/中斷；
(3) 磁盤空間；
(4) 錯誤日誌檢查；
(5) 數據庫一致性檢查；
(6) 做業運行狀態；
(7) 索引碎片檢查
(8) ……
後面會逐個分解各項任務的詳細清單。

三. 運維過程當中的問題解決
運維過程當中遇到問題時，若是可以經過本身/他人的經驗解決，那麼當然好；

但若是沒有解決思路的話，一般是這樣去查：
1. 查日誌：操做系統/數據庫/應用程序日誌中，有沒有相關的錯誤/信息提示；
2. 查錯誤號：官方文檔/網友分享中，有沒有解決方案；
3. 若是都沒有找到，那麼就中獎了，本身分析不出就團隊分析，團隊分析不出找官方支持，固然有的時候，官方支持也不是必定能解決。

注意：對於在線系統，這麼慢慢查下去，時間可能消耗過久，會影響用戶體驗。一般是優先快速解決問題，那怕只是用臨時應急方案，以保證系統的可用性，而後再去分析根本緣由，以完全解決，防止下次再發生。