雲上 MySQL 的這8個要點，運維，請了解一下~

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

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

1.基礎版是單個節點部署，價格低，成本效益非常高，由于是單節點，資料安全性以及可用性不能保證，不建議生産環境使用

2.高可用版采用一主 N 從的高可用模式，實時熱備，提供當機自動檢測和故障自動轉移。主從複制方式有三種：異步、半同步、強同步。高可用版預設一主一從異步複制方式，可以通過購買和更新遷移到一主二從強同步模式。

3.單節點高 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 在資料庫所在的實體機發生硬體故障時是如何保證高可用呢？

1.主所在實體機發生故障：

正常情況下，用戶端通過VIP:Port的方式連結到主庫上，從庫通過binlog和主進行同步。如下圖中的步驟1

當主庫所在的主控端發生異常當機，此時用戶端的連結就會被切換到從庫（用戶端具有斷線重連幾乎不受影響），此時從庫進行讀寫。主庫故障後，雲平台會自動生成一個新的主從高可用執行個體，将最近一天的冷備導入到新執行個體對，在和目前的舊的從庫進行 binlog 的同步。如下圖中的步驟2

binlog 增量同步完成後，舊的從庫會和新的執行個體對一直進行同步狀态，直至維護時間再次進行主動切換，切換時存在秒級閃斷，業務有重連可以忽略閃斷。此時用戶端直接通過VIP+Port的方式連接配接到建立的執行個體對。舊執行個體就會被删除。詳細的步驟如下圖步驟 3

2.從所在的實體機發生故障

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

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

在控制台發起執行個體更新的任務後，雲平台會自動建立一個新的執行個體對，該新執行個體對的配置是需要調整到的配置。先将最近一次的備份導出到建立執行個體對内，在和主執行個體進行binlog同步。如下圖步驟1

主執行個體和建立執行個體對同步完成後，使用者可以自行選擇立即切換或在維護期内切換。整個切換過程秒級即可完成，完成後嗎，用戶端連接配接資料庫請求都會到目标執行個體對，源執行個體對則會被自動回收。如下圖步驟2

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

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

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

（版權歸原作者所有，侵删