使用雲上的 MySQL 時，會遇到很多人詢問 CDB 的。爲了更好的瞭解雲上的 MySQL，本文將介紹一些重要的知識點。
1.實例類型
目前雲數據庫 MySQL 支持三種架構：基礎版、高可用版、單節點高 IO 版
1.基礎版是單個節點部署，價格低，性價比非常高，由於是單節點，數據安全性以及可用性不能保證，不建議生產環境使用
2.高可用版採用一主 N 從的高可用模式，實時熱備，提供宕機自動檢測和故障自動轉移。主從複製方式有三種：異步、半同步、強同步。高可用版默認一主一從異步複製方式，可以通過購買和升級遷移到一主二從強同步模式。
3.單節點高 IO 版採用單個物理節點部署，性價比高；底層存儲使用本地 NVMe SSD 硬盤，提供強大的 IO 性能。目前應用於只讀實例，幫助業務分攤讀壓力，適用於有讀寫分離需求的各個行業應用。
2.數據庫實例複製方式
異步複製
應用發起數據更新（含 insert、update、delete 等操作）請求，Master 在執行完更新操作後立即嚮應用程序返回響應，然後 Master 再向 Slave 複製數據。
數據更新過程中 Master 不需要等待 Slave 的響應，因此異步複製的數據庫實例通常具有較高的性能，且 Slave 不可用並不影響 Master 對外提供服務。但因數據並非實時同步到 Slave，而 Master 在 Slave 有延遲的情況下發生故障則有較小概率會引起數據不一致。騰訊雲數據庫 MySQL 異步複製採用一主一從的架構。
半同步複製
應用發起數據更新（含 insert、update、delete 操作）請求，Master 在執行完更新操作後立即向 Slave 複製數據，Slave 接收到數據並寫到 relay log 中（無需執行） 後才向 Master 返回成功信息，Master 必須在接受到 Slave 的成功信息後再向應用程序返回響應。
僅在數據複製發生異常（Slave 節點不可用或者數據複製所用網絡發生異常）的情況下，Master 會暫停（MySQL 默認10秒左右）對應用的響應，將複製方式降爲異步複製。當數據複製恢復正常，將恢復爲半同步複製。
騰訊雲數據庫 MySQL 半同步複製採用一主一從的架構。
強同步複製
應用發起數據更新（含 insert、update、delete 操作）請求，Master 在執行完更新操作後立即向 Slave 複製數據，Slave 接收到數據並執行完 後才向 Master 返回成功信息，Master 必須在接受到 Slave 的成功信息後再向應用程序返回響應。
因 Master 向 Slave 複製數據是同步進行的，Master 每次更新操作都需要同時保證 Slave 也成功執行，因此強同步複製能最大限度的保障主從數據的一致性。但因每次 Master 更新請求都強依賴於 Slave 的返回，因此 Slave 如果僅有單臺，它不可用將會極大影響 Master 上的操作。
在公衆號前端技術精選後臺回覆“手冊”，獲取一份驚喜禮包。
騰訊雲數據庫 MySQL 強同步複製採用一主兩從的架構，僅需其中一臺 Slave 成功執行即可返回，避免了單臺 Slave 不可用影響 Master 上操作的問題，提高了強同步複製集羣的可用性。
3.高可用實現原理
目前使用最多的就是高可用版本的一主一從架構，正常情況下，客戶通過VIP:Port的方式鏈接到主庫上，從庫通過 binlog 和主進行同步。雲上 MySQL 在數據庫所在的物理機發生硬件故障時是如何保證高可用呢？
1.主所在物理機發生故障：
正常情況下，客戶端通過VIP:Port的方式鏈接到主庫上，從庫通過binlog和主進行同步。如下圖中的步驟1
當主庫所在的宿主機發生異常宕機，此時客戶端的鏈接就會被切換到從庫（客戶端具有斷線重連幾乎不受影響），此時從庫進行讀寫。主庫故障後，雲平臺會自動生成一個新的主從高可用實例，將最近一天的冷備導入到新實例對，在和當前的舊的從庫進行 binlog 的同步。如下圖中的步驟2
binlog 增量同步完成後，舊的從庫會和新的實例對一直進行同步狀態，直至維護時間再次進行主動切換，切換時存在秒級閃斷，業務有重連可以忽略閃斷。此時客戶端直接通過VIP+Port的方式連接到新建的實例對。舊實例就會被刪除。詳細的步驟如下圖步驟 3
2.從所在的物理機發生故障
從庫所在的物理機發生故障是，對客戶端來說業務是完全不受影響，在從庫所在物理機異常後，雲平臺會自動發起重建從庫的流程，在健康的物理機上新建一個從庫，導入冷備數據後和主庫進行同步，同步完畢後，此時數據庫又恢復了主從高可用狀態。
4.實例升級
數據庫的升級不僅包含數據庫版本升級，還包括硬件升配，當然硬件的降配具體的原理也是一樣的。
在控制檯發起實例升級的任務後，雲平臺會自動創建一個新的實例對，該新實例對的配置是需要調整到的配置。先將最近一次的備份導出到新建實例對內，在和主實例進行binlog同步。如下圖步驟1
主實例和新建實例對同步完成後，用戶可以自行選擇立即切換或在維護期內切換。整個切換過程秒級即可完成，完成後嗎，客戶端連接數據庫請求都會到目標實例對，源實例對則會被自動回收。如下圖步驟2
從上面的步驟我們可以看到升級實例時，完全不影響數據庫的正常使用。升級主要花費的時間是導入冷備和追 binlog 這兩個步驟，而這兩個環節的所需的時間取決於客戶的數據量大小和產生的 binlog 的大小。一般導入冷備的速度是 50G/h（理論值僅供參考）。
5.binlog介紹
binlog日誌用於記錄所有更改數據的語句, 俗稱二進制日誌，主要用於複製和即時點恢復。主從複製也是依賴於binlog的。類似於Oracle的archivelog，Mongodb的oplog，所有和寫有關或者可能有關的語句，都會記錄在binlog文件中。雲上的MySQL數據庫的binlog文件都是每1G自動生成一個（新購實例也可能256M做一次切割），除非做了flush logs的操作。
MySQL的binlog默認保留5天，所以如果需要回檔的話，只能恢復到5天內的任意時間點。
另外控制檯下載的 binlog 日誌，需要在本地解析的話，須確保客戶端的 MySQL 版本與 CDB for MySQL 的版本一致，否則會出現解析出亂碼的情況，建議使用 3.4 或以上版本的mysqlbinlog
6.回檔介紹
回檔是將數據庫通過冷備和binlog恢復到之前的某個時間點的一種操作。CDB的回檔分爲普通回檔、快速回檔以及極速回檔
普通回檔：導入該實例的全量備份，再在對選中的庫、表進行回檔。該回檔模式無限制，但回檔速度較慢
快速回檔：僅導入所選中庫級別的備份和binlog，如有跨庫操作，且關聯庫未被同時選中，將會導致回檔失敗
極速回檔：僅導入所選中表級別的備份和binlog，如有跨表操作，且關聯表未被同時選中，將會導致回檔失敗。極速模式下，請手動選擇需要回檔的表。如果表已經被刪除，需要客戶自行創建表在進行回檔操作。
7.慢查詢
慢查詢就是執行數據庫查詢時消耗時間比較大的SQL語句。MySQL CPU 利用率過高，大部分原因與低效 SQL 有關係，通過優化低效 SQL 基本可以解決大部分問題。MySQL 慢查詢時間的默認值是10s，在遇到性能問題時，若發現沒有慢查詢，建議將其參數調成1s ，再觀察業務週期內的慢查詢，進而對其慢查詢進行優化。
如果出現全表掃描較高的情況，可以打開log_queries_not_using_indexes參數，此時未使用索引的全表掃描也可以記錄到慢查詢裏面。這個參數並不建議一直打開，會對數據庫的磁盤造成較大影響。
8.MySQL空間
用戶使用查詢語句得到的MySQL空間和控制檯看到的已使用空間相比有很大出入，爲什麼？
MySQL 的空洞效應導致，使用過程中的一些碎片沒有得到合理釋放因此查詢語句查出來的空間和控制檯統計的實際已使用空間相比少了許多，這部分是碎片，徹底解決需要在夜深人靜的時候執行 optimize table。
