配置Mysql Group Replication遇到的問題筆記

一

在配置第一臺伺服器

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。