專職做 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 在做日常管理工作不可缺少的精神。

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