騰訊專(zhuān)家：論高級(jí)DBA的自我修養(yǎng)

2017-08-11張秀云高效運(yùn)維

作者 : 張秀云

作者介紹:

張秀云:2007年開(kāi)始從事運(yùn)維方面的工作，經(jīng)歷過(guò)網(wǎng)絡(luò)管理員、linux運(yùn)維工程師、DBA、分布式存儲(chǔ)運(yùn)維等多個(gè)IT職位。對(duì)linux運(yùn)維、mysql數(shù)據(jù)庫(kù)、分布式存儲(chǔ)有豐富的經(jīng)驗(yàn)。2012年加盟騰訊，目前在騰訊負(fù)責(zé)騰訊云數(shù)據(jù)庫(kù)平臺(tái)和分布式存儲(chǔ)運(yùn)維平臺(tái)的運(yùn)維規(guī)劃工作。 微信:feihongwuhen

前言

專(zhuān)職做DBA已經(jīng)6年多的事件了，看同行、同事犯了太多的錯(cuò)誤，自己也犯了非常多的錯(cuò)誤。一路走來(lái)，感觸非常深。然而絕大多數(shù)的錯(cuò)誤其實(shí)都是很低級(jí)的錯(cuò)誤。

有的是因?yàn)椴涣私饽硞€(gè)引擎的特性導(dǎo)致；有的是因?yàn)閷?duì)線上環(huán)境不了解導(dǎo)致；有的是因?yàn)榻?jīng)驗(yàn)不足導(dǎo)致；一路上，跌跌撞撞，從小公司DBA，到騰訊高級(jí)DBA，再到現(xiàn)在的金融數(shù)據(jù)庫(kù)DBA。

不由得想起5年前的我，剛進(jìn)入DBA行業(yè)，缺乏經(jīng)驗(yàn)，經(jīng)常犯錯(cuò)誤，不是我不夠努力，更多的是初來(lái)咋到的我根本不知道應(yīng)該在哪方面下功夫。

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

下面主要從環(huán)境、數(shù)據(jù)安全、常規(guī)操作、預(yù)案、架構(gòu)、心態(tài)等層面，同時(shí)也會(huì)介紹一些實(shí)用的經(jīng)驗(yàn)。

<1> 環(huán)境篇

毫無(wú)疑問(wèn)，DBA是需要綜合技能最多的一個(gè)職業(yè)，需要你有網(wǎng)絡(luò)、操作系統(tǒng)、文件系統(tǒng)、數(shù)據(jù)庫(kù)、安全、編程等知識(shí)。

作為DBA，為了少犯錯(cuò)誤，你首先得非常熟悉你負(fù)責(zé)的數(shù)據(jù)庫(kù)環(huán)境，大到網(wǎng)絡(luò)環(huán)境、系統(tǒng)環(huán)境、數(shù)據(jù)庫(kù)環(huán)境（這里主要以mysql為例）。

如果不熟悉環(huán)境，很容易因?yàn)樽陨聿僮骺紤]不周而導(dǎo)致線上的故障。想想就知道，有多少DBA因?yàn)閍lter操作導(dǎo)致的線上故障？有多少DBA忽略了字符集的問(wèn)題導(dǎo)致了線上的亂碼？又有多少DBA由于遷移的時(shí)候沒(méi)有備份觸發(fā)器或者event導(dǎo)致的故障？太多的教訓(xùn)足以讓我們所有的DBA認(rèn)識(shí)到熟悉環(huán)境的重要性。

另外DBA對(duì)線上環(huán)境如果足夠了解，在處理故障、討論處理方案等，都能極大地增強(qiáng)我們的自信，更好地提升自己的影響力。我們可以說(shuō)不熟悉環(huán)境的DBA不是好DBA。下面來(lái)介紹環(huán)境部分我們DBA應(yīng)該注意的問(wèn)題：

1、軟件環(huán)境

1.1 操作系統(tǒng)環(huán)境

針對(duì)操作系統(tǒng)部分，你可能需要了解的是使用的操作系統(tǒng)類(lèi)型，linux or windows，該系統(tǒng)做了哪些內(nèi)核的優(yōu)化，尤其是針對(duì)數(shù)據(jù)庫(kù)，比如文件描述符、配置ntp、raid的寫(xiě)cache模式等，另外你還要對(duì)系統(tǒng)的運(yùn)行狀態(tài)有大致的了解，CPU使用、內(nèi)存使用、IO使用以及網(wǎng)絡(luò)帶寬和包量的情況。

1.2 數(shù)據(jù)庫(kù)環(huán)境

數(shù)據(jù)庫(kù)環(huán)境包含的內(nèi)容就非常多了，這里只介紹如果不了解比較容易造成誤操作的部分：

1.3 部署方式

對(duì)于數(shù)據(jù)庫(kù)的部署，我們需要了解數(shù)據(jù)庫(kù)是如何部署的，部署在了什么目錄，可執(zhí)行文件、數(shù)據(jù)文件、log文件、配置文件等的存放路徑，數(shù)據(jù)庫(kù)如何啟動(dòng)和停止等

1.4 使用引擎

了解目前數(shù)據(jù)庫(kù)默認(rèn)使用的引擎，以及現(xiàn)有的表使用的引擎，提前清楚地了解各個(gè)引擎的特點(diǎn)和使用，避免在出現(xiàn)數(shù)據(jù)遷移、表?yè)p壞以及啟動(dòng)問(wèn)題手忙腳亂導(dǎo)致誤操作。（我們的技術(shù)就像武器庫(kù)，都是靠平時(shí)閑淡中的積累和打造，在出問(wèn)題的時(shí)候直接從武器庫(kù)拿來(lái)使用，因此要經(jīng)常豐富我們的“武器庫(kù)”）

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

1.5 同步方式

目前mysql基本都會(huì)配置同步（如果沒(méi)有一定要加上，除非是數(shù)據(jù)丟了或者長(zhǎng)時(shí)間故障也沒(méi)關(guān)系的庫(kù)），既然涉及到同步就會(huì)有多種不同的方式。比如常見(jiàn)的分類(lèi)：

基于binlog和pos的同步

基于GTID的同步

異步

半同步

單線程同步

多線程同步

針對(duì)這些同步，都有一些不同的特點(diǎn)，比如出現(xiàn)問(wèn)題了，需要跳過(guò)某個(gè)位置，gtid的同步和基于pos的同步操作就不一樣，同步方式也是你必須掌握的技巧。

1.6 版本

在維護(hù)數(shù)據(jù)庫(kù)的時(shí)候，還需要了解當(dāng)前數(shù)據(jù)庫(kù)使用的大版本。因?yàn)閿?shù)據(jù)庫(kù)的大版本的功能會(huì)有很大的差異，有很多特性是只存在某個(gè)大版本的，因此了解使用的版本能讓你大致知道當(dāng)前數(shù)據(jù)庫(kù)支持哪些特性。在涉及到遷移、同步、數(shù)據(jù)庫(kù)升級(jí)等操作的時(shí)候，能從容應(yīng)對(duì)。

1.7 存儲(chǔ)過(guò)程（procedure）、事件（event）

了解當(dāng)前數(shù)據(jù)庫(kù)是否存在存儲(chǔ)過(guò)程和事件，在數(shù)據(jù)備份、數(shù)據(jù)遷移的時(shí)候，需要將對(duì)應(yīng)的存儲(chǔ)過(guò)程和事件的參數(shù)添加進(jìn)去，另外如果存在事件，在遷移的時(shí)候會(huì)有特殊的操作，在遷移的目標(biāo)機(jī)器要現(xiàn)將事件關(guān)閉，切換后再打開(kāi)。防止事件導(dǎo)致數(shù)據(jù)不一致。

1.8 關(guān)鍵配置

mysql有幾項(xiàng)非常關(guān)鍵的配置，需要了解清楚，避免由于配置沒(méi)搞清楚導(dǎo)致誤操作，總結(jié)關(guān)鍵配置如下：

innodb_buffer_pool_size

#對(duì)innodb生效，對(duì)性能影響非常大，一般可以設(shè)置內(nèi)存的50~80%

key_buffer_size

#對(duì)Myisam生效，建議修改成innodb

innodb_flush_log_at_trx_commit

#innodb的redo日志刷新方式，對(duì)innodb的影響會(huì)很大，一般設(shè)置為2log

-bin

#是否開(kāi)始binlog，如果沒(méi)有開(kāi)啟，一定要開(kāi)啟

sync_binlog

#刷binlog的方式，一般設(shè)置為0，如果對(duì)數(shù)據(jù)需要強(qiáng)一致的，可以將sync_binlog設(shè)置為大于1的數(shù)，兼顧安全和性能

innodb_file_per_table

#采用獨(dú)立表空間，建議都設(shè)置成獨(dú)立表空間，不然后面磁盤(pán)空間滿了，刪除表空間也無(wú)法釋放，必須做數(shù)據(jù)遷移

lower_case_table_names

#表明區(qū)分大小寫(xiě)

character_set_server

#字符集在遷移、數(shù)據(jù)庫(kù)變更、數(shù)據(jù)導(dǎo)入等都是必須要注意的，不然數(shù)據(jù)亂碼了就會(huì)很麻煩

max_connections

#最大連接數(shù)不能設(shè)置太大，要計(jì)算一下session內(nèi)存*max_connections + 固定內(nèi)存 < 總內(nèi)存-2G（這2G用來(lái)做系統(tǒng)內(nèi)存，留給系統(tǒng)的內(nèi)存可以再設(shè)大一點(diǎn)）

transaction_isolation

#設(shè)置隔離級(jí)別，默認(rèn)是Repeatable Read，如果是binlog是row模式，也經(jīng)常設(shè)置為Read Committed級(jí)別

所有上面說(shuō)的參數(shù)，都需要深入了解和熟悉，當(dāng)我們?cè)谧鰯?shù)據(jù)遷移的時(shí)候或者搭建mysql的時(shí)候，一定要比對(duì)一下和源實(shí)例的配置(比對(duì)工具可以參考pt-config-diff工具)，以免遷移完成后由于參數(shù)不一致，中途要重啟實(shí)例的情況。在這個(gè)問(wèn)題上，我見(jiàn)過(guò)太多的教訓(xùn)，希望大家能吸取教訓(xùn)，減少故障和問(wèn)題的發(fā)生。

1.9 數(shù)據(jù)庫(kù)環(huán)境收集工具介紹

前面我們介紹了數(shù)據(jù)庫(kù)的相關(guān)的環(huán)境，對(duì)于那么多的環(huán)境變量，我們?nèi)绾胃玫娜ナ占@里給大家介紹一個(gè)工具

pt-mysql-summary

這個(gè)工具的具體用法可以google了解，也可以訪問(wèn)如下鏈接了解，不在本文的論述范圍：

https://www.percona.com/doc/percona-toolkit/2.1/pt-mysql-summary.html

2、硬件

硬件相關(guān)的信息也是我們需要關(guān)注的，針對(duì)每種硬件我們都會(huì)有大致的QPS、TPS等指標(biāo)，這個(gè)對(duì)于新上業(yè)務(wù)的評(píng)估以及評(píng)估現(xiàn)在數(shù)據(jù)庫(kù)的瓶頸很有幫助，對(duì)于硬件你需要了結(jié)CPU核數(shù)、內(nèi)存的大小、硬盤(pán)的介質(zhì)（SAS？ PCIE SSD ？NVME SSD？），最好對(duì)線上的常見(jiàn)機(jī)型都有詳細(xì)的壓測(cè)數(shù)據(jù)。

了解每一種機(jī)型在mysql中的表現(xiàn)，也是體現(xiàn)DBA專(zhuān)業(yè)度的一個(gè)指標(biāo)。

經(jīng)常有DBA由于不了解各個(gè)機(jī)型大致能支撐的性能 ，在方案選型和設(shè)備選型討論中，無(wú)法肯定地確認(rèn)具體需要什么設(shè)備，當(dāng)前的設(shè)備配置是否能抗住對(duì)應(yīng)的訪問(wèn)量，導(dǎo)致領(lǐng)導(dǎo)和開(kāi)發(fā)對(duì)該DBA的專(zhuān)業(yè)度大打折扣。

如果大家在日常工作中有空閑的機(jī)器，不妨使用sysbench、mysqlslap、fio等工具搗鼓一下。

3、運(yùn)行狀態(tài)

作為DBA，我們還需要了解現(xiàn)在的實(shí)例的運(yùn)行狀態(tài)，如下幾個(gè)指標(biāo)都是我們需要了解的：

數(shù)據(jù)庫(kù)數(shù)據(jù)量和表的數(shù)據(jù)量

數(shù)據(jù)量到多少G，尤其是單表的數(shù)據(jù)量

實(shí)例負(fù)載情況（CPU負(fù)載、IO負(fù)載、系統(tǒng)負(fù)載）

慢查詢情況

SQL延遲情況

鎖情況

臟頁(yè)情況

訪問(wèn)模型

訪問(wèn)模型就是這數(shù)據(jù)庫(kù)承擔(dān)的是讀多寫(xiě)少還是讀少寫(xiě)多，以及是否是高并發(fā)等等

針對(duì)上述問(wèn)題，可以采用pt-mysql-summary工具獲取，再加以分析，也可以通過(guò)如下兩個(gè)工具來(lái)實(shí)時(shí)查看

innotop

orzdba

<2> 數(shù)據(jù)安全篇

針對(duì)數(shù)據(jù)安全，主要包含如下幾個(gè)部分

1、權(quán)限安全

在權(quán)限方面，我們經(jīng)常會(huì)看到有很多的數(shù)據(jù)庫(kù)根本就沒(méi)有密碼，或者給業(yè)務(wù)的用戶使用完全的權(quán)限（all privileges），或者是給某個(gè)帳號(hào)可以從任何地方登錄的權(quán)限，這些都是非常致命的。建議在授予權(quán)限的時(shí)候注意如下幾點(diǎn)：

數(shù)據(jù)庫(kù)一定設(shè)置符合密碼復(fù)雜度的用戶密碼

禁止給用戶設(shè)置%的登錄機(jī)器

只給業(yè)務(wù)最小權(quán)限的帳號(hào)，并限制登錄的機(jī)器

2、數(shù)據(jù)一致性

目前一般都是主從架構(gòu)，主從的數(shù)據(jù)是否一致？90%以上的主從架構(gòu)都缺乏數(shù)據(jù)一致性校驗(yàn)，之前遇到主從切換后數(shù)據(jù)不一致的情況，導(dǎo)致線上故障。

為了保證數(shù)據(jù)的一致性，記得周期性地使用pt-table-checksum來(lái)檢查主從數(shù)據(jù)是否一致，如果不一致，可以使用pt-table-sync進(jìn)行修復(fù)。

3、數(shù)據(jù)安全

做為DBA，經(jīng)常要思考，如果數(shù)據(jù)被誤刪，在現(xiàn)有的環(huán)境下是否會(huì)導(dǎo)致數(shù)據(jù)丟失。如果會(huì)，那就是你DBA工作沒(méi)有做到位。主要考慮的指標(biāo)為：

備份策略（數(shù)據(jù)庫(kù)備份、binlog備份）

這里主要考慮3件事情：

3.1 數(shù)據(jù)備份策略是否合理

備份策略至少包含全量備份，和binlog增量備份，由于有從機(jī)，基本binlog都會(huì)比較安全

3.2 備份數(shù)據(jù)是否安全

備份數(shù)據(jù)是否安全，比如備份機(jī)器掛掉，是否所有的備份數(shù)據(jù)都會(huì)丟失，可以采用分布式文件系統(tǒng)或者在服務(wù)器中交錯(cuò)存放來(lái)規(guī)避。

3.3 備份數(shù)據(jù)是否可用

常常問(wèn)自己，我們的備份數(shù)據(jù)都是有效的嗎？周期性做備份數(shù)據(jù)還原的演練是必要的，確保備份數(shù)據(jù)的有效性。

<3> 常規(guī)操作篇

在操作數(shù)據(jù)庫(kù)的時(shí)候，首先我們需要熟練常規(guī)的操作，常規(guī)的操作又分為兩部分，一個(gè)是線上數(shù)據(jù)庫(kù)的常規(guī)操作，一個(gè)是針對(duì)常見(jiàn)故障的預(yù)案的常規(guī)操作。熟練了操作和預(yù)案，才能在線上出問(wèn)題的時(shí)候不至于手忙腳亂。

1、常規(guī)操作

常規(guī)的操作一般包含如下幾項(xiàng)

啟動(dòng)停止

數(shù)據(jù)庫(kù)常規(guī)變更

索引優(yōu)化

配置修改

數(shù)據(jù)庫(kù)的備份

數(shù)據(jù)的遷移

切換

以上這些操作，包含的內(nèi)容太多，DBA們可以自行g(shù)oogle。總之要達(dá)到非常熟練的地步。如果命令記不住，建議將常規(guī)的操作通過(guò)關(guān)鍵字標(biāo)記，并記錄到類(lèi)似印象筆記的文檔中，要急用的時(shí)候可以快速搜索到。也可以寫(xiě)成工具腳本，隨時(shí)調(diào)用。

2、常見(jiàn)故障的預(yù)案

作為DBA，經(jīng)常要面對(duì)各種突發(fā)的故障。大家要先搞清楚，不是遇到了故障我們才去找解決辦法，而是在沒(méi)有遇到故障之前就應(yīng)該想到某一部分可能會(huì)出現(xiàn)問(wèn)題，如果出現(xiàn)問(wèn)題，我們應(yīng)該當(dāng)如何來(lái)應(yīng)對(duì)。

比如master出現(xiàn)故障，我們當(dāng)如何處理？當(dāng)你想到某個(gè)地方可能出現(xiàn)問(wèn)題，那么就先將解決方案寫(xiě)出來(lái)。然后再找環(huán)境測(cè)試解決方案的可行性。驗(yàn)證了方案可行性之后，最好在線上安排對(duì)應(yīng)的案例演習(xí)，確保解決方案可靠的。最終達(dá)到的效果是任何團(tuán)隊(duì)的任何一個(gè)成員對(duì)照文檔都能處理類(lèi)似的故障。

3、極端情況下的預(yù)案

除了常見(jiàn)故障的預(yù)案，我們還應(yīng)當(dāng)思考極端情況下可能出現(xiàn)的故障（雖然可能永遠(yuǎn)都用不上），比如數(shù)據(jù)庫(kù)主從都掛掉的情況。最好能拉上業(yè)務(wù)和開(kāi)發(fā)的同學(xué)一起討論，得出可行性的解決辦法，然后找環(huán)境驗(yàn)證。當(dāng)問(wèn)題真的出現(xiàn)后，你會(huì)比沒(méi)有預(yù)案的時(shí)候鎮(zhèn)定很多，不至于一臉懵B。

4、定期演習(xí)

預(yù)案做好以后最好能定期安排演習(xí)，開(kāi)始搞互聯(lián)網(wǎng)金融后有更深的體會(huì)，這邊基本每個(gè)月都會(huì)有常規(guī)的演習(xí)。定期演習(xí)非常必要，通過(guò)演習(xí)，將演習(xí)過(guò)程中發(fā)現(xiàn)的問(wèn)題都梳理出來(lái)，進(jìn)行各個(gè)擊破，確保各個(gè)預(yù)案都能正常工作。

<4> 架構(gòu)篇

1、你是一個(gè)合格DBA嗎？

作為運(yùn)維DBA，肯定會(huì)接觸到數(shù)據(jù)庫(kù)的架構(gòu)和業(yè)務(wù)架構(gòu)，之前我們總監(jiān)要求新入職的員工必須對(duì)你所要負(fù)責(zé)的數(shù)據(jù)庫(kù)架構(gòu)進(jìn)行串講，將不清楚的，不能直接上崗做線上操作。

這個(gè)無(wú)疑是非常正確的，尤其是在騰訊這種公司，很多后端的邏輯都通過(guò)OSS進(jìn)行封裝，導(dǎo)致你能看到的只是web頁(yè)面上的各個(gè)功能簡(jiǎn)單的按鈕。只要輕輕一點(diǎn)，就能將很復(fù)雜的功能完成。這個(gè)對(duì)于后端邏輯沒(méi)有好奇心的人是非常致命的。

出了問(wèn)題就找開(kāi)發(fā)，導(dǎo)致自己的能力沒(méi)有任何的提升，甚至還會(huì)在這種點(diǎn)鼠標(biāo)的工作中日益退化。因此在架構(gòu)篇部分其實(shí)想和大家聊的是在我們點(diǎn)鼠標(biāo)的同時(shí)，還是要深入地去了解點(diǎn)鼠標(biāo)背后發(fā)生的事情，知道異常如何分析和排查。

甚至要再大膽一點(diǎn)，你也可以嘗試著通過(guò)python或者go等語(yǔ)言去實(shí)現(xiàn)那些背后的邏輯，不要把自己局限在只是一個(gè)OP。因此我們?cè)谧鲞\(yùn)維的時(shí)候，不妨好好的問(wèn)自己幾個(gè)問(wèn)題：

我點(diǎn)了鼠標(biāo)之后，后端都干了什么事情？ 需要和哪些服務(wù)交互 ？

如果點(diǎn)完鼠標(biāo)以后，報(bào)錯(cuò)了，需要如何進(jìn)行排查？需要到哪里看日志？需要如何處理？

問(wèn)完這兩個(gè)問(wèn)題，更次一點(diǎn)的是找研發(fā)詳細(xì)了解里面的運(yùn)行邏輯，以及部署詳情，日志存放，出現(xiàn)問(wèn)題如何排查等。更好的辦法，是找研發(fā)要代碼，然后自己去看對(duì)應(yīng)按鈕后面代碼的邏輯。

有的同學(xué)會(huì)說(shuō)，我編碼能力差，看不懂。這個(gè)不用擔(dān)心，相信我，要基本看懂研發(fā)寫(xiě)的代碼其實(shí)并沒(méi)有那么難。踐行一下你就會(huì)知道。等你看完研發(fā)的代碼，估計(jì)很快就可以自己寫(xiě)一個(gè)類(lèi)似的功能出來(lái)。

2、你真的了解線上的架構(gòu)嗎？

現(xiàn)在數(shù)據(jù)庫(kù)高可用架構(gòu)比較多，不管是單純地使用主從架構(gòu)、MHA、MMM、ndbcluster或是集成了LVS、keepalived等組件，我們都不應(yīng)該僅僅停留在正常情況下會(huì)搭建、操作和使用對(duì)應(yīng)的架構(gòu)。

更多的是，我們需要更深入的去了解里面運(yùn)作的機(jī)理。就以MHA為例，它是如何檢測(cè)某一個(gè)實(shí)例異常的？各個(gè)組件之間如何配合？當(dāng)做切換的時(shí)候，MHA是如何保證數(shù)據(jù)的一致性？如果后端有多臺(tái)slave，它是如何選擇哪一臺(tái)從機(jī)做切換，并且，其他從機(jī)如何處理？

只有深入了解了邏輯之后，在遇到故障和問(wèn)題，你就能更快速的進(jìn)行定位，減少對(duì)業(yè)務(wù)的影響。此外你還能有針對(duì)性的做自動(dòng)化，讓自己工作更輕松。這么好的事情，為什么不踐行一下？

3、了解業(yè)務(wù)

還有一個(gè)問(wèn)題，就是作為DBA要盡可能的去了解業(yè)務(wù)，了解業(yè)務(wù)的讀寫(xiě)模型，了解業(yè)務(wù)相關(guān)架構(gòu)，了解業(yè)務(wù)如何使用數(shù)據(jù)庫(kù)。這樣做的好處是你能針對(duì)業(yè)務(wù)的場(chǎng)景給出更好的優(yōu)化建議，出了問(wèn)題也能快速判斷對(duì)業(yè)務(wù)的影響情況。

<5> 線上操作篇（經(jīng)驗(yàn)）

DBA面對(duì)線上復(fù)雜的環(huán)境，尤其是面對(duì)高并發(fā)的環(huán)境，很容易導(dǎo)致線上故障，下面是整理的一些容易導(dǎo)致線上故障的操作以及規(guī)避誤操作的技巧，希望能對(duì)各位DBA有所幫助：

修改或刪除數(shù)據(jù)前先備份，先備份，先備份（重要事情說(shuō)三遍）

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

批量操作中間添加sleep

DDL操作要謹(jǐn)慎，對(duì)于大表的alter操作最好使用pt-online-schema-change

變更操作先在測(cè)試環(huán)境測(cè)試

重啟數(shù)據(jù)庫(kù)前先刷臟頁(yè)

禁止批量刪除大量的binlog

對(duì)于變更操作一定要寫(xiě)詳細(xì)的操作步驟，并review

按enter之前再進(jìn)行一次環(huán)境確認(rèn)

如果你的操作可能會(huì)使?fàn)顩r變得更糟，請(qǐng)停止操作

快速處理磁盤(pán)滿，使用tune2fs釋放文件系統(tǒng)保留塊

連接數(shù)滿先修改內(nèi)存變量，而不是重啟，修改方式如下：

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

#pid是mysqld的對(duì)應(yīng)的pid

<6> 心態(tài)篇

1、心細(xì)膽大

從某種意義上講，DBA是一個(gè)高危的行業(yè)，不是開(kāi)玩笑，看看下面的截圖就知道：

風(fēng)險(xiǎn)本身是個(gè)偽命題，對(duì)于某些人來(lái)說(shuō)是風(fēng)險(xiǎn)，但是對(duì)于某些人來(lái)說(shuō)其實(shí)沒(méi)有風(fēng)險(xiǎn)。就像醫(yī)生做手術(shù)一樣，我們常人看來(lái)就是個(gè)非常危險(xiǎn)的事情，但是對(duì)于醫(yī)生來(lái)講，其實(shí)并沒(méi)有什么風(fēng)險(xiǎn)（大部分的手術(shù)）。

因此風(fēng)險(xiǎn)在于你是否已經(jīng)了解深入，并且做足了功課。這就要求我們?cè)谧鼍€上操作之前要心細(xì)，有詳細(xì)的操作步驟，有想盡的回滾方案，做完備的測(cè)試。這些做完了以后，你的膽子才能”大“起來(lái)，膽大是因?yàn)槟阈闹杏械祝闹杏凶孕拧＿@些自信都是前面你做功課帶給你的。

2、勇于擔(dān)當(dāng)

出現(xiàn)問(wèn)題本身并不可怕，可怕的是選擇逃避。我們要做的就是正視問(wèn)題，吸取教訓(xùn)，勇于擔(dān)當(dāng)。做好case study，防止團(tuán)隊(duì)在同一個(gè)地方跌倒兩次。

3、工匠精神

今天看到同事發(fā)的一個(gè)朋友圈很有感觸，在沒(méi)有人注意的地方也不懈怠、不偷懶的精神，才是真正的工匠精神。做為DBA也同樣非常需要這種精神，對(duì)于遺留問(wèn)題的跟進(jìn)不能偷懶；對(duì)于備份異常的巡檢不能偷懶；對(duì)于技術(shù)的積累不能偷懶；工匠精神是我們DBA在做日常管理工作不可缺少的精神。

有句話說(shuō)的是：”我們之所以經(jīng)常犯錯(cuò)，就是因?yàn)槲覀冏龅墓φn不夠“。如果你有很多功課拉下了，請(qǐng)安排事件逐步補(bǔ)上，要堅(jiān)信一切都是閑淡中求來(lái)，熱鬧中使用。有的事情知道了本身并沒(méi)有什么了不起，了不起的是那些堅(jiān)持踐行的人。踐行起來(lái)，你會(huì)發(fā)現(xiàn)你的人生從此不同。