[[200185]]

專職做 DBA 已經 6 年多的時間了，一路走來，感觸非常深。看同行、同事犯了太多的錯誤，同樣我自己也犯了非常多的錯誤，然而絕大多數的錯誤其實都是很低級的錯誤。

有的是因為不了解某個引擎的特性導致、有的是因為對線上環境不了解導致、有的是因為經驗不足導致。一路上，跌跌撞撞，從小公司 DBA，到騰訊高級 DBA，再到現在的金融數據庫 DBA。

不由得想起 5 年前的我，剛進入 DBA 行業，缺乏經驗，經常犯錯誤，不是我不夠努力，更多的是初來乍到的我根本不知道應該在哪方面下功夫。

[[200186]]

本文就是基于這方面的考慮，根據自己在 DBA 這個職業上走過的彎路，總結一些方法給 DBA 的同行。希望本文能給同行 DBA 或者運維的朋友們帶來一些改變，讓大家知道作為一個 DBA 需要在哪些方面下功夫。

下面主要從環境、數據安全、常規操作、預案、架構、心態等層面進行分享，同時也會介紹一些實用的經驗。

[[200187]]

環境篇

毫無疑問，DBA 是需要綜合技能最多的一個職業，需要你有網絡、操作系統、文件系統、數據庫、安全、編程等知識。

作為 DBA，為了少犯錯誤，你首先得非常熟悉你負責的數據庫環境，大到網絡環境、系統環境、數據庫環境(這里主要以MySQL為例)。如果不熟悉環境，很容易因為自身操作考慮不周而導致線上的故障。

想想就知道，有多少 DBA 因為 alter 操作導致的線上故障?有多少 DBA 忽略了字符集的問題導致了線上的亂碼?又有多少 DBA 由于遷移的時候沒有備份觸發器或者 event 導致的故障?太多的教訓足以讓我們所有的 DBA 認識到熟悉環境的重要性。

另外 DBA 對線上環境如果足夠了解，在處理故障、討論處理方案等，都能極大地增強我們的自信，更好地提升自己的影響力。

我們可以說不熟悉環境的 DBA 不是好 DBA。下面來介紹環境部分 DBA 應該注意的問題：

軟件環境

操作系統環境

針對操作系統部分，你可能需要了解的是使用的操作系統類型，Linux or Windows，該系統做了哪些內核的優化，尤其是針對數據庫。

比如文件描述符、配置 ntp、raid 的寫 cache 模式等，另外你還要對系統的運行狀態有大致的了解，CPU 使用、內存使用、IO 使用以及網絡帶寬和包量的情況。

數據庫環境

數據庫環境包含的內容就非常多了，這里只介紹如果不了解比較容易造成誤操作的部分：

部署方式

對于數據庫的部署，我們需要了解數據庫是如何部署的，部署在了什么目錄，可執行文件、數據文件、log 文件、配置文件等的存放路徑，數據庫如何啟動和停止等。

使用引擎

了解目前數據庫默認使用的引擎，以及現有的表使用的引擎，提前清楚地了解各個引擎的特點和使用，避免在出現數據遷移、表損壞以及啟動問題手忙腳亂導致誤操作。

我們的技術就像武器庫，都是靠平時閑淡中的積累和打造，在出問題的時候直接從武器庫拿來使用，因此要經常豐富我們的“武器庫”。

備注：雖然現在基本使用的都是 innodb 引擎，但是，你也同樣可以發現有的還用了 Myisam，甚至還有的用到了 memory、merge、spider、tokuDB 等。

同步方式

目前 MySQL 基本都會配置同步(如果沒有一定要加上，除非是數據丟了或者長時間故障也沒關系的庫)，既然涉及到同步就會有多種不同的方式。

比如常見的分類：

• 基于 binlog 和 pos 的同步。
• 基于 GTID 的同步。
• 異步。
• 半同步。
• 單線程同步。
• 多線程同步。

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

版本

在維護數據庫的時候，還需要了解當前數據庫使用的大版本。因為數據庫的大版本的功能會有很大的差異，有很多特性是只存在某個大版本的。

因此了解使用的版本能讓你大致知道當前數據庫支持哪些特性。在涉及到遷移、同步、數據庫升級等操作的時候，能從容應對。

存儲過程(procedure)、事件(event)

了解當前數據庫是否存在存儲過程和事件，在數據備份、數據遷移的時候，需要將對應的存儲過程和事件的參數添加進去。

另外如果存在事件，在遷移的時候會有特殊的操作，在遷移的目標機器要先將事件關閉，切換后再打開。防止事件導致數據不一致。

關鍵配置

MySQL 有幾項非常關鍵的配置，需要了解清楚，避免由于配置沒搞清楚導致誤操作，總結關鍵配置如下：

innodb_buffer_pool_size 
 
#對innodb生效，對性能影響非常大，一般可以設置內存的50~80% 
 
key_buffer_size 
 
#對Myisam生效，建議修改成innodb 
 
innodb_flush_log_at_trx_commit 
 
#innodb的redo日志刷新方式，對innodb的影響會很大，一般設置為2log 
 
-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 工具)，以免遷移完成后由于參數不一致，中途要重啟實例的情況。

在這個問題上，我見過太多的教訓，希望大家能吸取教訓，減少故障和問題的發生。

數據庫環境收集工具介紹

前面我們介紹了數據庫相關的環境，對于那么多的環境變量，我們如何更好的去收集，這里給大家介紹一個工具。

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

數據安全篇

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

權限安全

在權限方面，我們經常會看到有很多的數據庫根本就沒有密碼，或者給業務的用戶使用完全的權限(all privileges)，或者是給某個帳號可以從任何地方登錄的權限，這些都是非常致命的。

建議在授予權限的時候注意如下幾點：

• 數據庫一定設置符合密碼復雜度的用戶密碼。
• 禁止給用戶設置 % 的登錄機器。
• 只給業務最小權限的帳號，并限制登錄的機器。

數據一致性

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

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

數據安全

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

主要考慮的指標為：

• 備份策略(數據庫備份、binlog 備份)。

這里主要考慮三件事情：

• 數據備份策略是否合理。備份策略至少包含全量備份和 binlog 增量備份，由于有從機，基本 binlog 都會比較安全。
• 備份數據是否安全。備份數據是否安全，比如備份機器掛掉，是否所有的備份數據都會丟失，可以采用分布式文件系統或者在服務器中交錯存放來規避。
• 備份數據是否可用。常常問自己，我們的備份數據都是有效的嗎?周期性做備份數據還原的演練是必要的，確保備份數據的有效性。

常規操作篇

在操作數據庫的時候，首先我們需要熟練常規的操作。

常規的操作又分為兩部分：

• 線上數據庫的常規操作。
• 針對常見故障的預案的常規操作。

熟練了操作和預案，才能在線上出問題的時候不至于手忙腳亂。

常規操作

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

• 啟動停止。
• 數據庫常規變更。
• 索引優化。
• 配置修改。
• 數據庫的備份。
• 數據的遷移。
• 切換。

以上這些操作，包含的內容太多，DBA 們可以自行 Google，總之要達到非常熟練的地步。

如果命令記不住，建議將常規的操作通過關鍵字標記，并記錄到類似印象筆記的文檔中，要急用的時候可以快速搜索到。也可以寫成工具腳本，隨時調用。

常見故障的預案

作為 DBA，經常要面對各種突發的故障。大家要先搞清楚，不是遇到了故障我們才去找解決辦法，而是在沒有遇到故障之前就應該想到某一部分可能會出現問題，如果出現問題，我們該當如何來應對。

比如 master 出現故障，我們如何處理?當你想到某個地方可能出現問題，那么就先將解決方案寫出來，然后再找環境測試解決方案的可行性。

驗證了方案可行性之后，***在線上安排對應的案例演習，確保解決方案是可靠的。最終達到的效果是任何團隊的任何一個成員對照文檔都能處理類似的故障。

極端情況下的預案

除了常見故障的預案，我們還應當思考極端情況下可能出現的故障(雖然可能永遠都用不上)，比如數據庫主從都掛掉的情況。

***能拉上業務和開發的同學一起討論，得出可行性的解決辦法，然后找環境驗證。當問題真的出現后，你會比沒有預案的時候鎮定很多，不至于一臉懵 B。

定期演習

預案做好以后***能定期安排演習，開始搞互聯網金融后有更深的體會，這邊基本每個月都會有常規的演習。

定期演習非常必要，通過演習，將演習過程中發現的問題都梳理出來，進行各個擊破，確保各個預案都能正常工作。

架構篇

你是一個合格 DBA 嗎

作為運維 DBA，肯定會接觸到數據庫的架構和業務架構，之前我們總監要求新入職的員工必須對你所要負責的數據庫架構進行串講，將不清楚的，不能直接上崗做線上操作。

這個無疑是非常正確的，尤其是在騰訊這種公司，很多后端的邏輯都通過 OSS 進行封裝，導致你能看到的只是 Web 頁面上的各個功能簡單的按鈕。只要輕輕一點，就能將很復雜的功能完成，這個對于后端邏輯沒有好奇心的人是非常致命的。

出了問題就找開發，導致自己的能力沒有任何的提升，甚至還會在這種點鼠標的工作中日益退化。因此在架構篇部分其實想和大家聊的是在我們點鼠標的同時，還是要深入地去了解點鼠標背后發生的事情，知道異常如何分析和排查。

甚至要再大膽一點，你也可以嘗試著通過 Python 或者 Go 等語言去實現那些背后的邏輯，不要把自己局限在只是一個 OP。

因此我們在做運維的時候，不妨好好的問自己幾個問題：

• 我點了鼠標之后，后端都干了什么事情? 需要和哪些服務交互?
• 如果點完鼠標以后，報錯了，需要如何進行排查?需要到哪里看日志?需要如何處理?

問完這兩個問題，更次一點的是找研發詳細了解里面的運行邏輯，以及部署詳情，日志存放，出現問題如何排查等。更好的辦法，是找研發要代碼，然后自己去看對應按鈕后面代碼的邏輯。

有的同學會說，我編碼能力差，看不懂。這個不用擔心，相信我，要基本看懂研發寫的代碼并沒有那么難，踐行一下你就會知道。等你看完研發的代碼，估計很快就可以自己寫一個類似的功能出來。

你真的了解線上的架構嗎

現在數據庫高可用架構比較多，不管是單純地使用主從架構、MHA、MMM、ndbcluster 或是集成了 LVS、keepalived 等組件，我們都不應該僅僅停留在正常情況下會搭建、操作和使用對應的架構。

更多的是，我們需要更深入的去了解里面運作的機理。就以 MHA 為例，它是如何檢測某一個實例異常的?各個組件之間如何配合?

當做切換的時候，MHA 是如何保證數據的一致性?如果后端有多臺 slave，它是如何選擇哪一臺從機做切換，并且，其他從機如何處理?

只有深入了解了邏輯之后，再遇到故障和問題，你就能更快速的進行定位，減少對業務的影響。此外你還能有針對性的做自動化，讓自己工作更輕松。這么好的事情，為什么不踐行一下?

了解業務

還有一個問題，就是作為 DBA 要盡可能的去了解業務，了解業務的讀寫模型，了解業務相關架構，了解業務如何使用數據庫。

這樣做的好處是你能針對業務的場景給出更好的優化建議，出了問題也能快速判斷對業務的影響情況。

線上操作篇

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 

心態篇

心細膽大

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

風險本身是個偽***，對于某些人來說是風險，但是對于某些人來說其實沒有風險。就像醫生做手術一樣，我們常人看來就是個非常危險的事情，但是對于醫生來講，其實并沒有什么風險(大部分的手術)。

因此風險在于你是否已經了解深入，并且做足了功課。這就要求我們在做線上操作之前要心細，有詳細的操作步驟，有詳盡的回滾方案，做完備的測試。

這些做完了以后，你的膽子才能“大”起來，膽大是因為你心中有底，心中有自信。這些自信都是前面你做功課帶給你的。

勇于擔當

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

工匠精神

今天看到同事發的一個朋友圈很有感觸，在沒有人注意的地方也不懈怠、不偷懶的精神，才是真正的工匠精神。

做為 DBA 也同樣非常需要這種精神，對于遺留問題的跟進不能偷懶、對于備份異常的巡檢不能偷懶、對于技術的積累不能偷懶，工匠精神是我們 DBA 在做日常管理工作不可缺少的精神。

有句話說的是：“我們之所以經常犯錯，就是因為我們做的功課不夠”。

如果你有很多功課拉下了，請安排時間逐步補上，要堅信一切都是閑淡中求來，熱鬧中使用。有的事情知道了本身并沒有什么了不起，了不起的是那些堅持踐行的人。踐行起來，你會發現你的人生從此不同。

[[200188]]

張秀云，網名飛鴻無痕，現任職于騰訊，負責騰訊金融數據庫的運維和優化工作。2007年開始從事運維方面的工作，經歷過網絡管理員、Linux運維工程師、DBA、分布式存儲運維等多個IT職位。對Linux運維、MySQL數據庫、分布式存儲有豐富的經驗。