[[435899]]

使用云上的 MySQL 時，會遇到很多人詢問 CDB 的 為了更好的了解云上的 MySQL，本文將介紹一些重要的知識點。

實例類型

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

•  基礎版是單個節(jié)點部署，價格低，性價比非常高，由于是單節(jié)點，數(shù)據(jù)安全性以及可用性不能保證，不建議生產(chǎn)環(huán)境使用
•  高可用版采用一主 N 從的高可用模式，實時熱備，提供宕機自動檢測和故障自動轉(zhuǎn)移。主從復制方式有三種：異步、半同步、強同步。高可用版默認一主一從異步復制方式，可以通過購買和升級遷移到一主二從強同步模式。
•  單節(jié)點高 IO 版采用單個物理節(jié)點部署，性價比高；底層存儲使用本地 NVMe SSD 硬盤，提供強大的 IO 性能。目前應用于只讀實例，幫助業(yè)務分攤讀壓力，適用于有讀寫分離需求的各個行業(yè)應用。

數(shù)據(jù)庫實例復制方式

異步復制

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

數(shù)據(jù)更新過程中 Master 不需要等待 Slave 的響應，因此異步復制的數(shù)據(jù)庫實例通常具有較高的性能，且 Slave 不可用并不影響 Master 對外提供服務。但因數(shù)據(jù)并非實時同步到 Slave，而 Master 在 Slave 有延遲的情況下發(fā)生故障則有較小概率會引起數(shù)據(jù)不一致。

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

半同步復制

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

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

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

強同步復制

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

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

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

高可用實現(xiàn)原理

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

主所在物理機發(fā)生故障

•  正常情況下，客戶端通過 VIP:Port 的方式鏈接到主庫上，從庫通過 binlog 和主進行同步。如下圖中的步驟 1
•  當主庫所在的宿主機發(fā)生異常宕機，此時客戶端的鏈接就會被切換到從庫（客戶端具有斷線重連幾乎不受影響），此時從庫進行讀寫。主庫故障后，云平臺會自動生成一個新的主從高可用實例，將最近一天的冷備導入到新實例對，在和當前的舊的從庫進行 binlog 的同步。如下圖中的步驟 2
•  binlog 增量同步完成后，舊的從庫會和新的實例對一直進行同步狀態(tài)，直至維護時間再次進行主動切換，切換時存在秒級閃斷，業(yè)務有重連可以忽略閃斷。此時客戶端直接通過 VIP+Port 的方式連接到新建的實例對。舊實例就會被刪除。詳細的步驟如下圖步驟 3

MySQL 主庫故障切換示意圖

從所在的物理機發(fā)生故障

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

實例升級

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

•  在控制臺發(fā)起實例升級的任務后，云平臺會自動創(chuàng)建一個新的實例對，該新實例對的配置是需要調(diào)整到的配置。先將最近一次的備份導出到新建實例對內(nèi)，在和主實例進行 binlog 同步。如下圖步驟 1
•  主實例和新建實例對同步完成后，用戶可以自行選擇立即切換或在維護期內(nèi)切換。整個切換過程秒級即可完成，完成后嗎，客戶端連接數(shù)據(jù)庫請求都會到目標實例對，源實例對則會被自動回收。如下圖步驟 2

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

數(shù)據(jù)庫實例升級示意圖

binlog 介紹

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

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

另外控制臺下載的 binlog 日志，需要在本地解析的話，須確?？蛻舳说?MySQL 版本與 CDB for MySQL 的版本一致，否則會出現(xiàn)解析出亂碼的情況，建議使用 3.4 或以上版本的 mysqlbinlog。

回檔介紹

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

• 普通回檔：導入該實例的全量備份，再在對選中的庫、表進行回檔。該回檔模式無限制，但回檔速度較慢。
•  快速回檔：僅導入所選中庫級別的備份和 binlog，如有跨庫操作，且關聯(lián)庫未被同時選中，將會導致回檔失敗。
•  極速回檔：僅導入所選中表級別的備份和 binlog，如有跨表操作，且關聯(lián)表未被同時選中，將會導致回檔失敗。極速模式下，請手動選擇需要回檔的表。如果表已經(jīng)被刪除，需要客戶自行創(chuàng)建表在進行回檔操作。

慢查詢

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

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

MySQL 空間

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

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