效能優化資料庫篇-從單機到叢集

女友在高考 發表於 2021-07-18
資料庫

從單機到叢集

隨著資料量增加,讀寫併發的增加,系統可用性要求的提升,單機MySQL存在著一些問題:

  • 容量有限,難以擴容
  • 讀寫壓力、QPS過大,特別是分析類需求會影響到業務事務
  • 可用性不足,單點故障

效能優化資料庫篇-從單機到叢集

1 主從複製

核心流程是:

  1. 主庫寫binlog
  2. 從庫拉取binlog寫入relay log

效能優化資料庫篇-從單機到叢集

binlog格式

  • Row

這個模式存的是哪條記錄被修改,修改成什麼樣.缺點是日誌內容大。

  • Statement

存的是sql語句,日誌量少。缺點是一些函式、觸發器同步可能有障礙。

  • Mixed

兩種模式的結合,根據執行的sql語句來區分對待記錄的日誌形式。

檢視binlog命令,進入mysql的bin目錄下執行。

mysqlbinlog --no-defaults ../data/binlog.000116

修改binlog模式

  1. 先檢視binlog格式

SHOW VARIABLES LIKE "%binlog_format%";

  1. 線上修改

set global binlog_format='MIXED';

  1. 使用配置修改

配置檔案my.ini中加入

binlog_format="MIXED" #開啟MIXED模式

修改後重啟mysql服務

主從複製方案

  1. 非同步複製

傳統的主從複製,網路或機器故障,會導致資料不一致

效能優化資料庫篇-從單機到叢集

  1. 半同步複製

保證Source和Replica最終一致性
效能優化資料庫篇-從單機到叢集

  1. 組複製 (Mysql Group Replication)

簡稱MGR,基於分散式協議Paxos實現,保證資料一致性

效能優化資料庫篇-從單機到叢集

主從複製實戰

非同步複製

  1. 準備兩個mysql例項
  2. 修改master的那個mysql例項的my.cnf配置檔案,增加如下內容,並重啟mysql
server-id=1
log-bin=mysql-bin
  1. 登入master的mysql,建立一個同步資料的使用者
CREATE USER 'slave'@'%' IDENTIFIED BY '123456';

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
  1. 修改slave的那個mysql例項的my.cnf配置檔案,增加如下內容,並重啟mysql
server-id=2
log-bin=mysql-bin
  1. 登入master的mysql,執行
show master status;

記錄下File和Position
效能優化資料庫篇-從單機到叢集

  1. 登入slave的mysql,配置從庫
change master to master_host='192.168.161.21', master_user='slave', master_password='123456', master_port=3306, master_log_file='mysql-bin.000001', master_log_pos= 837, master_connect_retry=30;

master_log_file和master_log_pos就是上面記錄下的File和Position。

執行完後繼續執行下面的命令,開啟主從複製

start slave
  1. 檢視主從複製是否生效
show slave status \G;

兩個都是YES,說明成功
效能優化資料庫篇-從單機到叢集

  1. 測試,在主庫上新建資料庫,新建表,插入資料,然後檢視從庫的資料情況即可。

主從複製的侷限性

  1. 主從延遲問題
  2. 應用端需要配合讀寫分離框架
  3. 不解決高可用的問題

2 讀寫分離

方案1:

基於Spring提供的路由資料來源AbstractRoutingDataSource以及AOP

缺點:

  • 程式碼侵入性強
  • 同一個service中有“寫完讀”資料不一致問題

具體實現:https://www.cnblogs.com/cjsblog/p/9712457.html

方案2:

ShardingSphere-jdbc 的 Master-Slave 功能

缺點:

  • 對業務系統還是有侵入
  • 對已存在的舊系統改造不友好

具體操作:https://www.cnblogs.com/javammc/p/12470838.html

方案3:

使用MyCat/ShardingSphere-Proxy的Master-Slave功能

部署中介軟體,規則配置在中介軟體中,業務系統無侵入。

3 MySQL高可用

什麼是高可用?

高可用代表著更少的不可服務的時間。一般網際網路公司要求達到4個9,即一年不能服務的時間不超過52.6分鐘

99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小時

99.99 = 8760 * 0.0001 = 0.876小時 = 0.876 * 60 = 52.6分鐘

資料庫要實現高可用,需要做到

  1. 讀寫分離,提高讀的處理能力
  2. 故障轉移,災難恢復

常見的一些策略有:

  • 多個例項不在一個主機上
  • 跨機房部署
  • 兩地三中心容災高可用方案

3.1 MySQL高可用方案

方案1:主從手動切換

如果主節點掛掉了,將某個從改為主。然後配置其他從節點。應用側需要修改資料來源配置。

缺點:

  1. 可能資料不一致
  2. 需要人工操作
  3. 程式碼和配置的侵入性

方案2:主從手動切換2

用LVS+Keepalived實現多個節點的探活+請求路由
,配置VIP或DNS實現應用側配置不變更

缺點:

  • 也需要手工操作
  • 大量的配置和指令碼定義

方案3:MHA

MHA(Master High Availability)目前在 MySQL 高可用方面是一個相對成熟的解決方案,它由日本 DeNA 公司的 youshimaton(現就職於 Facebook 公司)開發,是一套優秀的作為 MySQL 高可用性環境下故障切換和主從提升的高可用軟體。

基於Perl語言開發,一般能在30S內實現主從切換。切換時通過SSh複製主節點的日誌。

缺點:

  • 需要配置SSH資訊
  • 至少3臺機器

方案4:MGR

Mysql Group Replication(MGR)

MGR的特點:

  1. 高一致性:基於分散式協議Paxos實現組複製,保證資料一致性
  2. 高容錯性:自動檢測機制,只要不是大多數節點當機都可以繼續工作
  3. 高擴充套件性:節點的的增加與移除會自動更新組成員資訊。新節點加入後,自動從其他節點通過增量資料,直到與其他節點資料一致
  4. 高靈活性:提高單主模式和多主模式,單主模式在主庫當機後自動選主,多主模式支援多節點寫入。
    如果主節點掛掉,將自動選擇某個從改為主。無需人工干預,基於組複製,保證資料一致性。

缺點:

  • 外部獲得狀態變更需要讀取資料庫
  • 外部需要使用LVS/VIP配置

方案5:Mysql Cluster

MySQL InnoDB Cluster是一個高可用的框架,它由下面這幾個元件構成:

  1. MySQL Group Replication :提供DB的擴充套件、自動故障轉移
  2. MySQL Router:輕量級中介軟體,提供應用程式負載均衡和應用連線的故障轉移
  3. MySQL Shell:新的MySQL客戶端,多種介面模式

方案6:orchestrator

一款MySQL高可用和複製拓撲管理工具,支援自動故障轉移和手動主從切換等。通過Web介面操作可以更改Mysql例項的複製關係和部分配置資訊,同時提供命令列和API介面,方便運維管理。