–MySQL 8 group replication 有什麼妖 問與答
- 2020 年 2 月 21 日
- 筆記
MYSQL 8.018-9 已經上線了，下載了percona 的8.018-9 ，打開了官方的 show card。
這次採用8.017 才有的clone功能來進行從庫的建立，不在使用備份的方式。（具體怎麼進行clone的方法， 請參見之前的文字）
WHERE PLUGIN_NAME = 'clone';
如何搭建MGR 集群，請參見之前的文字，用MYSQL 5.7 的方式可以搭建8.018的MGR集群
下面就開始捉妖行動
問題1 系統搭建後，從節點一直處於 recovering 狀態
經過
select * from performance_schema.replication_group_member_statsG
查看，發現是 error connecting to master 'repl@mgr1:3306' – retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.
原因：mysql 8 全部採用了 caching_sha2_password 的方式，這導致很多之前可以使用的工具以及工作的方式都需要改變。
快速低成本解決方法：
在my.cnf 中添加下面一行，將MYSQL 與MYSQL 5.7 的密碼認證方式一致，則上面的問題解決
default_authentication_plugin=mysql_native_password
重新啟動資料庫服務，上面的問題可以解決
問題2 MYSQL MGR 是否支援一致性讀，支援MYSQL 8.104版本已經開始支援，這從根本上提供了一種主從數據一致的方法
配置參數 group_replication_consistency
其中有五個值
eventual
before_on_primary_failover
before
after
before_and_after
需要強一致的，需要將group_replication_consistency 設置為 after
一個RW事務將一直等待，直到它的更改被應用到所有其他成員。此值對RO事務沒有影響。此模式確保在本地成員上提交事務時，任何後續事務都將讀取任何組成員上的寫入值或最近的值。對主要用於RO操作的組使用此模式，以確保應用的RW事務在提交後應用到所有地方。您的應用程式可以使用它來確保後續的讀操作能夠獲取最新的數據，其中包括最新的寫操作。這減少了
但前提是你的MYSQL 集群中是寫少，讀多。否則會影響整體集群的性能，尤其不能進行大事務分割的，應該盡量使用小的多個事務，替換大事務。
問題3 如果集群中的某台機器要離開，那離開集群的機器對外需要使用什麼方式離開
group_replication_exit_state_action插件變數是在MySQL 8.0.12中引入的，允許用戶在伺服器實例無意中離開組時配置組複製的行為。此功能主要是滿足在某個節點離開集群後，離開系統的節點的對外展示何種狀態。
其中可以選擇的值：
ABORT_SERVER:伺服器關閉自己; READ_ONLY:伺服器將自己切換到超級只讀模式
可以查看當前的伺服器的離開的狀態的後的反應是什麼。
這樣設置的好處是，可以自由的設定到當節點從集群離開了，採取什麼樣的措施。
問題4 MYSQL MGR 是無法忍受肆無忌憚的大事務，大事務會影響整體集群的性能甚至會導致集群之間節點無響應後解散的危險，怎麼緩解這個問題（注意是緩解問題，不是解決問題）
在MYSQL處理大事務時，很有可能集群裡面的機器會失去響應，組複製組成員在產生懷疑後等待的時間(以秒為單位)，然後將懷疑失敗的成員從組中驅逐出去。在懷疑產生之前的最初5秒的檢測周期不計入此時間。更改某個組成員上的group_replication_member_expel_timeout的值將立即對該組成員的現有和將來的無響應生效。不是強制要求組中的所有成員都具有相同的設置，但是建議這樣做，以避免意外的驅逐。 默認情況下，group_replication_member_expel_timeout設置為0，這意味著沒有等待期，在5秒的檢測期結束後，可疑成員可能立即被驅逐。為了避免在較慢的網路上進行不必要的排除，或者在預期的瞬時網路故障或機器變慢的情況下，您可以指定一個大於零的超時值，最高可達3600秒(1小時)。如果可疑成員在懷疑超時之前再次激活，它將重新加入組。
當然正確的方法是，控制應用產生的事務大小，這才是正路。
問題5 當成員和集群分離後，是否進行繼續的嘗試
默認當節點與集群分離後，將不再嘗試加入集群，從8.016後添加了group-replication-autorejoin-tries，可以對已經離開的節點進行重試次數的設置，最大可以設置2016次。這樣的設置可以解決由於網路或其他問題造成節點脫離後的重新添加的自動化操作。使得 MGR 向自動化故障修復又邁出了一步。
從上邊部分的方式看出MYSQL MGR 一致是往集群節點失敗後的高容忍和自動修復上是進步的，尤其8.019，clone的功能會應用到自動節點數據修復中，但實際上MGR 從目前看還是一直在進步，並未停止的狀態，並且使用的經驗和這些新功能的可靠性還有待驗證，所以導致目前還有很多企業在使用8.0的哪個版本，採用哪種技術，終究資料庫整體升級並沒有那麼簡單和輕鬆。
