專職做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.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

2、硬件

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

經常有DBA由於不了解各個機型大致能支撐的性能 ，在方案選型和設備選型討論中，無法肯定地確認具體需要什麽設備，當前的設備配置是否能抗住對應的訪問量，導致領導和開發對該DBA的專業度大打折扣。如果大家在日常工作中有空閑的機器，不妨使用sysbench、mysqlslap、fio等工具搗鼓一下。

3、運行狀態

作為DBA，我們還需要了解現在的實例的運行狀態，如下幾個指標都是我們需要了解的：

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

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

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

慢查詢情況

SQL延遲情況

鎖情況

臟頁情況

訪問模型

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

針對上述問題，可以采用pt-mysql-summary工具獲取，再加以分析，也可以通過如下兩個工具來實時查看

innotop

orzdba

<2>數據安全篇

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

1、權限安全

在權限方面，我們經常會看到有很多的數據庫根本就沒有密碼，或者給業務的用戶使用完全的權限（all privileges），或者是給某個帳號可以從任何地方登錄的權限，這些都是非常致命的。建議在授予權限的時候註意如下幾點：

數據庫一定設置符合密碼復雜度的用戶密碼

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

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

2、數據一致性

目前一般都是主從架構，主從的數據是否一致？90%以上的主從架構都缺乏數據一致性校驗，之前遇到主從切換後數據不一致的情況，導致線上故障。

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

3、數據安全

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

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

這裏主要考慮3件事情：

3.1 數據備份策略是否合理

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

3.2 備份數據是否安全

備份數據是否安全，比如備份機器掛掉，是否所有的備份數據都會丟失，可以采用分布式文件系統或者在服務器中交錯存放來規避。

3.3 備份數據是否可用

常常問自己，我們的備份數據都是有效的嗎？周期性做備份數據還原的演練是必要的，確保備份數據的有效性。

<3>常規操作篇

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

1、常規操作

常規的操作一般包含如下幾項

啟動停止

數據庫常規變更

索引優化

配置修改

數據庫的備份

數據的遷移

切換

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

2、常見故障的預案

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

3、極端情況下的預案

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

4、定期演習

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

<4>架構篇

1、你是一個合格DBA嗎？

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

我點了鼠標之後，後端都幹了什麽事情？ 需要和哪些服務交互 ？

如果點完鼠標以後，報錯了，需要如何進行排查？需要到哪裏看日誌？需要如何處理？

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

2、你真的了解線上的架構嗎？

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

3、了解業務

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

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

DBA面對線上復雜的環境，尤其是面對高並發的環境，很容易導致線上故障，下面是整理的一些容易導致線上故障的操作以及規避誤操作的技巧，希望能對各位DBA有所幫助：

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

2、線上變更一定要有回退方案

3、批量操作中間添加sleep

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

5、變更操作先在測試環境測試

6、重啟數據庫前先刷臟頁

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

8、對於變更操作一定要寫詳細的操作步驟，並review

9、按enter之前再進行一次環境確認

10、如果你的操作可能會使狀況變得更糟，請停止操作

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

12、連接數滿先修改內存變量，而不是重啟，修改方式如下：

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

#pid是mysqld的對應的pid

<6>心態篇

1、心細膽大

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

風險本身是個偽命題，對於某些人來說是風險，但是對於某些人來說其實沒有風險。就像醫生做手術一樣，我們常人看來就是個非常危險的事情，但是對於醫生來講，其實並沒有什麽風險（大部分的手術）。因此風險在於你是否已經了解深入，並且做足了功課。這就要求我們在做線上操作之前要心細，有詳細的操作步驟，有想盡的回滾方案，做完備的測試。這些做完了以後，你的膽子才能”大“起來，膽大是因為你心中有底，心中有自信。這些自信都是前面你做功課帶給你的。

2、勇於擔當

出現問題本身並不可怕，可怕的是選擇逃避。我們要做的就是正視問題，吸取教訓，勇於擔當。做好case study，防止團隊在同一個地方跌倒兩次。

3、工匠精神

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

有句話說的是：”我們之所以經常犯錯，就是因為我們做的功課不夠“。如果你有很多功課拉下了，請安排事件逐步補上，要堅信一切都是閑淡中求來，熱鬧中使用。有的事情知道了本身並沒有什麽了不起，了不起的是那些堅持踐行的人。踐行起來，你會發現你的人生從此不同。

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

致DBA：為什麽你經常犯錯，是因為你做的功課不夠