數(shù)據(jù)庫(kù)的健康檢查涉及索引設(shè)計(jì)、容量規(guī)劃、服務(wù)安全、參數(shù)配置、用戶訪問(wèn)、集群復(fù)制6個(gè)方面。

　　數(shù)據(jù)庫(kù)作為一個(gè)大型的并發(fā)存儲(chǔ)系統(tǒng)，其內(nèi)部設(shè)計(jì)極其復(fù)雜。開發(fā)者在使用數(shù)據(jù)庫(kù)時(shí)，面臨著可用性、可靠性、性能、安全、擴(kuò)展性等多重挑戰(zhàn)，這就使得數(shù)據(jù)庫(kù)的使用具有較高的技術(shù)門檻。

　　一般大型團(tuán)隊(duì)都會(huì)雇傭?qū)Ｂ毜? DBA來(lái)維護(hù)數(shù)據(jù)庫(kù)的日常運(yùn)行，指導(dǎo)開發(fā)者建立正確的使用姿勢(shì)。但是對(duì)于一般的中小型團(tuán)隊(duì)，受限于人力成本，這種模式很難實(shí)現(xiàn)。

　　而隨著 DevOps理念的流行，開發(fā)者開始更多地參與和承擔(dān)數(shù)據(jù)庫(kù)的運(yùn)維工作，其中就包括對(duì)數(shù)據(jù)庫(kù)的定期巡檢。

　　對(duì)數(shù)據(jù)庫(kù)定期進(jìn)行健康檢查是數(shù)據(jù)庫(kù)日常維護(hù)的重要環(huán)節(jié)，通過(guò)檢查數(shù)據(jù)庫(kù)的各項(xiàng)運(yùn)行指標(biāo)，評(píng)估系統(tǒng)的運(yùn)行風(fēng)險(xiǎn)，提前將風(fēng)險(xiǎn)消滅在搖籃中，能夠有效提高數(shù)據(jù)庫(kù)的服務(wù)質(zhì)量。

　　今天我們就來(lái)聊聊開發(fā)者如何對(duì)數(shù)據(jù)庫(kù)進(jìn)行健康檢查。

　　數(shù)據(jù)庫(kù)的健康檢查涉及索引設(shè)計(jì)、容量規(guī)劃、服務(wù)安全、參數(shù)配置、用戶訪問(wèn)、集群復(fù)制6個(gè)方面。

　　索引設(shè)計(jì)

　　合理的索引設(shè)計(jì)能夠有效加速數(shù)據(jù)庫(kù)的訪問(wèn)，提高查詢的執(zhí)行效率，減少用戶查詢對(duì)服務(wù)端的資源消耗。

　　而不合理的、低效的、冗余的甚至無(wú)效的索引不僅無(wú)法起到加速查詢?cè)L問(wèn)的效果，反而會(huì)影響數(shù)據(jù)庫(kù)的插入、更新性能，甚至是數(shù)據(jù)庫(kù)的高可用方案能否生效。 所以針對(duì)索引的健康檢查主要是發(fā)現(xiàn)系統(tǒng)表結(jié)構(gòu)設(shè)計(jì)中的不合理、低效、冗余、無(wú)效的索引。

　　主鍵索引缺失

　　由于 MySQL默認(rèn)存儲(chǔ)引擎 InnoDB(MySQL 5.6 之后)使用的是聚簇索引表設(shè)計(jì)，這就要求所有的表必須包含一個(gè)主鍵，所有的數(shù)據(jù)記錄需要按照主鍵順序構(gòu)建 B+樹，所有數(shù)據(jù)記錄位于葉子節(jié)點(diǎn)。

　　如果用戶在創(chuàng)建表時(shí)顯式指定主鍵，則數(shù)據(jù)庫(kù)會(huì)使用用戶指定的主鍵構(gòu)建B+樹，但是如果用戶沒(méi)有顯式指定主鍵，同時(shí)也沒(méi)有指定任何唯一鍵索引，InnoDB為了確保每張表至少包含一個(gè)主鍵，則默認(rèn)會(huì)為用戶生成一個(gè)“隱含主鍵”，該主鍵對(duì)用戶不可見，甚至對(duì)于 MySQL Server層的 binlog也不可見。

　　binlog 是連接 MySQL主從復(fù)制節(jié)點(diǎn)的紐帶，所有主節(jié)點(diǎn)的更新都是通過(guò) binlog傳遞給從節(jié)點(diǎn)的，一旦 binlog中沒(méi)有更新記錄的主鍵 ID，就會(huì)導(dǎo)致基于 Row格式的 binlog在從節(jié)點(diǎn)執(zhí)行時(shí)，無(wú)法唯一標(biāo)識(shí)某一條記錄，只能通過(guò)全表掃描來(lái)進(jìn)行全表匹配，大大降低了從機(jī)更新的執(zhí)行效率，從而造成復(fù)制延遲。如果是用于高可用故障切換的從節(jié)點(diǎn)，會(huì)導(dǎo)致切換的時(shí)間大幅增加，甚至?xí)?dǎo)致高可用機(jī)制失效。如果是用于提高讀能力搭建的只讀從節(jié)點(diǎn)，則會(huì)導(dǎo)致應(yīng)用讀到的數(shù)據(jù)可能是很久以前的舊數(shù)據(jù)。所以我們建議使用 InnoDB存儲(chǔ)引擎的 MySQL用戶在創(chuàng)建表時(shí)，必須顯示指定主鍵。

　　主鍵索引與業(yè)務(wù)相關(guān)

　　如果用戶在創(chuàng)建表時(shí)指定的主鍵與業(yè)務(wù)相關(guān)，可能會(huì)被頻繁地更新，這樣會(huì)引起MySQL數(shù)據(jù)庫(kù)的 InnoDB存儲(chǔ)引擎進(jìn)行頻繁的節(jié)點(diǎn)合并和分裂，造成大量額外的系統(tǒng) IO開銷，影響數(shù)據(jù)庫(kù)的插入和更新性能。

　　我們推薦開發(fā)者在創(chuàng)建表時(shí)指定與業(yè)務(wù)無(wú)關(guān)的自增字段作為主鍵，這樣不僅會(huì)提高按時(shí)間序插入的性能(順序?qū)懭胗脖P)，同時(shí)也可以提高按插入時(shí)間范圍檢索的查詢效率。

　　冗余索引

　　如果一個(gè)索引涉及的字段屬性包含另外一個(gè)索引涉及的字段屬性，同時(shí)兩個(gè)索引字段順序一致，且兩個(gè)索引的首字段屬性相同，則可以認(rèn)為涉及字段少的索引為冗余索引。

　　在 MySQL 5.7推出 sys庫(kù)之前，我們可以通過(guò) percona的工具 pt-duplicate-key-checker來(lái)完成對(duì)冗余索引的檢查，在 MySQL 5.7中，我們可以通過(guò) sys庫(kù) schema_redundant_indexes表來(lái)完成。

　　低效索引

　　索引的作用在于通過(guò)索引，查詢可以掃描更少的記錄。數(shù)據(jù)庫(kù)中的記錄在索引字段區(qū)分度越高，掃描的記錄數(shù)就越少，執(zhí)行的效率就越高。如果數(shù)據(jù)庫(kù)表中的記錄在索引字段區(qū)分度不大，索引對(duì)記錄的篩選結(jié)果就不明顯，索引就無(wú)法起到加速查詢的作用。

　　通過(guò)數(shù)據(jù)庫(kù)記錄在索引字段的區(qū)分度，我們可以衡量索引的執(zhí)行效率。MySQL系統(tǒng)庫(kù) mysql庫(kù)下，innodb_index_stats表的 stat_value字段，記錄了某張表在某個(gè)索引的不同取值的記錄個(gè)數(shù)， innodb_table_stats表的 n_rows字段記錄了某張表的總記錄數(shù)，二者相除，即可得到數(shù)據(jù)庫(kù)記錄在某個(gè)索引的區(qū)分度。越接近1，表示區(qū)分度越高;低于0.1，則說(shuō)明區(qū)分度較差。開發(fā)者應(yīng)該重新評(píng)估 SQL語(yǔ)句涉及的字段，選擇區(qū)分度高的多個(gè)字段創(chuàng)建索引，通過(guò)運(yùn)行下面的 SQL語(yǔ)句，可以計(jì)算每張表的索引區(qū)分度。

　　select t.database_name AS `db`,

　　t.TABLE_NAME AS `table`,

　　i.INDEX_NAME AS `index name`,

　　i.stat_description as cols ,

　　i.stat_value AS differRows,

　　t.n_rows as rows,

　　ROUND(((i.stat_value / IFNULL(IF(t.n_rows < i.stat_value, i.stat_value, t.n_rows),0.01)) ), 2) AS `sel_percent`

　　from mysql.innodb_index_stats i

　　INNER JOIN mysql.innodb_table_stats t on i.database_name = t.database_name and i.table_name= t.table_name

　　where t.table_name= %

　　AND t.database_name= %

　　AND i.INDEX_NAME != 'PRIMARY'

　　AND i.stat_name like '%n_diff_pfx%';

　　無(wú)效索引

　　如果一個(gè)索引始終無(wú)法被查詢使用，它的存在只能增加數(shù)據(jù)庫(kù)的維護(hù)開銷，開發(fā)者應(yīng)該及時(shí)刪除這些索引。通過(guò) MySQL 5.7 sys庫(kù) schema_unused_indexes視圖，可以查看當(dāng)前實(shí)例哪些索引從沒(méi)有被使用。

　　容量規(guī)劃

　　數(shù)據(jù)庫(kù)的運(yùn)行需要依賴計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等多種資源，對(duì)各種資源歷史使用情況的分析，對(duì)資源配置進(jìn)行合理的規(guī)劃，是確保數(shù)據(jù)庫(kù)穩(wěn)定運(yùn)行的必要條件。

　　CPU

　　CPU利用率是衡量 CPU繁忙程度最直觀的指標(biāo)，通過(guò) top命令，開發(fā)者可以查看 CPU的使用情況。

　　CPU 利用率持續(xù)超過(guò)80%，說(shuō)明計(jì)算資源已經(jīng)接近飽和，如果開發(fā)者已經(jīng)做過(guò) SQL優(yōu)化，則需要使用更高配置的 CPU。通過(guò)查看7天內(nèi) CPU利用率超過(guò)80%的時(shí)間占整體時(shí)間的百分比以及單次持續(xù)時(shí)間超過(guò)的一定的閾值，可清楚 CPU擴(kuò)容的觸發(fā)條件。

　　IO

　　大部分?jǐn)?shù)據(jù)庫(kù)應(yīng)用的都是 IO Bound類型，IO處理能力最常用的衡量指標(biāo)是 IO 利用率。IO 利用率統(tǒng)計(jì)的是一秒內(nèi) IO請(qǐng)求隊(duì)列非空的時(shí)間比例，IO利用率越高就表示硬盤越繁忙。但是 IO利用率100%并不表示系統(tǒng)已經(jīng)無(wú)法處理更多的 IO請(qǐng)求。

　　IOPS和每秒 IO字節(jié)數(shù)可以從存儲(chǔ)設(shè)備的角度更準(zhǔn)確地描述 IO狀態(tài)。每一個(gè)存儲(chǔ)設(shè)備都有 IOPS和每秒 IO字節(jié)數(shù)的上限，任意一個(gè)達(dá)到上限，就會(huì)成為 IO處理能力的瓶頸。在傳統(tǒng)機(jī)械硬盤中，隨機(jī) IO主要受到 IOPS的限制，順序 IO主要受帶寬限制。除此之外，我們還可以從應(yīng)用的角度、使用一次 IO請(qǐng)求的響應(yīng)時(shí)間來(lái)描述 IO負(fù)載。一次 IO請(qǐng)求的響應(yīng)時(shí)間包括其在隊(duì)列中的等待時(shí)間和實(shí)際 IO處理時(shí)間之和。

　　通過(guò) iostats，開發(fā)者可以采集到上述指標(biāo)，如果這些指標(biāo)在一段時(shí)間內(nèi)持續(xù)接近設(shè)定上限，則可以認(rèn)為 IO過(guò)載。通過(guò)擴(kuò)大內(nèi)存，讓更多的讀寫請(qǐng)求命中緩存可以緩解硬盤 IO，因?yàn)閿?shù)據(jù)庫(kù)的應(yīng)用大部分都屬于熱點(diǎn)應(yīng)用。另外，使用更高配置的存儲(chǔ)設(shè)備，例如固態(tài)硬盤，可以大幅提高系統(tǒng)的 IO處理能力。

　　存儲(chǔ)空間

　　存儲(chǔ)空間不足會(huì)導(dǎo)致嚴(yán)重的系統(tǒng)故障，數(shù)據(jù)庫(kù)可能宕機(jī)，更為嚴(yán)重的是數(shù)據(jù)庫(kù)進(jìn)程存活但是無(wú)法響應(yīng)服務(wù)，從而造成基于進(jìn)程的監(jiān)控失效。根據(jù)7天內(nèi)數(shù)據(jù)庫(kù)中存儲(chǔ)數(shù)據(jù)的變化，我們可以估算出未來(lái)3天內(nèi)數(shù)據(jù)的增長(zhǎng)情況，從而判斷實(shí)例是否存在存儲(chǔ)空間不足的風(fēng)險(xiǎn)。

　　內(nèi)存

　　使用 InnoDB存儲(chǔ)引擎的 MySQL數(shù)據(jù)庫(kù)在實(shí)例啟動(dòng)時(shí)，就會(huì)預(yù)分配一塊固定大小的內(nèi)存空間，所有讀寫請(qǐng)求都會(huì)在該空間中完成。如果內(nèi)存中緩存了用戶讀寫的數(shù)據(jù)，則直接讀取內(nèi)存，如果內(nèi)存中沒(méi)有用戶讀寫的數(shù)據(jù)，則需要將數(shù)據(jù)先從硬盤中 load進(jìn)內(nèi)存中。由于內(nèi)存的讀寫速度遠(yuǎn)遠(yuǎn)快于硬盤，這就使得讀寫請(qǐng)求是否命中內(nèi)存決定了讀寫請(qǐng)求的處理速度。內(nèi)存空間越大，緩存數(shù)據(jù)越多，命中的幾率也就越大。所以我們可以使用緩存命中率來(lái)衡量?jī)?nèi)存空間大小是否滿足應(yīng)用的需求。

　　在MySQL中，show engine innodb status 命令的 Buffer pool hit rate可以度量從上一次執(zhí)行 show engine innodb status到本次時(shí)間范圍內(nèi) Buffer pool的命中情況。

　　網(wǎng)絡(luò)

　　網(wǎng)絡(luò)帶寬在數(shù)據(jù)庫(kù)返回記錄較多的情況下，也可能會(huì)成為系統(tǒng)的瓶頸。一般我們使用每秒網(wǎng)絡(luò)流入和流出字節(jié)數(shù)來(lái)衡量網(wǎng)絡(luò)流量是否達(dá)到帶寬限制。在云環(huán)境下，每臺(tái)虛擬機(jī)或者容器都是有一定的網(wǎng)絡(luò)帶寬配額，私有網(wǎng)絡(luò)的配額會(huì)比較大，公網(wǎng)配額與用戶付費(fèi)相關(guān);使用 iftop 可以查看當(dāng)前系統(tǒng)的網(wǎng)絡(luò)流量。

　　服務(wù)安全

　　弱密碼

　　MySQL的登陸認(rèn)證使用的是 IP+賬戶密碼的方式，很多開發(fā)者為了方便記憶，習(xí)慣將數(shù)據(jù)庫(kù)密碼設(shè)置為弱密碼，這實(shí)際是非常危險(xiǎn)的。數(shù)據(jù)庫(kù)中的數(shù)據(jù)很多涉及敏感業(yè)務(wù)，弱密碼非常容易被破解，對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)是一個(gè)嚴(yán)重的安全隱患。

　　MySQL系統(tǒng)庫(kù) mysql庫(kù)下的 user表的 password字段保存了所有用戶的密碼，MySQL使用的是兩次 sha-1的不可逆加密算法，所以我們無(wú)法通過(guò) password字段獲取用戶的密碼內(nèi)容，但是我們可以通過(guò)將常見弱密碼制成彩虹表，模擬 MySQL的加密算法，匹配 password字段，即可發(fā)現(xiàn)數(shù)據(jù)庫(kù)中的弱密碼賬號(hào)。

　　網(wǎng)絡(luò)安全

　　在一般的業(yè)務(wù)架構(gòu)中，數(shù)據(jù)庫(kù)都不會(huì)直接服務(wù)于終端用戶，而是服務(wù)于運(yùn)行業(yè)務(wù)邏輯的應(yīng)用程序。所以數(shù)據(jù)庫(kù)和業(yè)務(wù)程序之間出于安全考慮，會(huì)選擇使用私有網(wǎng)絡(luò)。即使使用私有網(wǎng)絡(luò)，為了避免數(shù)據(jù)庫(kù)連錯(cuò)，也需要在設(shè)置數(shù)據(jù)庫(kù)賬號(hào)時(shí)，增加 IP來(lái)源限制。

　　在一些特定的場(chǎng)景下，如果數(shù)據(jù)訪問(wèn)必須借助公網(wǎng)來(lái)實(shí)現(xiàn)，就會(huì)將數(shù)據(jù)庫(kù)暴露在公網(wǎng)上。使用公網(wǎng)數(shù)據(jù)庫(kù)實(shí)例，必須要配置防火墻，否則存在被攻擊的隱患，通過(guò) iptables我們可以控制訪問(wèn)數(shù)據(jù)庫(kù)的來(lái)源 IP。

　　權(quán)限檢查

　　MySQL提供了多種權(quán)限配置，為了方便管理以及避免誤操作，一般會(huì)將管理權(quán)限和訪問(wèn)權(quán)限配置成兩個(gè)不同的賬號(hào)，禁止使用管理權(quán)限作為業(yè)務(wù)程序訪問(wèn)數(shù)據(jù)庫(kù)的賬號(hào)。通過(guò)系統(tǒng)庫(kù) mysql庫(kù)的 user表可以確認(rèn)各個(gè)賬號(hào)擁有的權(quán)限，盡量避免業(yè)務(wù)賬號(hào)擁有 super權(quán)限。

　　參數(shù)配置

　　內(nèi)存相關(guān)參數(shù)

　　MySQL數(shù)據(jù)庫(kù)的內(nèi)存使用包括兩個(gè)部分：共享內(nèi)存與連接獨(dú)占內(nèi)存。

　　每一個(gè)用戶新建連接，數(shù)據(jù)庫(kù)都要分配一定的內(nèi)存空間保存用戶的臨時(shí)數(shù)據(jù)，這些空間為單個(gè)連接獨(dú)占。在 MySQL實(shí)例啟動(dòng)時(shí)，系統(tǒng)會(huì)預(yù)先分配一些實(shí)例級(jí)別的連接共享內(nèi)存空間，例如 Innodb_buffer_pool，Innodb_log_buffer_pool等。

　　獨(dú)占內(nèi)存空間乘以最大連接數(shù)加上共享內(nèi)存空間，我們可以計(jì)算出 MySQL最大可使用的內(nèi)存空間，如果超過(guò)實(shí)際物理內(nèi)存大小，就存在 MySQL進(jìn)程被操作系統(tǒng)強(qiáng)行 oom kill風(fēng)險(xiǎn)，導(dǎo)致實(shí)例宕機(jī)。

　　MySQL的這些內(nèi)存空間都可以通過(guò)配置參數(shù)指定大小，如果超過(guò)實(shí)際內(nèi)存空間，應(yīng)該調(diào)整相應(yīng)參數(shù)配置，最常見的是調(diào)整 Innodb_buffer_pool和最大連接數(shù)。

　　memory = key_buffer_size + query_cache_size + tmp_table_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size +

　　innodb_log_buffer_size + max_connections * (sort_buffer_size + read_buffer_size + read_rnd_buffer_size + join_buffer_size +

　　thread_stack + binlog_cache_size)。

　　Innodb 日志相關(guān)參數(shù)

　　innodb_log_file_size 參數(shù)定義了 Innodb 重做日志的大小。如果參數(shù)設(shè)置過(guò)小，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)寫操作頻繁卡頓，如果設(shè)置過(guò)大，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)實(shí)例 recovery花費(fèi)大量的時(shí)間。

　　一般情況下，對(duì)于使用固態(tài)硬盤等高配置存儲(chǔ)設(shè)備的數(shù)據(jù)庫(kù)，我們可以將重做日志設(shè)置大一些;對(duì)于使用機(jī)械硬盤的數(shù)據(jù)庫(kù)，可以設(shè)置小一些，一般在512M到4G之間。innodb_flush_log_at_trx_commit定義了重做日志的刷新節(jié)奏，如果該參數(shù)非1，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)宕機(jī)重啟后丟失部分更新數(shù)據(jù)，對(duì)于數(shù)據(jù)可靠性要求較高的應(yīng)用造成嚴(yán)重影響。

　　二進(jìn)制日志相關(guān)參數(shù)

　　binlog 主要在 MySQL集群復(fù)制以及故障恢復(fù)中擔(dān)任協(xié)調(diào)者的作用。binlog_format 定義了 binlog的格式，主要包括ROW、STATEMENT、MIXED三種格式。ROW格式是最安全的一種日志格式，會(huì)保證主從數(shù)據(jù)的嚴(yán)格一致，建議使用 ROW格式。

　　但是 ROW格式的 binlog會(huì)占用更多的存儲(chǔ)空間，通過(guò) expire_logs_days可以控制保存 binlog的天數(shù)，如果 binlog占用的存儲(chǔ)空間比例超過(guò)50%，則應(yīng)考慮適當(dāng)減少 binlog的保存天數(shù)。 sync_binlog 參數(shù)定義了 binlog刷新硬盤的節(jié)奏，如果非1，會(huì)導(dǎo)致宕機(jī)重啟后部分?jǐn)?shù)據(jù)丟失。

　　連接數(shù)相關(guān)參數(shù)

　　MySQL有最大連接數(shù)限制 max_connections，如果應(yīng)用連接超過(guò) max_connetions限制，則會(huì)得到 out of max connections異常，無(wú)法建立連接。

　　show processlist 可以查看當(dāng)前的連接數(shù)，如果接近最大限制，則存在無(wú)法新建連接的風(fēng)險(xiǎn)。通過(guò)使用連接池可以控制數(shù)據(jù)庫(kù)的連接數(shù)。

　　用戶訪問(wèn)

　　慢連接

　　慢查詢數(shù)量是最直觀的反映數(shù)據(jù)庫(kù)處理能力是否滿足業(yè)務(wù)需求的指標(biāo)。通過(guò)設(shè)置 slow_query_log可以開啟慢查詢?nèi)罩?，MySQL數(shù)據(jù)庫(kù)會(huì)將執(zhí)行時(shí)間超過(guò) long_query_time的查詢記入慢查詢?nèi)罩尽Ｈ绻硞€(gè)時(shí)間段內(nèi)，慢查詢數(shù)量急劇增加，則開發(fā)者就必須要關(guān)注數(shù)據(jù)庫(kù)的性能問(wèn)題，首先就需要進(jìn)行 SQL優(yōu)化，其次考慮資源是否需要擴(kuò)容，最后可能需要數(shù)據(jù)庫(kù)水平擴(kuò)展方案，包括創(chuàng)建只讀從節(jié)點(diǎn)。

　　死鎖數(shù)量

　　兩個(gè)事務(wù)涉及的數(shù)據(jù)庫(kù)記錄有重疊，如果 SQL語(yǔ)句的加鎖順序不一致，就會(huì)導(dǎo)致事務(wù)之間的死鎖。雖然 MySQL數(shù)據(jù)庫(kù)會(huì)自動(dòng)檢測(cè)死鎖并強(qiáng)制回滾系統(tǒng)認(rèn)為代價(jià)較小的事務(wù)，但是死鎖的檢測(cè)與事務(wù)回滾都有較大的代價(jià)，會(huì)嚴(yán)重拖慢數(shù)據(jù)庫(kù)的性能，所以當(dāng)系統(tǒng)中出現(xiàn)大量死鎖時(shí)，開發(fā)者必須引起重視，要分析發(fā)生死鎖的事務(wù)的 SQL語(yǔ)句的加鎖規(guī)則，調(diào)整 SQL語(yǔ)句。通過(guò) show engin innodb status可以查看死鎖的相關(guān)信息以及系統(tǒng)的處理過(guò)程。

　　集群復(fù)制

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

　　復(fù)制是 MySQL多個(gè)節(jié)點(diǎn)之間實(shí)現(xiàn)數(shù)據(jù)同步的重要機(jī)制，主要用于搭建高可用實(shí)例主從節(jié)點(diǎn)以及提供多個(gè)只讀從節(jié)點(diǎn)提高讀擴(kuò)展能力。節(jié)點(diǎn)之間的數(shù)據(jù)是否最終一致對(duì)于高可用方案是否生效、只讀實(shí)例讀取的數(shù)據(jù)是否正確有著嚴(yán)重影響。

　　從機(jī)執(zhí)行 show slave status可以獲取從機(jī)的復(fù)制狀態(tài)，Slave_IO_Running和 Slave_SQL_Running分別表示 IO和 SQL線程是否運(yùn)行正常，如果不正常，則應(yīng)及時(shí)處理。參數(shù) relay_log_recovery和 relay_log_info_repository影響從節(jié)點(diǎn)宕機(jī)重啟后，與主機(jī)的復(fù)制位置是否正確，如果位置錯(cuò)誤，則可能導(dǎo)致數(shù)據(jù)錯(cuò)誤。

　　復(fù)制性能

　　復(fù)制延遲經(jīng)常用來(lái)評(píng)估復(fù)制性能是否滿足業(yè)務(wù)需求。Show slave status的 Seconds behind master字段標(biāo)識(shí)了從機(jī)落后主機(jī)的延遲時(shí)間。如果延遲較長(zhǎng)，則會(huì)影響高可用實(shí)例主從切換的時(shí)間以及只讀從節(jié)點(diǎn)是否能夠及時(shí)讀到最新數(shù)據(jù)。

　　通過(guò)使用并行復(fù)制技術(shù)可以提高從節(jié)點(diǎn)的復(fù)制性能。MySQL 5.6 提供了基于 Database級(jí)別的并行復(fù)制，通過(guò) slave_parallel_workers 設(shè)置并行線程數(shù);MySQL 5.7提供了基于 LOGICAL_CLOCK的并行復(fù)制， 主機(jī)上同一個(gè) Group提交的 binlog中包含事務(wù)在從機(jī)并行執(zhí)行，相比 Database，具備更高的并發(fā)性，除了設(shè)置 slave_parallel_workers，還需要將 slave-parallel-type設(shè)置為 LOGICAL_CLOCK。slave_preserve_commit_order=1可以確保從機(jī)并行執(zhí)行的事務(wù)按序提交。同時(shí)從機(jī)的 log_bin和 log_slave_updates參數(shù)必須同時(shí)開啟。

　　這樣繁瑣又細(xì)致的過(guò)程極其考驗(yàn)我們的耐心， 如果你是網(wǎng)易蜂巢的開發(fā)者，這些工作都可以一鍵解決。

　　網(wǎng)易蜂巢智能數(shù)據(jù)庫(kù)健康診斷系統(tǒng)

　　使用網(wǎng)易蜂巢的開發(fā)者，可以使用平臺(tái)提供的智能健康診斷系統(tǒng)對(duì)數(shù)據(jù)庫(kù)服務(wù)中的關(guān)系數(shù)據(jù)庫(kù)實(shí)例進(jìn)行自動(dòng)健康檢查。檢查內(nèi)容覆蓋6個(gè)大類，22個(gè)子項(xiàng)，檢查結(jié)束后根據(jù)檢查結(jié)果，會(huì)自動(dòng)生成健康指數(shù)，開發(fā)者根據(jù)健康指數(shù)，可以快速判斷系統(tǒng)存在風(fēng)險(xiǎn)的嚴(yán)重程度，同時(shí)平臺(tái)提供了該分?jǐn)?shù)在所有實(shí)例的健康檢查中的排名。

　　有風(fēng)險(xiǎn)的項(xiàng)目，平臺(tái)會(huì)使用橙色標(biāo)識(shí)，開發(fā)者點(diǎn)擊風(fēng)險(xiǎn)項(xiàng)目，會(huì)看到系統(tǒng)對(duì)該風(fēng)險(xiǎn)的詳細(xì)描述以及相應(yīng)的修復(fù)建議。針對(duì)部分檢查內(nèi)容，系統(tǒng)提供了一鍵自動(dòng)修復(fù)功能。

　　RDS