DBA為什麼經常犯錯？因為你落下了這些功課！
作者介紹
張秀雲，網名飛鴻無痕，現任職於騰訊，負責騰訊金融資料庫的運維和優化工作。2007年開始從事運維方面的工作，經歷過網路管理員、Linux運維工程師、DBA、分散式儲存運維等多個IT職位。對Linux運維、MySQL資料庫、分散式儲存有豐富的經驗。
專職做DBA已經6年多的時間了，看同行、同事犯了太多的錯誤，自己也犯了非常多的錯誤。一路走來，感觸非常深。然而絕大多數的錯誤其實都是很低階的錯誤，有的是因為不瞭解某個引擎的特性導致；有的是因為對線上環境不瞭解導致；有的是因為經驗不足導致。一路上，跌跌撞撞，從小公司DBA，到騰訊高階DBA，再到現在的金融資料庫高階DBA。 不由想起5年前的我，剛進入DBA行業，缺乏經驗，經常犯錯誤，不是我不夠努力，更多的是初來乍到的我根本不知道應該在哪方面下功夫。
本文就是基於這方面的考慮，根據自己在DBA這個職業上走過的彎路，總結一些方法給DBA同行。希望本文能給同行DBA或者運維的朋友們帶來一些改變，讓大家瞭解作為DBA需要在哪些方面發力。
下面主要從環境、資料安全、常規操作、預案、架構、心態等層面，介紹一些實用的經驗。
環境篇
毫無疑問，DBA是需要綜合技能最多的一個職業，需要你有網路、作業系統、檔案系統、資料庫、安全、程式設計等知識。作為DBA，為了少犯錯誤，你首先得非常熟悉你負責的資料庫環境，大到網路環境、系統環境、資料庫環境（這裡主要以MySQL為例）。
如果不熟悉環境，很容易因為自身操作考慮不周而導致線上的故障。想想就知道，有多少DBA因為Alter操作導致線上故障？有多少DBA忽略了字符集的問題導致了線上的亂碼？又有多少DBA由於遷移的時候沒有備份觸發器或者event導致故障？太多的教訓足以讓我們所有的DBA認識到熟悉環境的重要性。
另外，DBA對線上環境如果足夠了解，在處理故障、討論處理方案等，都能極大地增強我們的自信，更好地提升自己的影響力。我們可以說不熟悉環境的DBA不是好DBA。下面來介紹DBA在環境部分應該注意的問題。
軟體
1.作業系統環境
針對作業系統部分，你可能需要了解的是使用的作業系統型別。Linux or Windows，該系統做了哪些核心的優化，尤其是針對資料庫，比如檔案描述符、配置NTP、Raid的寫cache模式等。另外你還要對系統的執行狀態有大致的瞭解，例如CPU使用、記憶體使用、IO使用以及網路頻寬和包量的情況。
2.資料庫環境
資料庫環境包含的內容就非常多了，這裡只介紹因為不瞭解而比較容易造成誤操作的部分。
（1）部署方式
對於資料庫的部署，我們需要了解資料庫是如何部署的，部署在什麼目錄，可執行檔案、資料檔案、log檔案、配置檔案等的存放路徑，資料庫如何啟動和停止等。
（2）使用引擎
瞭解目前資料庫預設使用的引擎，以及現有的表使用的引擎，提前清楚地瞭解各個引擎的特點和使用，避免在出現資料遷移、表損壞以及啟動問題時手忙腳亂導致誤操作。（我們的技術就像武器庫，都是靠平時閒談中的積累和打造，在出問題的時候直接從武器庫拿出來使用，因此要經常豐富我們的武器庫）
備註：雖然現在基本使用的都是InnoDB引擎，但是，你也同樣可以發現有的還用了Myisam，甚至有的還用到了Memory、merge、Spider、TokuDB等。
（3）同步方式
目前MySQL基本都會配置同步（如果沒有的話，一定要加上，除非是資料丟了或者長時間故障也沒關係的庫），既然涉及到同步就會有多種不同的方式。比如常見的分類：
- 基於binlog和POS的同步
- 基於GTID的同步
- 非同步
- 半同步
- 單執行緒同步
- 多執行緒同步
針對這些同步，都有一些不同的特點，比如出現問題了，需要跳過某個位置，GTID的同步和基於POS的同步操作就不一樣，同步方式也是你必須掌握的技巧。
（4）版本
在維護資料庫時，還需要了解當前資料庫使用的大版本。因為資料庫的大版本的功能會有很大的差異，有很多特性是隻存在某個大版本的，因此瞭解使用的版本能讓你大致知道當前資料庫支援哪些特性。在涉及到遷移、同步、資料庫升級等操作的時候，能從容應對。
（5）儲存過程（procedure）、事件（event）
瞭解當前資料庫是否存在儲存過程和事件。在資料備份、資料遷移的時候，需要將對應的儲存過程和事件的引數新增進去。另外如果存在事件，在遷移的時候會有特殊的操作，在遷移的目標機器要先將事件關閉，切換後再開啟。防止事件導致資料不一致。
（6）關鍵配置
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
硬體
經常有DBA由於不瞭解各個機型大致能支撐的效能 ，所以在方案選型和裝置選型討論中，無法肯定地確認具體需要什麼裝置，當前的裝置配置是否能抗住對應的訪問量，導致領導和開發對該DBA的專業度大打折扣。如果大家在日常工作中有空閒的機器，不妨使用sysbench、mysqlslap、FIO等工具搗鼓一下。
執行狀態
- 資料庫資料量和表的資料量
#資料量到多少G，尤其是單表的資料量
- 例項負載情況（CPU負載、IO負載、系統負載）
- 慢查詢情況
- SQL延遲情況
- 鎖情況
- 髒頁情況
- 訪問模型
#訪問模型就是這資料庫承擔的是讀多寫少還是讀少寫多，以及是否是高併發等等
針對上述問題，可以採用pt-mysql-summary工具獲取，再加以分析，也可以通過如下兩個工具來實時檢視：
- innotop
- orzdba
資料安全篇
許可權安全
- 資料庫一定設定符合密碼複雜度的使用者密碼；
- 禁止給使用者設定%的登入機器；
- 只給業務最小許可權的帳號，並限制登入的機器。
資料一致性
為了保證資料的一致性，記得週期性地使用pt-table-checksum來檢查主從資料是否一致，如果不一致，可以使用pt-table-sync進行修復。
資料安全
1.資料備份策略是否合理
2.備份資料是否安全
3.備份資料是否可用
常規操作篇
在操作資料庫的時候，首先我們需要熟練常規的操作。常規的操作又分為兩部分，一個是線上資料庫的常規操作，另一個是針對常見故障的預案的常規操作。熟練了操作和預案，才能在線上出問題的時候不至於手忙腳亂。
常規操作
常規的操作一般包含如下幾項：
- 啟動停止
- 資料庫常規變更
- 索引優化
- 配置修改
- 資料庫的備份
- 資料的遷移
- 切換
以上這些操作，包含的內容太多，DBA們可以自行Google。總之要達到非常熟練的地步。如果命令記不住，建議將常規的操作通過關鍵字標記，並記錄到類似印象筆記的文件中，要急用的時候也可以快速搜尋到。也可以寫成工具指令碼，隨時呼叫。
常見故障的預案
極端情況下的預案
定期演習
架構篇
你是一個合格DBA嗎？
因此在架構篇部分其實想和大家聊的是在我們點滑鼠的同時，還是要深入地去了解點滑鼠背後發生的事情，知道異常如何分析和排查。甚至要再大膽一點，你也可以嘗試著通過Python或者Go等語言去實現那些背後的邏輯，不要只是把自己侷限在做一個OP。因此我們在做運維的時候，不妨好好地問自己幾個問題：
我點了滑鼠之後，後端都幹了什麼事情？ 需要和哪些服務互動 ？如果點完滑鼠以後，報錯了，需要如何進行排查？需要到哪裡看日誌？需要如何處理？
問完這兩個問題，更次一點的是找研發詳細瞭解裡面的執行邏輯，以及部署詳情，日誌存放，出現問題如何排查等。更好的辦法，是找研發要程式碼，然後自己去看對應按鈕後面程式碼的邏輯。
有的同學會說，我編碼能力差，看不懂。這個不用擔心，相信我，要基本看懂研發寫的程式碼其實並沒有那麼難。踐行一下你就會知道。等你看完研發的程式碼，估計很快就可以自己寫一個類似的功能出來。
只有深入瞭解了邏輯之後，在遇到故障和問題，你就能更快速地進行定位，減少對業務的影響。此外你還能有針對性的做自動化，讓自己工作更輕鬆。這麼好的事情，為什麼不踐行一下？
瞭解業務
線上操作篇（經驗）
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是一個高危的行業，不是開玩笑，看看下面的截圖就知道：
風險本身是個偽命題，對於某些人來說是風險，但對於某些人來說其實沒有風險。就像醫生做手術一樣，我們常人看來就是個非常危險的事情，但是對於醫生來講，其實並沒有什麼風險（大部分的手術）。因此風險在於你是否已經瞭解深入，並且做足了功課。
這就要求我們在做線上操作之前要心細，要有詳細的操作步驟，有想盡的回滾方案，做完備的測試。這些做完了以後，你的膽子才能“大”起來，膽大是因為你心中有底，心中有自信。這些自信都是前面你做功課帶給你的。
勇於擔當
工匠精神
有句話說得好：我們之所以經常犯錯，就是因為我們做的功課不夠。如果你有很多功課落下了，請安排時間逐步補上，要堅信一切都是閒談中求來，熱鬧中使用。
文章來自微信公眾號：DBAplus社群