這是一個振奮人心的消息！
2016-12-12，一個重要的日子，mysql5.7.17 GA版發佈，正式發佈了Group Replication(組複製) Plugin，增強了MySQL原有的高可用方案(原有的高可用方案是指mysql主從架構)，提供了重要的特性——多寫，保證組內高可用，數據強一致性。
1. 背景
在介紹組複製之間，我們先簡單介紹傳統的複製和半同步複製:
1.1 傳統複製
傳統mysql複製是完全異步化的複製。下圖描述了傳統複製的原理:
master事務的提交不需要等待slave relay的響應。relay log總是異步地發送到slave上去執行。在高併發的情況下，傳統的主從複製，從節點可能會與主產生較大的延遲，此時如果主節點出現異常，那麼就會出現數據不一致的情況，數據可能會丟！
1.2 半同步複製
半同步複製是傳統複製的變種，在master事務的commit之前，必須確保slave收到relay log並且響應給master以後，才能進行事務的commit。
因爲slave接受relay log之後有可能apply失敗。這個時候master其實不知道slave的失敗，照常提交了這個事務。由此，半同步複製一樣也會出現數據不一致的情況。
1.3 組複製
引入組複製，是爲了解決傳統複製和半同步複製可能產生數據不一致的問題。組複製依靠分佈式一致性協議(Paxos協議的變體)，實現了分佈式下數據的強一致性，提供了真正的數據高可用方案(是否真正高可用還有待商榷)。其提供的多寫方案，給我們實現多活方案帶來了希望。
一個replication group由若干個節點(數據庫實例)組成，組內各個節點維護各自的數據副本(Share Nothing)，通過一致性協議實現原子消息和全局有序消息，來實現組內實例數據的強一致。
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節點。
【重要】 在切換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節點，同時可以進行讀寫操作，並且數據是一致的。讓我等屌絲看到了多活方案的希望啊…
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