一
在配置第一台服務器
START GROUP_REPLICATION;
后出現以下問題：
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
發現，本機無法ping通，修改/etc/sysconfig/network-scripts/ifcfg-eth0（eth0為你上網用的網卡），設置好本機ip、子網掩碼、網關，之后重啟network就行
二、第二台服務器一直處於RECOVERING狀態
這個問題比較復雜，很有可能是因為出現一些錯誤情況導致服務器之間連接不成功，一般MySQL會嘗試連接10次，之后后起的服務器會處於ERROR狀態。
一旦一個實例進入ERROR狀態，該實例super_read_only選項被設置為ON。要離開ERROR 狀態，必須手動配置實例super_read_only=OFF。
情況1：
防火牆和selinux沒關，這是小問題，關掉就行。
情況2：
兩台服務器主機名相同，mysql無法通過DNS找到對應服務器。
解決方法：
在my.cnf文件中設置
report-host=192.168.50.22 #后面跟的ip是本機的ip
或者取消掉mysql通過DNS查找服務器的策略，當然，也可以修改hosts文件，方法網上可以找到的。當然，最好是設置report-host。
還有server_id每台服務器一定要不同。
情況3：
查看mysql日志，發現兩台服務器直接一直在嘗試連接，一直連接不上。嘗試10次之后，變成ERROR狀態。
VM Ware的鍋，概率不高。
然后我運氣不好，碰到了，折磨了我一個星期，網上根本找不到解決方法，最后換成VirtualBox就好了，實際生產環境應該不會有這么坑爹的問題，大概是VM Ware虛擬機網絡通信機制的問題，猜測可能還有防火牆，同事用VM Ware做成功了，大概是版本問題或者其他的，具體原因查不出來。
我后來在用一個純凈的基本沒有自配的服務的centos鏡像在VM Ware下裝機，連網卡都啟動不來后才猜出來的，然后毅然下了個VirtualBox，重新配，就沒問題了。
初步覺得可能是管理員權限的原因，VM Ware和Win 10都該背鍋。
情況4：
加載的sql查詢文件語法不兼容組復制，例如建表沒有主鍵，創建的帶返回值的函數沒有聲明DETERMINISTIC之類的，查MySQL日志大概能查出來。
三
如果用虛擬機模擬組復制，那么，最好不要直接克隆一台已經配置好的虛擬機，至少，不能克隆已經初始化了mysql的虛擬機，不然會造成兩台服務器的MEMBER_ID相同，導致兩台服務器無法找到對方。
四、自增量
如果在數據庫內使用到了自增的字段，最好在/etc/my.cnf中添加auto_increment_increment、auto_increment_offset兩個參數，防止發生事務沖突（MGR其實本身就有防止自增量事務沖突的能力，運用了GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT這個參數，但如果不去手動設置，自增量的間隔會非常奇怪）。
auto_increment_increment為自增量的間隔，auto_increment_offset為自增量的初始位置。
從官網查到的文檔上，建議最好為：
auto_increment_increment=n（組內成員數）
auto_increment_offset=server_id(這里的server_id最好為1,2,3這樣的自增量,且每台都不同)
這樣肯定能解決事務沖突的問題，但是，這樣，為了讓自增量每次都是+1，必須得DB1插表，然后DB2，接着DB3...如果一直是DB1(或者任意一台組內的服務器)插表，會導致自增量每次是+n。如果有強迫症，會很難受...
網上也有這么做的：
auto_increment_increment=1
auto_increment_offset=2
這樣，我們做MGR的時候也試過，還試過auto_increment_offset等於其他大於1的值，基本上自增量每次都是+1，也沒有出現事務沖突，湊合着是可以用的，但邏輯上有點奇怪，不知道會不會有隱藏的問題。
至於
auto_increment_increment=1
auto_increment_offset=1
這樣的做法，肯定是哪位老哥用官網上的做法寫的DB1示例后，被人各種無腦Ctrl+C、Ctrl+V之后的做法。
這樣會導致每次自增的間隔為7，不論在哪台服務器上。
至於為什么會這樣，貌似是GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT這個參數默認是7，而MGR默認的規避自增量導致的事務沖突的方式中auto_increment_increment=GROUP_REPLICATION_AUTO_INCREMENT_INCREMENT。
這樣做，還不如用官方提出的設計。
現在，我們在公司里，用的是：
# auto_increment_increment=1
auto_increment_offset=9
這里auto_increment_increment參數被我們注釋掉了，在測試的時候基本也沒出問題，不知道到時候到生產環境會怎樣。
自增字段的大小依賴於group replication組中成員的多少。
auto_increment_offset值，最好是大於等於組內成員數，如果段的大小等於組內成員的數量，則所有的自增值都會被使用。
auto_increment_offset值小於組內成員數，我們有試過，不過不知道是我們測試的虛擬機數量太少，還是情況考慮的不周，暫時沒什么問題，不過以防萬一，還是不要這么操作。
關於組復制設置自增量間隔，推薦可以看：
WL#8445: Group Replication: Auto-increment configuration/handling
笨小孩的dba之路-MySQL group replication介紹
還有自行Google，至於百度就算了，沒什么用。
五、設置read_only
因為以默認的方式（不設置loose-group_replication_single_primary_mode=FALSE）啟動組復制時后起服務器沒用寫的權限，所以要在MySQL shell上輸入
set global read_only=0;
不過，最好在服務器ONLINE之后再執行，不然，同步會出現問題。
查看日志/var/log/mysqld.log，大量出現：
[ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication is recovering. Try again when the server is ONLINE.'
[ERROR] Run function 'before_commit' in plugin 'group_replication' failed
當然這樣依然有概率能ONLINE，不過比較浪費時間，而且也有很大概率失敗。
所有生產環境最好不要在服務器RECOVERING時設置read_only=0。