組複製提供了了容錯能力，只要組中的大多數的成員存活，那麼系統就是可用的，組複製有2中形式，多master，所有server都能接受更新和單master自動選主，只有master接受更新,有更新衝突的時候，會採用先提交獲勝的策略，回滾掉後提交的，組複製中對於讀寫的事務的提交並不是有原始的server單獨決定的，需要所有的server決定是否提交，在原始server上提交的時候，該server會發送一個廣播，包含行改變及行的唯一標識符，然後這個事務有個全局總順序，確保每個server上接收的是相同順序的事務，在多master模式中，應用端需要處理一些該模式下的異常
對於一個提交的事務，組中的大部分要確保事務全局序列的順序性，每個節點單獨的決定是提交還是丟棄，然後所有的server確定最終的決定，如果有網絡分區發生，導致部分的server沒辦法訪問，發生分區，那麼系統將會停止處理直到問題解決。所以組複製中有內建的，自動的腦力檢測機制。
組複製跟普通的複製一樣，也是shared-nothing的結構
在不同的server上併發的執行事務可能會遇到衝突，這種衝突會在certification的過程中被檢測，如果併發的事務，在不同的server上執行，更新了相同的行，就會產生衝突，這種衝突的處理就是先執行的正常，後執行的被回滾。
組複製中的失敗檢測
內部有機制來發現及報告哪個server是靜默的並假定是死亡的，失敗檢測器提供可能失敗sevrver的信息，如果組都同意這個server可能是死亡的，那麼就認定他是死亡的server，並排除。當server沒有迴應的時候，就開始檢測過程，但一個server與組中其他成員孤立的時候，這個server會懷疑別的server都失敗了，有超時設置，但他不能與組中大多數達成一致，他的懷疑就是無效的，所以他是不能執行任何的本地事務的。
組成員
server不但要同意事務提交，還要維護當前視圖，如果server將一個新的server認爲是組的一部分，那麼組會自動重新配置，同樣的，，一個server離開後，組信息也會重新配置。如果因爲異常原因，server在離開組後，如果組沒有達成一致，那麼爲了防止腦裂的發生，系統會被block，需要管理員去手工處理修復。
組複製中如果一個server宕掉了，那麼客戶端的連接需要使用負載均衡或是路由去重新連接別的server。組複製是不會去解決這種問題的。
組複製有2中模式，單主和多主模式，默認的情況下是單主的。單主的情況下，第一個啓動的實例就是主，其他的節點啓動後都是隻讀的模式。
在單主的模式下，當主宕掉後，剩下的成員會通過uuid來進行選擇新主，選擇列表中的第一個成員，
客戶端的配置需要注意，需要在新主應用完他的rely log後才連接新主進行操作。
查看集羣的server的狀態
SELECT * FROM performance_schema.replication_group_members;
在集羣的額大部分不可用的情況下，集羣是停止服務的
部署單主模式，需要注意組複製的自增主鍵的offset使用了serverid,所以serverid不能設置的過大。
1部署3個mysql實例
2在配置文件中配置參數
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name=“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= “127.0.0.1:24901”
loose-group_replication_group_seeds= “127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”
loose-group_replication_bootstrap_group= off
3在mysql中創建複製用戶
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0,00 sec)
mysql> CREATE USER rpl_user@’%’ IDENTIFIED BY ‘rpl_pass’;
Query OK, 0 rows affected (0,00 sec)
mysql> GRANT REPLICATION SLAVE ON . TO rpl_user@’%’;
Query OK, 0 rows affected, 1 warning (0,00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0,00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0,00 sec)
爲用戶配置複製恢復的通道
CHANGE MASTER TO MASTER_USER=‘rpl_user’, MASTER_PASSWORD=‘rpl_pass’ \
FOR CHANNEL ‘group_replication_recovery’;
每個實例的機器需要正確的配置hostname，否則會導致通訊出錯。在每個節點添加到集羣的過程中，都使用了分佈式的恢復來進行與其他成員的同步。
安裝插件
INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;
使用命令查看插件是否安裝成功
mysql> SHOW PLUGINS;
在節點1上啓動組複製
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
查看組成員
SELECT * FROM performance_schema.replication_group_members;
創建個測試表，插入幾條數據，然後看下事件
SHOW BINLOG EVENTS;
接下來添加實例到組中，創建實例2的配置文件
Replication configuration parameters
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
Group Replication configuration
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name=“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= “127.0.0.1:24902”
loose-group_replication_group_seeds= “127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”
loose-group_replication_bootstrap_group= off
在節點2上創建用戶
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@’%’;
GRANT REPLICATION SLAVE ON . TO rpl_user@’%’ IDENTIFIED BY ‘rpl_pass’;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER=‘rpl_user’, MASTER_PASSWORD=‘rpl_pass’ \
FOR CHANNEL ‘group_replication_recovery’;
安裝插件
INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;
啓動2上的組複製
mysql> START GROUP_REPLICATION;
檢查成員
SELECT * FROM performance_schema.replication_group_members;
這個時候節點2是會自動的追趕上節點1的。
按照添加節點2的過程添加節點3
監控組複製
performance_schema.replication_group_member_stats
performance_schema.replication_group_members
These Perfomance Schema replication tables also show information about Group Replication:
performance_schema.replication_connection_status
performance_schema.replication_applier_status
The replication channels created by the Group Replication plugin are named:
在單主模式下，查找新主是誰
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= ‘group_replication_primary_member’;
如果節點中大部分的實例意外宕掉，則集羣無法確定當前的集羣由哪些節點組成，會發生腦裂的情況，這種情況下需要管理員介入處理。
手工調整集羣中的成員
查看節點1的地址
SELECT @@group_replication_local_address;
查看節點2的地址
SELECT @@group_replication_local_address;
使用下面的命令強制調整集羣中的成員
SET GLOBAL group_replication_force_members=“127.0.0.1:10000,127.0.0.1:10001”;
需要確保排除去的節點是shutdown的狀態，否則他們組成一個集羣，就出現了腦裂的風險。
組複製的限制：
1不能使用複製event checksums
2認證過程不會考慮gap鎖，推薦使用read committed隔離級別。
3認證過程不會考慮表鎖及命名鎖
4不支持savepoints
5可序列化隔離級別不會被支持
6在使用多master的結構中，在不同server上對相同的對象上同時進行ddl和dml操作是不被支持的。
7多master的情況下不支持外鍵
8大事務，對於那些很大的事務，如果在5秒的窗口內不能在組成員內拷貝，那麼會導致組通訊失敗，要避免這個需要使事務儘可能的小。
多主模式不支持級聯的外鍵
最多有9個server
需要使用group_replication_ip_whitelist參數指定能訪問的ip
需要網絡條件好，如果網絡有延時，那麼集羣成員會頻繁的被剔除
主節點和從節點的數據可以不一樣，這個就跟普通的複製是一樣的，只要不產生不存在的錯誤，都能正常複製
整體感覺跟galera cluster很像