這八個雲Mysql的要點，運維一定要了解

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

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

例項型別
目前雲資料庫 MySQL 支援三種架構：基礎版、高可用版、單節點高 IO 版。

• 基礎版是單個節點部署，價格低，價效比非常高，由於是單節點，資料安全性以及可用性不能保證，不建議生產環境使用
• 高可用版採用一主 N 從的高可用模式，實時熱備，提供當機自動檢測和故障自動轉移。主從複製方式有三種：非同步、半同步、強同步。高可用版預設一主一從非同步複製方式，可以透過購買和升級遷移到一主二從強同步模式。
• 單節點高 IO 版採用單個物理節點部署，價效比高；底層儲存使用本地 NVMe SSD 硬碟，提供強大的 IO 效能。目前應用於只讀例項，幫助業務分攤讀壓力，適用於有讀寫分離需求的各個行業應用。
資料庫例項複製方式
非同步複製

應用發起資料更新（含 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 上操作的問題，提高了強同步複製叢集的可用性。

高可用實現原理

目前使用最多的就是高可用版本的一主一從架構，正常情況下，客戶透過 VIP:Port 的方式連結到主庫上，從庫透過 binlog 和主進行同步。雲上 MySQL 在資料庫所在的物理機發生硬體故障時是如何保證高可用呢？

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



從所在的物理機發生故障

從庫所在的物理機發生故障是，對客戶端來說業務是完全不受影響，在從庫所在物理機異常後，雲平臺會自動發起重建從庫的流程，在健康的物理機上新建一個從庫，匯入冷備資料後和主庫進行同步，同步完畢後，此時資料庫又恢復了主從高可用狀態。

例項升級

資料庫的升級不僅包含資料庫版本升級，還包括硬體升配，當然硬體的降配具體的原理也是一樣的。

• 在控制檯發起例項升級的任務後，雲平臺會自動建立一個新的例項對，該新例項對的配置是需要調整到的配置。先將最近一次的備份匯出到新建例項對內，在和主例項進行 binlog 同步。如下圖步驟 1
• 主例項和新建例項對同步完成後，使用者可以自行選擇立即切換或在維護期內切換。整個切換過程秒級即可完成，完成後嗎，客戶端連線資料庫請求都會到目標例項對，源例項對則會被自動回收。如下圖步驟 2

從上面的步驟我們可以看到升級例項時，完全不影響資料庫的正常使用。升級主要花費的時間是匯入冷備和追 binlog 這兩個步驟，而這兩個環節的所需的時間取決於客戶的資料量大小和產生的 binlog 的大小。一般匯入冷備的速度是 50G/h（理論值僅供參考）。



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。

回檔介紹

回檔是將資料庫透過冷備和 binlog 恢復到之前的某個時間點的一種操作。CDB 的回檔分為普通回檔、快速回檔以及極速回檔：

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

慢查詢就是執行資料庫查詢時消耗時間比較大的 SQL 語句。MySQL CPU 利用率過高，大部分原因與低效 SQL 有關係，透過最佳化低效 SQL 基本可以解決大部分問題。MySQL 慢查詢時間的預設值是 10s，在遇到效能問題時，若發現沒有慢查詢，建議將其引數調成 1s ，再觀察業務週期內的慢查詢，進而對其慢查詢進行最佳化。

如果出現全表掃描較高的情況，可以開啟 log_queries_not_using_indexes 引數，此時未使用索引的全表掃描也可以記錄到慢查詢裡面。這個引數並不建議一直開啟，會對資料庫的磁碟造成較大影響。

MySQL 空間

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

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

原文來自：