一
在配置第一臺服務器mysql
START GROUP_REPLICATION;
後出現如下問題：linux
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就行sql
2、第二臺服務器一直處於RECOVERING狀態
這個問題比較複雜，頗有多是由於出現一些錯誤狀況致使服務器之間鏈接不成功，通常MySQL會嘗試鏈接10次，以後後起的服務器會處於ERROR狀態。shell
一旦一個實例進入ERROR狀態，該實例super_read_only選項被設置爲ON。要離開ERROR 狀態，必須手動配置實例super_read_only=OFF。數據庫
狀況1：
防火牆和selinux沒關，這是小問題，關掉就行。centos
狀況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相同，致使兩臺服務器沒法找到對方。
4、自增量
若是在數據庫內使用到了自增的字段，最好在/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，至於百度就算了，沒什麼用。
5、設置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。