使用云上的 MySQL 時(shí)，會(huì)遇到很多人詢問 CDB 的。為了更好的了解云上的 MySQL，本文將介紹一些重要的知識(shí)點(diǎn)。

1.實(shí)例類型

目前云數(shù)據(jù)庫(kù) MySQL 支持三種架構(gòu)：基礎(chǔ)版、高可用版、單節(jié)點(diǎn)高 IO 版

1.基礎(chǔ)版是單個(gè)節(jié)點(diǎn)部署，價(jià)格低，性價(jià)比非常高，由于是單節(jié)點(diǎn)，數(shù)據(jù)安全性以及可用性不能保證，不建議生產(chǎn)環(huán)境使用

2.高可用版采用一主 N 從的高可用模式，實(shí)時(shí)熱備，提供宕機(jī)自動(dòng)檢測(cè)和故障自動(dòng)轉(zhuǎn)移。主從復(fù)制方式有三種：異步、半同步、強(qiáng)同步。高可用版默認(rèn)一主一從異步復(fù)制方式，可以通過購(gòu)買和升級(jí)遷移到一主二從強(qiáng)同步模式。

3.單節(jié)點(diǎn)高 IO 版采用單個(gè)物理節(jié)點(diǎn)部署，性價(jià)比高；底層存儲(chǔ)使用本地 NVMe SSD 硬盤，提供強(qiáng)大的 IO 性能。目前應(yīng)用于只讀實(shí)例，幫助業(yè)務(wù)分?jǐn)傋x壓力，適用于有讀寫分離需求的各個(gè)行業(yè)應(yīng)用。

2.數(shù)據(jù)庫(kù)實(shí)例復(fù)制方式

異步復(fù)制

應(yīng)用發(fā)起數(shù)據(jù)更新（含 insert、update、delete 等操作）請(qǐng)求，Master 在執(zhí)行完更新操作后立即向應(yīng)用程序返回響應(yīng)，然后 Master 再向 Slave 復(fù)制數(shù)據(jù)。

數(shù)據(jù)更新過程中 Master 不需要等待 Slave 的響應(yīng)，因此異步復(fù)制的數(shù)據(jù)庫(kù)實(shí)例通常具有較高的性能，且 Slave 不可用并不影響 Master 對(duì)外提供服務(wù)。但因數(shù)據(jù)并非實(shí)時(shí)同步到 Slave，而 Master 在 Slave 有延遲的情況下發(fā)生故障則有較小概率會(huì)引起數(shù)據(jù)不一致。騰訊云數(shù)據(jù)庫(kù) MySQL 異步復(fù)制采用一主一從的架構(gòu)。

半同步復(fù)制

應(yīng)用發(fā)起數(shù)據(jù)更新（含 insert、update、delete 操作）請(qǐng)求，Master 在執(zhí)行完更新操作后立即向 Slave 復(fù)制數(shù)據(jù)，Slave 接收到數(shù)據(jù)并寫到 relay log 中（無(wú)需執(zhí)行） 后才向 Master 返回成功信息，Master 必須在接受到 Slave 的成功信息后再向應(yīng)用程序返回響應(yīng)。

僅在數(shù)據(jù)復(fù)制發(fā)生異常（Slave 節(jié)點(diǎn)不可用或者數(shù)據(jù)復(fù)制所用網(wǎng)絡(luò)發(fā)生異常）的情況下，Master 會(huì)暫停（MySQL 默認(rèn)10秒左右）對(duì)應(yīng)用的響應(yīng)，將復(fù)制方式降為異步復(fù)制。當(dāng)數(shù)據(jù)復(fù)制恢復(fù)正常，將恢復(fù)為半同步復(fù)制。

騰訊云數(shù)據(jù)庫(kù) MySQL 半同步復(fù)制采用一主一從的架構(gòu)。

強(qiáng)同步復(fù)制

應(yīng)用發(fā)起數(shù)據(jù)更新（含 insert、update、delete 操作）請(qǐng)求，Master 在執(zhí)行完更新操作后立即向 Slave 復(fù)制數(shù)據(jù)，Slave 接收到數(shù)據(jù)并執(zhí)行完 后才向 Master 返回成功信息，Master 必須在接受到 Slave 的成功信息后再向應(yīng)用程序返回響應(yīng)。

因 Master 向 Slave 復(fù)制數(shù)據(jù)是同步進(jìn)行的，Master 每次更新操作都需要同時(shí)保證 Slave 也成功執(zhí)行，因此強(qiáng)同步復(fù)制能最大限度的保障主從數(shù)據(jù)的一致性。但因每次 Master 更新請(qǐng)求都強(qiáng)依賴于 Slave 的返回，因此 Slave 如果僅有單臺(tái)，它不可用將會(huì)極大影響 Master 上的操作。

騰訊云數(shù)據(jù)庫(kù) MySQL 強(qiáng)同步復(fù)制采用一主兩從的架構(gòu)，僅需其中一臺(tái) Slave 成功執(zhí)行即可返回，避免了單臺(tái) Slave 不可用影響 Master 上操作的問題，提高了強(qiáng)同步復(fù)制集群的可用性。

3.高可用實(shí)現(xiàn)原理

目前使用最多的就是高可用版本的一主一從架構(gòu)，正常情況下，客戶通過VIP:Port的方式鏈接到主庫(kù)上，從庫(kù)通過 binlog 和主進(jìn)行同步。云上 MySQL 在數(shù)據(jù)庫(kù)所在的物理機(jī)發(fā)生硬件故障時(shí)是如何保證高可用呢？

1.主所在物理機(jī)發(fā)生故障：

正常情況下，客戶端通過VIP:Port的方式鏈接到主庫(kù)上，從庫(kù)通過binlog和主進(jìn)行同步。如下圖中的步驟1

當(dāng)主庫(kù)所在的宿主機(jī)發(fā)生異常宕機(jī)，此時(shí)客戶端的鏈接就會(huì)被切換到從庫(kù)（客戶端具有斷線重連幾乎不受影響），此時(shí)從庫(kù)進(jìn)行讀寫。主庫(kù)故障后，云平臺(tái)會(huì)自動(dòng)生成一個(gè)新的主從高可用實(shí)例，將最近一天的冷備導(dǎo)入到新實(shí)例對(duì)，在和當(dāng)前的舊的從庫(kù)進(jìn)行 binlog 的同步。如下圖中的步驟2

binlog 增量同步完成后，舊的從庫(kù)會(huì)和新的實(shí)例對(duì)一直進(jìn)行同步狀態(tài)，直至維護(hù)時(shí)間再次進(jìn)行主動(dòng)切換，切換時(shí)存在秒級(jí)閃斷，業(yè)務(wù)有重連可以忽略閃斷。此時(shí)客戶端直接通過VIP+Port的方式連接到新建的實(shí)例對(duì)。舊實(shí)例就會(huì)被刪除。

2.從所在的物理機(jī)發(fā)生故障

從庫(kù)所在的物理機(jī)發(fā)生故障是，對(duì)客戶端來說業(yè)務(wù)是完全不受影響，在從庫(kù)所在物理機(jī)異常后，云平臺(tái)會(huì)自動(dòng)發(fā)起重建從庫(kù)的流程，在健康的物理機(jī)上新建一個(gè)從庫(kù)，導(dǎo)入冷備數(shù)據(jù)后和主庫(kù)進(jìn)行同步，同步完畢后，此時(shí)數(shù)據(jù)庫(kù)又恢復(fù)了主從高可用狀態(tài)。

4.實(shí)例升級(jí)

數(shù)據(jù)庫(kù)的升級(jí)不僅包含數(shù)據(jù)庫(kù)版本升級(jí)，還包括硬件升配，當(dāng)然硬件的降配具體的原理也是一樣的。

在控制臺(tái)發(fā)起實(shí)例升級(jí)的任務(wù)后，云平臺(tái)會(huì)自動(dòng)創(chuàng)建一個(gè)新的實(shí)例對(duì)，該新實(shí)例對(duì)的配置是需要調(diào)整到的配置。先將最近一次的備份導(dǎo)出到新建實(shí)例對(duì)內(nèi)，在和主實(shí)例進(jìn)行binlog同步。

主實(shí)例和新建實(shí)例對(duì)同步完成后，用戶可以自行選擇立即切換或在維護(hù)期內(nèi)切換。整個(gè)切換過程秒級(jí)即可完成，完成后嗎，客戶端連接數(shù)據(jù)庫(kù)請(qǐng)求都會(huì)到目標(biāo)實(shí)例對(duì)，源實(shí)例對(duì)則會(huì)被自動(dòng)回收。

從上面的步驟我們可以看到升級(jí)實(shí)例時(shí)，完全不影響數(shù)據(jù)庫(kù)的正常使用。升級(jí)主要花費(fèi)的時(shí)間是導(dǎo)入冷備和追 binlog 這兩個(gè)步驟，而這兩個(gè)環(huán)節(jié)的所需的時(shí)間取決于客戶的數(shù)據(jù)量大小和產(chǎn)生的 binlog 的大小。一般導(dǎo)入冷備的速度是 50G/h（理論值僅供參考）。

5.binlog介紹

binlog日志用于記錄所有更改數(shù)據(jù)的語(yǔ)句， 俗稱二進(jìn)制日志，主要用于復(fù)制和即時(shí)點(diǎn)恢復(fù)。主從復(fù)制也是依賴于binlog的。類似于Oracle的archivelog，Mongodb的oplog，所有和寫有關(guān)或者可能有關(guān)的語(yǔ)句，都會(huì)記錄在binlog文件中。云上的MySQL數(shù)據(jù)庫(kù)的binlog文件都是每1G自動(dòng)生成一個(gè)（新購(gòu)實(shí)例也可能256M做一次切割），除非做了flush logs的操作。

MySQL的binlog默認(rèn)保留5天，所以如果需要回檔的話，只能恢復(fù)到5天內(nèi)的任意時(shí)間點(diǎn)。

另外控制臺(tái)下載的 binlog 日志，需要在本地解析的話，須確保客戶端的 MySQL 版本與 CDB for MySQL 的版本一致，否則會(huì)出現(xiàn)解析出亂碼的情況，建議使用 3.4 或以上版本的mysqlbinlog

6.回檔介紹

回檔是將數(shù)據(jù)庫(kù)通過冷備和binlog恢復(fù)到之前的某個(gè)時(shí)間點(diǎn)的一種操作。CDB的回檔分為普通回檔、快速回檔以及極速回檔

普通回檔：導(dǎo)入該實(shí)例的全量備份，再在對(duì)選中的庫(kù)、表進(jìn)行回檔。該回檔模式無(wú)限制，但回檔速度較慢

快速回檔：僅導(dǎo)入所選中庫(kù)級(jí)別的備份和binlog，如有跨庫(kù)操作，且關(guān)聯(lián)庫(kù)未被同時(shí)選中，將會(huì)導(dǎo)致回檔失敗

極速回檔：僅導(dǎo)入所選中表級(jí)別的備份和binlog，如有跨表操作，且關(guān)聯(lián)表未被同時(shí)選中，將會(huì)導(dǎo)致回檔失敗。極速模式下，請(qǐng)手動(dòng)選擇需要回檔的表。如果表已經(jīng)被刪除，需要客戶自行創(chuàng)建表在進(jìn)行回檔操作。

7.慢查詢

慢查詢就是執(zhí)行數(shù)據(jù)庫(kù)查詢時(shí)消耗時(shí)間比較大的SQL語(yǔ)句。MySQL CPU 利用率過高，大部分原因與低效 SQL 有關(guān)系，通過優(yōu)化低效 SQL 基本可以解決大部分問題。MySQL 慢查詢時(shí)間的默認(rèn)值是10s，在遇到性能問題時(shí)，若發(fā)現(xiàn)沒有慢查詢，建議將其參數(shù)調(diào)成1s ，再觀察業(yè)務(wù)周期內(nèi)的慢查詢，進(jìn)而對(duì)其慢查詢進(jìn)行優(yōu)化。

如果出現(xiàn)全表掃描較高的情況，可以打開log_queries_not_using_indexes參數(shù)，此時(shí)未使用索引的全表掃描也可以記錄到慢查詢里面。這個(gè)參數(shù)并不建議一直打開，會(huì)對(duì)數(shù)據(jù)庫(kù)的磁盤造成較大影響。

8.MySQL空間

用戶使用查詢語(yǔ)句得到的MySQL空間和控制臺(tái)看到的已使用空間相比有很大出入，為什么？

MySQL 的空洞效應(yīng)導(dǎo)致，使用過程中的一些碎片沒有得到合理釋放因此查詢語(yǔ)句查出來的空間和控制臺(tái)統(tǒng)計(jì)的實(shí)際已使用空間相比少了許多，這部分是碎片，徹底解決需要在夜深人靜的時(shí)候執(zhí)行 optimize table。

來源：https://cloud.tencent.com/developer/article/1579285

編輯：jq