【轉】Galera：多主同步MySQL集群原理解析

Galera：多主同步MySQL集群原理解析

http://www.liuhaihua.cn/archives/44038.html

Galera Cluster是基於MySQL/innodb二次開發而成的一個支持“多主同步”的數據庫主從集群。強調主從集群意味着Galera Cluster的每個節點充當一個數據冗余，而沒有在節點間做分庫分表的水平擴展。Galaer官網中為Galera Cluster洋洋灑灑羅列了10大優勢，其實總結下來無非上文用引號注明的兩點：

多主

Galera Cluster沒有MySQL主從集群只有一個主能提供寫服務的限制，集群中每個節點都可讀可寫，無需讀寫分離。在一個Galera Cluster前直接部署HAProxy或LVS做讀寫負責均衡是比較常用的做法。

 

同步

Galera replication具有實時性，能夠保障不同節點的數據視圖在較小的時間范圍內是一致的。MySQL原生replication方案slave中的SQL線程和IO線程是分離的，即便使用半同步甚至同步復制，也可能因為SQL線程的速度跟不上IO線程而導致slave數據落后很多，當然5.7引入並行復制后會好很多，而Galera中除了具有並行復制的功能外，還具有flow control的功能來控制節點間數據同步的速度。

 

Galera Cluster相較於MySQL 來說的核心貢獻是基於Galera replication plugin實現實現了多主和同步兩大特性，本文將詳細剖析Galera在解決多主和同步兩大問題上的想法和思路。

架構簡述

Galera Cluster節點間通過wsapi進行數據通信和同步，如圖1和圖2所示，wsapi通過hook的方式侵入Innodb中事務的commit流程，獲取事務內所有數據行的更改，構造一個write set並將其同步到Cluster其他節點，wsapi即write set api簡稱。

圖1. Galera Overview

圖2. Galera library

Galera provider目前是wsapi的唯一實現。Galera provider內部實現又划分為多個層次，其中最為核心的是認證層（certification）和復制層（replication）。認證層負責檢測本機事務，以及從其他節點同步來的事務是否可以提交，Galera的基於認證的事務樂觀並發控制會在多主實現一節中介紹。復制層的工作包含兩方面：

• 組通信，與其他節點同步writeset，並為事務分配全局唯一的GTID
• 並行復制，結合Galera事務樂觀並發控制原理的並行復制

復制層通過組通信（Group communication）完成writeset的同步和GTID的分配，GTID的分配是Galera基於認證的事務並發控制和並行復制的前提和基礎。

GTID與組通信

GTID是global transaction id的縮寫，在MySQL社區中，GTID的概念並不新鮮，MySQL中的GTID是由Master生成，用於標志事務唯一性並通過ID定位binlog位置的一種手段，從而有效解決了級聯復制等場景中的各種問題。

對於Galera Cluster來說，replication通過Galera replication中間件來保障，不基於binlog，因此Galera的GTID雖然也標志事務的唯一性，但是它的設計初衷完全不同，在介紹它的設計目的之前，先來看下Galera的GTID格式：

45eec521-2f34-11e0-0800-2a36050b826b:94530586304

如上圖所示，GTID包含兩部分：

• UUID，標志事務的唯一性ID
• 一個順序ID，標志這個事務在Galera Cluster所有節點事務中的順序

而且實現方式也要復雜的多，因為Galera Cluster中所有節點都可做master，因此不能由一個節點隨意去分配。理論上需要所有節點對一個事務的ID達成一致才能確定，但是這里引入Paxos一類的分布式一致性算法顯然會嚴重拖慢commit速度，因為Paxos采用的是全同步的通信方式。

 

PS：如果您想和業內技術大牛交流的話，請加qq群(527933790)或者關注微信公眾 號(AskHarries)，謝謝！

===============

 

一、MariaDB Galera Cluster概要：

1.簡述：

     MariaDB Galera Cluster 是一套在mysql innodb存儲引擎上面實現multi-master及數據實時同步的系統架構，業務層面無需做讀寫分離工作，數據庫讀寫壓力都能按照既定的規則分發到 各個節點上去。在數據方面完全兼容 MariaDB 和 MySQL。

2.特性：

     (1).同步復制 Synchronous replication

     (2).Active-active multi-master 拓撲邏輯

     (3).可對集群中任一節點進行數據讀寫

     (4).自動成員控制，故障節點自動從集群中移除

     (5).自動節點加入

     (6).真正並行的復制，基於行級

     (7).直接客戶端連接，原生的 MySQL 接口

     (8).每個節點都包含完整的數據副本

     (9).多台數據庫中數據同步由 wsrep 接口實現

3.局限性

     (1).目前的復制僅僅支持InnoDB存儲引擎,任何寫入其他引擎的表，包括mysql.*表將不會復制,但是DDL語句會被復制的,因此創建用戶將會被復制,但是insert into mysql.user…將不會被復制的.

     (2).DELETE操作不支持沒有主鍵的表,沒有主鍵的表在不同的節點順序將不同,如果執行SELECT…LIMIT… 將出現不同的結果集.

     (3).在多主環境下LOCK/UNLOCK TABLES不支持,以及鎖函數GET_LOCK(), RELEASE_LOCK()…

     (4).查詢日志不能保存在表中。如果開啟查詢日志，只能保存到文件中。

     (5).允許最大的事務大小由wsrep_max_ws_rows和wsrep_max_ws_size定義。任何大型操作將被拒絕。如大型的LOAD DATA操作。

     (6).由於集群是樂觀的並發控制，事務commit可能在該階段中止。如果有兩個事務向在集群中不同的節點向同一行寫入並提交，失敗的節點將中止。對 於集群級別的中止，集群返回死鎖錯誤代碼(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

     (7).XA事務不支持，由於在提交上可能回滾。

     (8).整個集群的寫入吞吐量是由最弱的節點限制，如果有一個節點變得緩慢，那么整個集群將是緩慢的。為了穩定的高性能要求，所有的節點應使用統一的硬件。

     (9).集群節點建議最少3個。

     (10).如果DDL語句有問題將破壞集群。