碼迷,mamicode.com
首頁 > 數據庫 > 詳細

MySQL 高可用之 MGR

時間:2019-08-15 17:12:23      閱讀:47      評論:0      收藏:0      [點我收藏+]

標簽:網絡   tran   for   必須   proxy   res   orm   問題:   lz4   

 

 

MGR整體架構及特點

  single-master

    只有一個節點寫入,都可以讀取

  multi-master

    每個節點都可以寫入和讀取

  涉及到的概念:

    group communication system (GCS)

    writeset

    membership

    cerification info

    flow control stats

    paxos

  MGR一致性讀增強

  group_replication_consistency (8.0.14引入)

    EVENTUAL: 默認

    BEFORE: 等待隊列中的事務全部執行完

    BEFORE_ON_PRIMARY_FAILOVER: 等待新primary執行完隊列中事務

    AFTER: 等待數據變更在其他所有節點全部被應用

    BEFORE_AND_AFTER: 

  MGR限制

    僅支持InnoDB,必須有主健

    Binlog 格式: Row,關閉binlog checksum  

    必須開啟GTID

    事務隔離級別: READ COMMITTED (沒有 gap lock)  

    大事務限制: group_replication_transaction_size_limit

    Multi master模式:避免相同表上不同節點并發執行DDL/DML

    集群最大節點; 9 (奇數個數)

 

MGR數據如何實現數據同步

  MGR的數據復制 -> 事務認證

    事務認證

    沖突檢測

      certification_info key: xxhash64(索引名稱+db名+db名長度+表名+表名長度+構成索引唯一性的每個列的值+值長度) Value 是事務的 gtid_executed

      事務分配 gtid

      group_replication_gtid_assignment_block_size

    事務組提交 (group commit)

 

MGR數據復制沖突解決

  問題:

    對于告訴寫入的系統 centification_info 會越來愈大,性能會越來越差?

  處理辦法:

    centification_info 引入清理機制

 

MGR數據復制流控

Flow Control

  流控目的

    保證集群延遲可控 (對于只讀事務不在流控范圍之內)

  出現流控原因

    各節點性能不一致

    木桶短板效應

  參數

    group_replication_flow_control_mode 默認為: quota 開啟流控

    group_replication_flow_control_period 多久進行一次流控統計,單位:秒

    group_replication_flow_control_applier_threshold & group_replication_flow_control_certifier_threshold 事務認證隊列中積累超過多少個待認證的事務才觸發節點流控

 

 

MGR監控點

  當前節點是不是在線

    select member_state from performance_schema.replication_group_members;  

  是不是存在延遲

    獲取到的: select received_transaction_set from performance_schema.replication_connection_status;

    已經執行的: select @@gtid_executed

  當前隊列是不是有積壓

    select count_transaction_in_queue from performanct_schema.replication_group_member_stats where [email protected]@server_uuid;

  當前節點是不是可寫

    select * from performance_shcema.global_variables where variable_name in (‘read_only‘,‘super_read_only‘);

  

MGR優化方向

  運維上

    運維基本復制結構,所有的數據復制,還是邏輯的重放,所以優化也是復制優化點。

    更改:

      slave_parallel_type -> LOGICAL_CLOCK

    增強 SQL_THREAD 個數:

      slave_parallel_workers -> 2-8

    如果CPU瓶頸,網絡沒問題,減少CPU壓縮:

      group_replication_compression_threshold = 1000000 ->  2000000

      由原來的1M變成2M,再進行壓縮(主要針對大事務傳輸優化)

  對于寫量畢竟大環境

    使用single-master

    表結構設計上:減少索引數量,多使用聯合索引

  內核上

    已經嘗試: static const int BROADCASE_GTID_EXECUTED_PERIOD = 60>30; //seconds

  重要參數:

    group_replication_member_expel_timeout (8.0.13+) 

      (5+X) 秒后,節點從group中移除失戀成員

      網絡異常 -> 5秒 -> 失聯猜測 -> X秒 / UNREACHABLE -> 移除 

      X 秒內,group無法增加節點,刪除節點,選舉Primary

    group_replication_unreachable_majority_timeout

      發生網絡分區后,minorty成員X秒內未能恢復連接到majority,進入ERROR

    group_replication_exit_state_action (8.0.12+, 5.7.24+)

      ABORT_SERVER / READ_ONLY

      aplier執行錯誤 / 與 majority失聯 / 網絡波動被移除group

    group_replication_recovery_complete_at

      TRANSACTIONS_CERTIFIED / TRANSACTIONS_APPLIED

    group_replication_member_weight

      single primary 下, 節點角色不對等情況下有用

      相同group_replication_member_weight, 取決于 server_uuid

    group_replication_transaction_size_limit (5.7.19+)

      限制單個事務最大字節數,可控制網絡開銷,內存分配,沖突概率

    group_replication_compression_threshold

      超過X字節后,開啟LZ4壓縮事務傳輸,默認1MB 

 

MGR部署架構建議

  MySQLrouter + MGR  

    router: 兩個接口 (read, insert)

    需要關注一下MySQL的X協議,js相關的相關操作

    建議使用ProxySQL替代

  如果為了性能 : Single-master

  使用方便: Multi-master (單點寫入,多點讀取)

 

 

 

MySQL 高可用之 MGR

標簽:網絡   tran   for   必須   proxy   res   orm   問題:   lz4   

原文地址:https://www.cnblogs.com/yujiaershao/p/11357932.html

(0)
(0)
   
舉報
評論 一句話評論(0
登錄后才能評論!
? 2014 mamicode.com 版權所有 京ICP備13008772號-2
迷上了代碼!
河北十一选五基本走势