致DBA：爲何你常常犯錯，是由於你作的功課不夠

專職作DBA已經6年多的事件了，看同行、同事犯了太多的錯誤，本身也犯了很是多的錯誤。一路走來，感觸很是深。然而絕大多數的錯誤其實都是很低級的錯誤。有的是由於不瞭解某個引擎的特性致使；有的是由於對線上環境不瞭解致使；有的是由於經驗不足致使；一路上，跌跌撞撞，從小公司DBA，到騰訊高級DBA，再到如今的金融數據庫DBA。 不禁得想起5年前的我，剛進入DBA行業，缺少經驗，常常犯錯誤，不是我不夠努力，更多的是初來咋到的我根本不知道應該在哪方面下功夫。本文就是基於這方面的考慮，根據本身在DBA這個職業上走過的彎路，總結一些方法給DBA的同行。但願本文能給同行DBA或者運維的朋友們帶來一些改變，讓你們知道做爲一個DBA須要在哪些方面下功夫。下面主要從環境、數據安全、常規操做、預案、架構、心態等層面，同時也會介紹一些實用的經驗。

<1>環境篇

毫無疑問，DBA是須要綜合技能最多的一個職業，須要你有網絡、操做系統、文件系統、數據庫、安全、編程等知識。做爲DBA，爲了少犯錯誤，你首先得很是熟悉你負責的數據庫環境，大到網絡環境、系統環境、數據庫環境（這裏主要以mysql爲例）。若是不熟悉環境，很容易由於自身操做考慮不周而致使線上的故障。想一想就知道，有多少DBA由於alter操做致使的線上故障？有多少DBA忽略了字符集的問題致使了線上的亂碼？又有多少DBA因爲遷移的時候沒有備份觸發器或者event致使的故障？太多的教訓足以讓咱們全部的DBA認識到熟悉環境的重要性。另外DBA對線上環境若是足夠了解，在處理故障、討論處理方案等，都能極大地加強咱們的自信，更好地提高本身的影響力。咱們能夠說不熟悉環境的DBA不是好DBA。下面來介紹環境部分咱們DBA應該注意的問題：

一、軟件環境

1.1 操做系統環境

針對操做系統部分，你可能須要瞭解的是使用的操做系統類型，linux or windows，該系統作了哪些內核的優化，尤爲是針對數據庫，好比文件描述符、配置ntp、raid的寫cache模式等，另外你還要對系統的運行狀態有大體的瞭解，CPU使用、內存使用、IO使用以及網絡帶寬和包量的狀況。

1.2 數據庫環境

數據庫環境包含的內容就很是多了，這裏只介紹若是不瞭解比較容易形成誤操做的部分：

1.3 部署方式

對於數據庫的部署，咱們須要瞭解數據庫是如何部署的，部署在了什麼目錄，可執行文件、數據文件、log文件、配置文件等的存放路徑，數據庫如何啓動和中止等

1.4 使用引擎

瞭解目前數據庫默認使用的引擎，以及現有的表使用的引擎，提早清楚地瞭解各個引擎的特色和使用，避免在出現數據遷移、表損壞以及啓動問題手忙腳亂致使誤操做。（咱們的技術就像武器庫，都是靠平時閒淡中的積累和打造，在出問題的時候直接從武器庫拿來使用，所以要常常豐富咱們的「武器庫」）

備註：雖然如今基本使用的都是innodb引擎，可是，你也一樣能夠發現有的還用了Myisam，甚至還有的用到了memory、merge、spider、tokuDB等。

1.5 同步方式

目前mysql基本都會配置同步（若是沒有必定要加上，除非是數據丟了或者長時間故障也不要緊的庫），既然涉及到同步就會有多種不一樣的方式。好比常見的分類：

基於binlog和pos的同步

基於GTID的同步

異步

半同步

單線程同步

多線程同步

針對這些同步，都有一些不一樣的特色，好比出現問題了，須要跳過某個位置，gtid的同步和基於pos的同步操做就不同，同步方式也是你必須掌握的技巧。

1.6 版本

在維護數據庫的時候，還須要瞭解當前數據庫使用的大版本。由於數據庫的大版本的功能會有很大的差別，有不少特性是隻存在某個大版本的，所以瞭解使用的版本能讓你大體知道當前數據庫支持哪些特性。在涉及到遷移、同步、數據庫升級等操做的時候，能從容應對。

1.7 存儲過程（procedure）、事件（event）

瞭解當前數據庫是否存在存儲過程和事件，在數據備份、數據遷移的時候，須要將對應的存儲過程和事件的參數添加進去，另外若是存在事件，在遷移的時候會有特殊的操做，在遷移的目標機器要現將事件關閉，切換後再打開。防止事件致使數據不一致。

1.8 關鍵配置

mysql有幾項很是關鍵的配置，須要瞭解清楚，避免因爲配置沒搞清楚致使誤操做，總結關鍵配置以下：

innodb_buffer_pool_size

#對innodb生效，對性能影響很是大，通常能夠設置內存的50~80%

key_buffer_size

#對Myisam生效，建議修改爲innodb

innodb_flush_log_at_trx_commit

#innodb的redo日誌刷新方式，對innodb的影響會很大，通常設置爲2

log-bin

#是否開始binlog，若是沒有開啓，必定要開啓

sync_binlog

#刷binlog的方式，通常設置爲0，若是對數據須要強一致的，能夠將sync_binlog設置爲大於1的數，兼顧安全和性能

innodb_file_per_table

#採用獨立表空間，建議都設置成獨立表空間，否則後面磁盤空間滿了，刪除表空間也沒法釋放，必須作數據遷移

lower_case_table_names

#代表區分大小寫

character_set_server

#字符集在遷移、數據庫變動、數據導入等都是必需要注意的，否則數據亂碼了就會很麻煩

max_connections

#最大鏈接數不能設置太大，要計算一下session內存*max_connections + 固定內存 < 總內存-2G（這2G用來作系統內存，留給系統的內存能夠再設大一點）

transaction_isolation

#設置隔離級別，默認是Repeatable Read，若是是binlog是row模式，也常常設置爲Read Committed級別

全部上面說的參數，都須要深刻了解和熟悉，當咱們在作數據遷移的時候或者搭建mysql的時候，必定要比對一下和源實例的配置(比對工具能夠參考pt-config-diff工具)，以避免遷移完成後因爲參數不一致，中途要重啓實例的狀況。在這個問題上，我見過太多的教訓，但願你們能吸收教訓，減小故障和問題的發生。

1.9 數據庫環境收集工具介紹

前面咱們介紹了數據庫的相關的環境，對於那麼多的環境變量，咱們如何更好的去收集，這裏給你們介紹一個工具

pt-mysql-summary

這個工具的具體用法能夠google瞭解，也能夠訪問以下連接瞭解，不在本文的論述範圍：

https://www.percona.com/doc/percona-toolkit/2.1/pt-mysql-summary.html

二、硬件

硬件相關的信息也是咱們須要關注的，針對每種硬件咱們都會有大體的QPS、TPS等指標，這個對於新上業務的評估以及評估如今數據庫的瓶頸頗有幫助，對於硬件你須要告終CPU核數、內存的大小、硬盤的介質（SAS？ PCIE SSD ？NVME SSD？），最好對線上的常見機型都有詳細的壓測數據。瞭解每一種機型在mysql中的表現，也是體現DBA專業度的一個指標。

常常有DBA因爲不瞭解各個機型大體能支撐的性能 ，在方案選型和設備選型討論中，沒法確定地確認具體須要什麼設備，當前的設備配置是否能抗住對應的訪問量，致使領導和開發對該DBA的專業度大打折扣。若是你們在平常工做中有空閒的機器，不妨使用sysbench、mysqlslap、fio等工具搗鼓一下。

三、運行狀態

做爲DBA，咱們還須要瞭解如今的實例的運行狀態，以下幾個指標都是咱們須要瞭解的：

數據庫數據量和表的數據量

#數據量到多少G，尤爲是單表的數據量

實例負載狀況（CPU負載、IO負載、系統負載）

慢查詢狀況

SQL延遲狀況

鎖狀況

髒頁狀況

訪問模型

#訪問模型就是這數據庫承擔的是讀多寫少仍是讀少寫多，以及是不是高併發等等

針對上述問題，能夠採用pt-mysql-summary工具獲取，再加以分析，也能夠經過以下兩個工具來實時查看

innotop

orzdba

---

<2>數據安全篇

針對數據安全，主要包含以下幾個部分

一、權限安全

在權限方面，咱們常常會看到有不少的數據庫根本就沒有密碼，或者給業務的用戶使用徹底的權限（all privileges），或者是給某個賬號能夠從任何地方登陸的權限，這些都是很是致命的。建議在授予權限的時候注意以下幾點：

數據庫必定設置符合密碼複雜度的用戶密碼

禁止給用戶設置%的登陸機器

只給業務最小權限的賬號，並限制登陸的機器

二、數據一致性

目前通常都是主從架構，主從的數據是否一致？90%以上的主從架構都缺少數據一致性校驗，以前遇到主從切換後數據不一致的狀況，致使線上故障。

爲了保證數據的一致性，記得週期性地使用pt-table-checksum來檢查主從數據是否一致，若是不一致，可使用pt-table-sync進行修復。

三、數據安全

作爲DBA，常常要思考，若是數據被誤刪，在現有的環境下是否會致使數據丟失。若是會，那就是你DBA工做沒有作到位。主要考慮的指標爲：

備份策略（數據庫備份、binlog備份）

這裏主要考慮3件事情：

3.1 數據備份策略是否合理

備份策略至少包含全量備份，和binlog增量備份，因爲有從機，基本binlog都會比較安全

3.2 備份數據是否安全

備份數據是否安全，好比備份機器掛掉，是否全部的備份數據都會丟失，能夠採用分佈式文件系統或者在服務器中交錯存放來規避。

3.3 備份數據是否可用

經常問本身，咱們的備份數據都是有效的嗎？週期性作備份數據還原的演練是必要的，確保備份數據的有效性。

---

<3>常規操做篇

在操做數據庫的時候，首先咱們須要熟練常規的操做，常規的操做又分爲兩部分，一個是線上數據庫的常規操做，一個是針對常見故障的預案的常規操做。熟練了操做和預案，才能在線上出問題的時候不至於手忙腳亂。

一、常規操做

常規的操做通常包含以下幾項

啓動中止

數據庫常規變動

索引優化

配置修改

數據庫的備份

數據的遷移

切換

以上這些操做，包含的內容太多，DBA們能夠自行google。總之要達到很是熟練的地步。若是命令記不住，建議將常規的操做經過關鍵字標記，並記錄到相似印象筆記的文檔中，要急用的時候能夠快速搜索到。也能夠寫成工具腳本，隨時調用。

二、常見故障的預案

做爲DBA，常常要面對各類突發的故障。你們要先搞清楚，不是遇到了故障咱們纔去找解決辦法，而是在沒有遇到故障以前就應該想到某一部分可能會出現問題，若是出現問題，咱們應該當如何來應對。好比master出現故障，咱們當如何處理？當你想到某個地方可能出現問題，那麼就先將解決方案寫出來。而後再找環境測試解決方案的可行性。驗證了方案可行性以後，最好在線上安排對應的案例演習，確保解決方案可靠的。最終達到的效果是任何團隊的任何一個成員對照文檔都能處理相似的故障。

三、極端狀況下的預案

除了常見故障的預案，咱們還應當思考極端狀況下可能出現的故障（雖然可能永遠都用不上），好比數據庫主從都掛掉的狀況。最好能拉上業務和開發的同窗一塊兒討論，得出可行性的解決辦法，而後找環境驗證。當問題真的出現後，你會比沒有預案的時候鎮定不少，不至於一臉懵B。

四、按期演習

預案作好之後最好能按期安排演習，開始搞互聯網金融後有更深的體會，這邊基本每月都會有常規的演習。按期演習很是必要，經過演習，將演習過程當中發現的問題都梳理出來，進行各個擊破，確保各個預案都能正常工做。

---

<4>架構篇

一、你是一個合格DBA嗎？

做爲運維DBA，確定會接觸到數據庫的架構和業務架構，以前咱們總監要求新入職的員工必須對你所要負責的數據庫架構進行串講，將不清楚的，不能直接上崗作線上操做。這個無疑是很是正確的，尤爲是在騰訊這種公司，不少後端的邏輯都經過OSS進行封裝，致使你能看到的只是web頁面上的各個功能簡單的按鈕。只要輕輕一點，就能將很複雜的功能完成。這個對於後端邏輯沒有好奇心的人是很是致命的。出了問題就找開發，致使本身的能力沒有任何的提高，甚至還會在這種點鼠標的工做中日益退化。所以在架構篇部分其實想和你們聊的是在咱們點鼠標的同時，仍是要深刻地去了解點鼠標背後發生的事情，知道異常如何分析和排查。甚至要再大膽一點，你也能夠嘗試着經過python或者go等語言去實現那些背後的邏輯，不要把本身侷限在只是一個OP。所以咱們在作運維的時候，不妨好好的問本身幾個問題：

我點了鼠標以後，後端都幹了什麼事情？ 須要和哪些服務交互 ？

若是點完鼠標之後，報錯了，須要如何進行排查？須要到哪裏看日誌？須要如何處理？

問完這兩個問題，更次一點的是找研發詳細瞭解裏面的運行邏輯，以及部署詳情，日誌存放，出現問題如何排查等。更好的辦法，是找研發要代碼，而後本身去看對應按鈕後面代碼的邏輯。有的同窗會說，我編碼能力差，看不懂。這個不用擔憂，相信我，要基本看懂研發寫的代碼其實並無那麼難。踐行一下你就會知道。等你看完研發的代碼，估計很快就能夠本身寫一個相似的功能出來。

二、你真的瞭解線上的架構嗎？

如今數據庫高可用架構比較多，無論是單純地使用主從架構、MHA、MMM、ndbcluster或是集成了LVS、keepalived等組件，咱們都不該該僅僅停留在正常狀況下會搭建、操做和使用對應的架構。更多的是，咱們須要更深刻的去了解裏面運做的機理。就以MHA爲例，它是如何檢測某一個實例異常的？各個組件之間如何配合？當作切換的時候，MHA是如何保證數據的一致性？若是後端有多臺slave，它是如何選擇哪一臺從機作切換，而且，其餘從機如何處理？只有深刻了解了邏輯以後，在遇到故障和問題，你就能更快速的進行定位，減小對業務的影響。此外你還能有針對性的作自動化，讓本身工做更輕鬆。這麼好的事情，爲何不踐行一下？

三、瞭解業務

還有一個問題，就是做爲DBA要儘量的去了解業務，瞭解業務的讀寫模型，瞭解業務相關架構，瞭解業務如何使用數據庫。這樣作的好處是你能針對業務的場景給出更好的優化建議，出了問題也能快速判斷對業務的影響狀況。

---

<5>線上操做篇（經驗）

DBA面對線上複雜的環境，尤爲是面對高併發的環境，很容易致使線上故障，下面是整理的一些容易致使線上故障的操做以及規避誤操做的技巧，但願能對各位DBA有所幫助：

一、修改或刪除數據前先備份，先備份，先備份（重要事情說三遍）

二、線上變動必定要有回退方案

三、批量操做中間添加sleep

四、DDL操做要謹慎，對於大表的alter操做最好使用pt-online-schema-change

五、變動操做先在測試環境測試

六、重啓數據庫前先刷髒頁

七、禁止批量刪除大量的binlog

八、對於變動操做必定要寫詳細的操做步驟，並review

九、按enter以前再進行一次環境確認

十、若是你的操做可能會使情況變得更糟，請中止操做

十一、快速處理磁盤滿，使用tune2fs釋放文件系統保留塊

十二、鏈接數滿先修改內存變量，而不是重啓，修改方式以下：

gdb -p pid -ex "set max_connections=1000" -batch

#pid是mysqld的對應的pid

---

<6>心態篇

一、心細膽大

從某種意義上講，DBA是一個高危的行業，不是開玩笑，看看下面的截圖就知道：

 

風險自己是個僞命題，對於某些人來講是風險，可是對於某些人來講其實沒有風險。就像醫生作手術同樣，咱們常人看來就是個很是危險的事情，可是對於醫生來說，其實並無什麼風險（大部分的手術）。所以風險在於你是否已經瞭解深刻，而且作足了功課。這就要求咱們在作線上操做以前要心細，有詳細的操做步驟，有想盡的回滾方案，作完備的測試。這些作完了之後，你的膽子才能」大「起來，膽大是由於你心中有底，心中有自信。這些自信都是前面你作功課帶給你的。

二、敢於擔當

出現問題自己並不可怕，可怕的是選擇逃避。咱們要作的就是正視問題，吸收教訓，敢於擔當。作好case study，防止團隊在同一個地方跌倒兩次。

三、工匠精神

今天看到同事發的一個朋友圈頗有感觸，在沒有人注意的地方也不懈怠、不偷懶的精神，纔是真正的工匠精神。作爲DBA也一樣很是須要這種精神，對於遺留問題的跟進不能偷懶；對於備份異常的巡檢不能偷懶；對於技術的積累不能偷懶；工匠精神是咱們DBA在作平常管理工做不可缺乏的精神。

---

有句話說的是：」咱們之因此常常犯錯，就是由於咱們作的功課不夠「。若是你有不少功課拉下了，請安排事件逐步補上，要堅信一切都是閒淡中求來，熱鬧中使用。有的事情知道了自己並無什麼了不得，了不得的是那些堅持踐行的人。踐行起來，你會發現你的人生今後不一樣。

 

備註：原創做品，轉載請著名出處！