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

女友在高考發表於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介面，方便運維管理。

相關文章