一
在配置第一臺伺服器
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。