專職做 DBA 已經 6 年多的時間了，一路上，跌跌撞撞，從小公司 DBA，到騰訊進階 DBA，再到現在的金融資料庫 DBA。看同行、同僚犯了太多的錯誤，自己也犯了非常多的錯誤。一路走來，感觸非常深。然而絕大多數的錯誤其實都是很低級的錯誤。 一如 5 年前的我，剛進入 DBA 行業，缺乏經驗，經常犯錯誤，不是我不夠努力，更多的是初來咋到的我根本不知道應該在哪方面下功夫。本文就是基于這方面的考慮，根據自己在 DBA 這個職業上走過的彎路，總結一些方法給 DBA 的同行。希望本文能給同行 DBA 或者運維的朋友們帶來一些改變，讓大家知道作為一個 DBA 需要在哪些方面下功夫。
專職做 DBA 已經 6 年多的事件了，看同行、同僚犯了太多的錯誤，自己也犯了非常多的錯誤。一路走來，感觸非常深。然而絕大多數的錯誤其實都是很低級的錯誤。有的是因為不了解某個引擎的特性導緻；有的是因為對線上環境不了解導緻；有的是因為經驗不足導緻；一路上，跌跌撞撞，從小公司 DBA，到騰訊進階 DBA，再到現在的金融資料庫 DBA。 不由得想起 5 年前的我，剛進入 DBA 行業，缺乏經驗，經常犯錯誤，不是我不夠努力，更多的是初來咋到的我根本不知道應該在哪方面下功夫。本文就是基于這方面的考慮，根據自己在 DBA 這個職業上走過的彎路，總結一些方法給 DBA 的同行。希望本文能給同行 DBA 或者運維的朋友們帶來一些改變，讓大家知道作為一個 DBA 需要在哪些方面下功夫。下面主要從環境、資料安全、正常操作、預案、架構、心态等層面，同時也會介紹一些實用的經驗。
毫無疑問，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 的同步操作就不一樣，同步方式也是你必須掌握的技巧。
在維護資料庫的時候，還需要了解目前資料庫使用的大版本。因為資料庫的大版本的功能會有很大的差異，有很多特性是隻存在某個大版本的，是以了解使用的版本能讓你大緻知道目前資料庫支援哪些特性。在涉及到遷移、同步、資料庫更新等操作的時候，能從容應對。
了解目前資料庫是否存在存儲過程和事件，在資料備份、資料遷移的時候，需要将對應的存儲過程和事件的參數添加進去，另外如果存在事件，在遷移的時候會有特殊的操作，在遷移的目标機器要現将事件關閉，切換後再打開。防止事件導緻資料不一緻。
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 工具)，以免遷移完成後由于參數不一緻，中途要重新開機執行個體的情況。在這個問題上，我見過太多的教訓，希望大家能吸取教訓，減少故障和問題的發生。
前面我們介紹了資料庫的相關的環境，對于那麼多的環境變量，我們如何更好的去收集，這裡給大家介紹一個工具
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 備份）
這裡主要考慮 3 件事情：
備份政策至少包含全量備份，和 binlog 增量備份，由于有從機，基本 binlog 都會比較安全
備份資料是否安全，比如備份機器挂掉，是否所有的備份資料都會丢失，可以采用分布式檔案系統或者在伺服器中交錯存放來規避。
常常問自己，我們的備份資料都是有效的嗎？周期性做備份資料還原的演練是必要的，確定備份資料的有效性。
在操作資料庫的時候，首先我們需要熟練正常的操作，正常的操作又分為兩部分，一個是線上資料庫的正常操作，一個是針對常見故障的預案的正常操作。熟練了操作和預案，才能線上上出問題的時候不至于手忙腳亂。
正常的操作一般包含如下幾項
啟動停止
資料庫正常變更
索引優化
配置修改
資料庫的備份
資料的遷移
切換
以上這些操作，包含的内容太多，DBA 們可以自行 google。總之要達到非常熟練的地步。如果指令記不住，建議将正常的操作通過關鍵字标記，并記錄到類似印象筆記的文檔中，要急用的時候可以快速搜尋到。也可以寫成工具腳本，随時調用。
作為 DBA，經常要面對各種突發的故障。大家要先搞清楚，不是遇到了故障我們才去找解決辦法，而是在沒有遇到故障之前就應該想到某一部分可能會出現問題，如果出現問題，我們應該當如何來應對。比如 master 出現故障，我們當如何處理？當你想到某個地方可能出現問題，那麼就先将解決方案寫出來。然後再找環境測試解決方案的可行性。驗證了方案可行性之後，最好線上上安排對應的案例演習，確定解決方案可靠的。最終達到的效果是任何團隊的任何一個成員對照文檔都能處理類似的故障。
除了常見故障的預案，我們還應當思考極端情況下可能出現的故障（雖然可能永遠都用不上），比如資料庫主從都挂掉的情況。最好能拉上業務和開發的同學一起讨論，得出可行性的解決辦法，然後找環境驗證。當問題真的出現後，你會比沒有預案的時候鎮定很多，不至于一臉懵 B。
預案做好以後最好能定期安排演習，開始搞網際網路金融後有更深的體會，這邊基本每個月都會有正常的演習。定期演習非常必要，通過演習，将演習過程中發現的問題都梳理出來，進行各個擊破，確定各個預案都能正常工作。
作為運維 DBA，肯定會接觸到資料庫的架構和業務架構，之前我們總監要求新入職的員工必須對你所要負責的資料庫架構進行串講，将不清楚的，不能直接上崗做線上操作。這個無疑是非常正确的，尤其是在騰訊這種公司，很多後端的邏輯都通過 OSS 進行封裝，導緻你能看到的隻是 web 頁面上的各個功能簡單的按鈕。隻要輕輕一點，就能将很複雜的功能完成。這個對于後端邏輯沒有好奇心的人是非常緻命的。出了問題就找開發，導緻自己的能力沒有任何的提升，甚至還會在這種點滑鼠的工作中日益退化。是以在架構篇部分其實想和大家聊的是在我們點滑鼠的同時，還是要深入地去了解點滑鼠背後發生的事情，知道異常如何分析和排查。甚至要再大膽一點，你也可以嘗試着通過 python 或者 go 等語言去實作那些背後的邏輯，不要把自己局限在隻是一個 OP。是以我們在做運維的時候，不妨好好的問自己幾個問題：
我點了滑鼠之後，後端都幹了什麼事情？ 需要和哪些服務互動 ？
如果點完滑鼠以後，報錯了，需要如何進行排查？需要到哪裡看日志？需要如何處理？
問完這兩個問題，更次一點的是找研發詳細了解裡面的運作邏輯，以及部署詳情，日志存放，出現問題如何排查等。更好的辦法，是找研發要代碼，然後自己去看對應按鈕後面代碼的邏輯。有的同學會說，我編碼能力差，看不懂。這個不用擔心，相信我，要基本看懂研發寫的代碼其實并沒有那麼難。踐行一下你就會知道。等你看完研發的代碼，估計很快就可以自己寫一個類似的功能出來。
現在資料庫高可用架構比較多，不管是單純地使用主從架構、MHA、MMM、ndbcluster 或是內建了 LVS、keepalived 等元件，我們都不應該僅僅停留在正常情況下會搭建、操作和使用對應的架構。更多的是，我們需要更深入的去了解裡面運作的機理。就以 MHA 為例，它是如何檢測某一個執行個體異常的？各個元件之間如何配合？當做切換的時候，MHA 是如何保證資料的一緻性？如果後端有多台 slave，它是如何選擇哪一台從機做切換，并且，其他從機如何處理？隻有深入了解了邏輯之後，在遇到故障和問題，你就能更快速的進行定位，減少對業務的影響。此外你還能有針對性的做自動化，讓自己工作更輕松。這麼好的事情，為什麼不踐行一下？
還有一個問題，就是作為 DBA 要盡可能的去了解業務，了解業務的讀寫模型，了解業務相關架構，了解業務如何使用資料庫。這樣做的好處是你能針對業務的場景給出更好的優化建議，出了問題也能快速判斷對業務的影響情況。
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、連接配接數滿先修改記憶體變量，而不是重新開機，修改方式如下：
從某種意義上講，DBA 是一個高危的行業，不是開玩笑，看看下面的截圖就知道：
風險本身是個僞命題，對于某些人來說是風險，但是對于某些人來說其實沒有風險。就像醫生做手術一樣，我們常人看來就是個非常危險的事情，但是對于醫生來講，其實并沒有什麼風險（大部分的手術）。是以風險在于你是否已經了解深入，并且做足了功課。這就要求我們在做線上操作之前要心細，有詳細的操作步驟，有想盡的復原方案，做完備的測試。這些做完了以後，你的膽子才能"大"起來，膽大是因為你心中有底，心中有自信。這些自信都是前面你做功課帶給你的。
出現問題本身并不可怕，可怕的是選擇逃避。我們要做的就是正視問題，吸取教訓，勇于擔當。做好 case study，防止團隊在同一個地方跌倒兩次。
今天看到同僚發的一個朋友圈很有感觸，在沒有人注意的地方也不懈怠、不偷懶的精神，才是真正的工匠精神。做為 DBA 也同樣非常需要這種精神，對于遺留問題的跟進不能偷懶；對于備份異常的巡檢不能偷懶；對于技術的積累不能偷懶；工匠精神是我們 DBA 在做日常管理工作不可缺少的精神。
有句話說的是："我們之是以經常犯錯，就是因為我們做的功課不夠"。如果你有很多功課拉下了，請安排事件逐漸補上，要堅信一切都是閑淡中求來，熱鬧中使用。有的事情知道了本身并沒有什麼了不起，了不起的是那些堅持踐行的人。踐行起來，你會發現你的人生從此不同。