(轉)MySQL Group Replication介紹

這是一個振奮人心的消息!mysql



2016-12-12,一個重要的日子,mysql5.7.17 GA版發佈,正式發佈了Group Replication(組複製) Plugin,加強了MySQL原有的高可用方案(原有的高可用方案是指mysql主從架構),提供了重要的特性——多寫,保證組內高可用,數據強一致性。算法

1. 背景
sql

在介紹組複製之間,咱們先簡單介紹傳統的複製和半同步複製:數據庫

1.1 傳統複製

傳統mysql複製是徹底異步化的複製。下圖描述了傳統複製的原理:網絡

async_replication_diagram

master事務的提交不須要等待slave relay的響應。relay log老是異步地發送到slave上去執行。在高併發的狀況下,傳統的主從複製,從節點可能會與主產生較大的延遲,此時若是主節點出現異常,那麼就會出現數據不一致的狀況,數據可能會丟!架構

1.2 半同步複製

半同步複製是傳統複製的變種,在master事務的commit以前,必須確保slave收到relay log而且響應給master之後,才能進行事務的commit。併發

semisync_replication_diagram

由於slave接受relay log以後有可能apply失敗。這個時候master其實不知道slave的失敗,照常提交了這個事務。由此,半同步複製同樣也會出現數據不一致的狀況。app

1.3 組複製

gr_replication_diagram

引入組複製,是爲了解決傳統複製和半同步複製可能產生數據不一致的問題。組複製依靠分佈式一致性協議(Paxos協議的變體),實現了分佈式下數據的強一致性,提供了真正的數據高可用方案(是否真正高可用還有待商榷)。其提供的多寫方案,給咱們實現多活方案帶來了但願。異步

一個replication group由若干個節點(數據庫實例)組成,組內各個節點維護各自的數據副本(Share Nothing),經過一致性協議實現原子消息和全局有序消息,來實現組內實例數據的強一致。async

2. 組複製介紹

2.1 數據一致性保證

對於只讀(RO)事務,組間實例無需進行通信,就能夠處理事務;對於讀寫(RW)事務,組內全部節點必須通過通信,共同決定事務提交與否。

引用mysql官方博客對於讀寫事務提交過程的描述,解釋瞭如何保證了組內節點間數據的一致性的(難以翻譯- -。):

To be precise, when a transaction is ready to commit at the originating server, the server will atomically broadcasts the write values (rows changed) and the correspondent write set (unique identifiers of the rows that were updated). Then a global total order will be established for that transaction. Ultimately, this means that all servers receive the same set of transactions in the same order. As a consequence, all servers apply the same set of changes in the same order, therefore they remain consistent within the group.

2.2 事務衝突處理

在高併發的狀況下,節點間讀寫事務的提交可能會產生衝突,好比,兩個不一樣的事務在兩個節點上操做了同一行數據,這個時候就會產生衝突。首先,Group Replication是可以識別到這個衝突,而後對此的處理是,依賴事務提交的時間前後順序,先發起提交的節點可以正確提交,然後面的提交,會失敗。

2.3 故障檢測

Group Replication內部有故障檢測機制,能夠識別組內成員是否掛掉(組內節點心跳檢測)。當一個節點失效,將由其餘節點決定是否將這個失效的節點從group裏面剔除。

2.4 組成員管理

replication group須要維護組內節點的狀態(在線?存活?掛掉?),對於失效的節點,由其餘節點決定是否剔除。對於新加入的節點,須要維護它的視圖與其餘節點的視圖保持一致。

2.5 容錯能力

組複製基於分佈式一致性算法實現,一個組容許部分節點掛掉,只要保證絕大多數節點仍然存活而且之間的通信是沒有問題的,那麼這個組對外仍然可以提供服務。

假設一個複製組由2n + 1個節點,那麼容許n個節點失效,這個複製組仍然可以對外提供服務。好比有3個節點組成的一個複製組,可容許1個節點失效,這個複製組仍然可以提供服務。

Group Size Majority Instant Failures Tolerated
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3

由此能夠看出,複製組由奇數個節點組成爲佳。

2.6 兩種模式

mysql5.7.17 Group Replication提供了single-primary和multi-primary兩種模式。single-primary mode 組內只有一個節點負責寫入,讀能夠從任意一個節點讀取,組內數據保持強一致;而multi-primary mode 爲多寫,即寫會下發到組內全部節點,組內全部節點同時可讀,也是可以保證組內數據強一致性。一個group的全部節點必須配置使用同一種模式,不可混用。

2.6.1 Single-Primary Mode

這個模式下,group內只有一臺節點可寫可讀,其餘節點只能夠讀。對於group的部署,須要先跑起primary節點(即那個可寫可讀的節點),而後再跑起其餘的節點,並把這些節點一一加進group。其餘的節點就會自動同步primary節點上面的變化,而後將本身設置爲只讀模式。

當primary節點意外宕機或者下線,在知足大多數機器存活的狀況下,group內部發起選舉,選出下一個可用的讀節點,提高爲primary節點。

primary選舉根據group內節點的UUID按字典序來選擇,即存活的節點按UUID字典序排列,而後選擇排在最前的節點做爲新的primary節點。

single-primary-election

【重要】 在切換primary期間,mysql group不會重定向應用所持有的鏈接。這須要應用層或者中間件層去保證。

如何查看group內哪一個節點是做爲primary節點,官方提供了一個方法:

mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';
+--------------------------------------+
| VARIABLE_VALUE                       |
+--------------------------------------+
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
+--------------------------------------+1 row in set (0,00 sec)12345671234567

獲得的是實例節點的UUID

2.6.2 Multi-Primary Mode

多主模式,即多寫,沒有選擇新primary的概念,group內的全部機器都是primary節點,同時能夠進行讀寫操做,而且數據是一致的。讓我等屌絲看到了多活方案的但願啊…

multi-primary

2.7 Requirements&Limitations

2.7.1 Requirements

部署group replication有如下需求:

1) 架構上

  • 存儲引擎必須爲innodb

  • 每一個表必須提供主鍵

  • 只支持ipv4,網絡帶寬要好

  • 一個group最多隻能有9個節點

2) 配置上

針對my.cnf,須要指定以下配置:

# Binary Log must be active.
log-bin[=log_file_name]

# Binary Log Format must be set to ROW.
binlog-format=row# Global Transaction Identifiers must be turned on.
gtid-mode=ON# Replication applier needs to have replication metadata repositories stored in system tables.
master-info-repository=TABLErelay-log-info-repository=TABLE# Transaction write set extraction must be enabled.transaction-write-set-extraction=XXHASH64

# Servers need to log binary logs that are applied through the replication applier.
log-slave-updates

# Replication event checksums are not supported.
binlog-checksum=NONE1234567891011121314151617181920212212345678910111213141516171819202122

2.7.2 Limitations

如下列舉使用group replication的限制:

  • 不支持Replication event checksums,須要在my.cnf裏面配置,在上節已經說起

  • 不支持Savepoints

  • multi-primary mode部署方式不支持SERIALIZABLE事務隔離級別

  • multi-primary mode部署方式不能徹底支持級聯外鍵約束

  • multi-primary mode部署方式不支持在不一樣節點上對同一個數據庫對象併發執行DDL(在不一樣節點上對同一行併發進行RW事務,後發起的事務會失敗)




轉載由:http://blog.csdn.net/d6619309/article/details/53691352

相關文章
相關標籤/搜索