試下以下兩種方法：

方法一：

更新以下包：

a) dbcp commons library

b) connection pool library

c) mysql j/connector library.

方法二：

在MySQL中設定該引數：

SET wait_timeout =1200;

Good Luck!

背景

為獲得最佳相容性和效能，組的所有成員為了 Group Replication，應執行相同版本的 MySQL Server。但是，在某些情況下，可能需要組內有不同版本的伺服器執行共存。例如，在滾動升級期間。當組中存在不同的版本時，某些成員可能與其他成員不相容，因為它們支援其他人沒有或缺乏其他人所具有的功能。因此，組複製需實現相容性策略以防止執行到不相容的版本組合方案。在 MySQL 8.0.17 中，組複製為組中的成員版本實現的相容性策略考慮了成員的 MySQL Server 版本的補丁版本。

以前，只考慮過主要版本。使用維護版本（8.0.17）意味著組複製可以在組重新配置和升級過程中更好地維護混合版本組的複製安全性。

內容大綱

1. 主成員選項

A.主成員選舉演算法具有 8.0.17 或更高版本成員的組具有至少一個 8.0.16 或更低成員版本的組B.使用者觸發主切換具有 8.0.17 或更高版本成員的組具有至少一個 8.0.16 或更低成員版本的組2. 寫版本相容性3. 最低版本相容性4. 捐贈者版本相容性5. 升級6. 結論主成員選項選擇新的主節點時的引數之一是用於複製安全性的成員版本。從 8.0.17 開始，在選擇新主時也考慮補丁級別。因此，基於組配置的下一個主要內容存在細微差別。主成員選舉演算法在主成員的故障轉移期間，基於以下演算法選擇新的主成員：具有 8.0.17 或更高版本成員的組該組中的所有成員都具有 8.0.17 或更高版本。1. 該組的最低成員版本，包括補丁級別2. 根據步驟-1，該組中版本最低成員的成員權重較高3. 伺服器 uuid 的詞法排序在相同成員權重的組內是最低的例子例1：主成員退出後的小組：8.0.19 / 8.0.20 / 8.0.208.0.19 將因其最低版本，開始被選為主伺服器。例2：主成員退出後的小組：8.0.19 權重：90 / 8.0.19 權重：50 / 8.0.20 權重：90 / 8.0.20 權重：95“版本 8.0.19 權重：90”的伺服器將被選為主要伺服器，因為它是組內的最低版本且有較高的權重。例3：主成員退出後的小組：8.0.19 權重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c8.0.19 權重：90 uuid：5a67adc9-6ad1-11e7-9b1f-f48c5048ab0c8.0.19 權重：50 uuid：5a6e5078-6ad1-11e7-9bce-f48c5048ab0c“8.0.19 權重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c”的伺服器將被選為主，因為其具有較高成員權重和最低伺服器 uuid。具有至少一個 8.0.16 或更低成員版本的組該組中至少有 1 名成員，版本低於 8.0.17。1. 考慮主要版本的該組的最低成員版本2. 根據步驟-1，該組中最低成員的成員權重較高3. 伺服器 uuid 的詞法排序在相同成員權重的組內是最低的例子例1：主成員退出後的小組：5.7.22 / 8.0.20 / 8.0.205.7.22 版本的伺服器將從其最低版本的組中被選為主伺服器。使用者觸發主切換如果主成員被修改為使用UDF，group_replication_set_as_primary（server_uuid）或 group_replication_switch_to_single_primary_mode（[server_uuid]），則還會採取一些預防措施以確保所有成員相容並可以執行所需的更改。演算法如下：具有 8.0.17 或更高版本成員的組該組中的所有成員都具有 8.0.17 或更高版本。1. 如果提供了 server_uuid，則該伺服器將成為主成員，如果其版本在組中最低（考慮補丁級別），否則將引發錯誤。2. 如果未提供 server_uuid，則考慮組成員版本直到補丁級別進行選舉。例子例1：多主模式到單主模式切換時的組成員：8.0.19 權重：50 / 8.0.20 權重：90 / 8.0.20 權重：95“版本 8.0.19 權重：50”的伺服器將被選為主伺服器，因為它的補丁是該組的最低版本。具有至少一個 8.0.16 或更低成員版本的組該組中至少有 1 名成員，版本低於8.0.17。1. 如果組中的任何成員的版本為 5.7 或版本低於 8.0.13，則該函式不會對主成員進行任何更改。2. 如果主要版本 8 提供的 server_uuid，那麼該伺服器將成為主成員，否則將丟擲錯誤。3. 如果未提供 server_uuid，則考慮到組成員版本的唯一主版本，將進行選舉。注意：對於 UDF group_replication_set_as_primary，server_uuid 是必需的。如果未提供 server_uuid，UDF 將失敗。例子例1：多主模式到單主模式切換時的組成員：8.0.14 權重：90 / 8.0.20 權重：50 / 8.0.20 權重：90 / 8.0.20 權重：95“版本 8.0.20 權重：95”的伺服器將被選為主伺服器，因為該組的最低主要版本（由於組中存在 8.0.14 而忽略了維護版本）。寫版本相容性從 8.0.17 開始，如果新成員版本高於組的最低成員版本（考慮補丁級別），則新成員將處於只讀模式。如果該組透過執行 UDF group_replication_switch_to_multi_primary_mode 進入多主模式，則該組的最低成員版本將是可寫的，而其他成員將處於只讀狀態。版本為 8.0.16 或更低版本的成員，如果組中的任何成員具有 5.7 版本，則以只讀模式加入組。版本 5.7 的成員始終可寫，因為 5.7 僅考慮主要版本。在 MySQL 5.7 和 8.0 中，直到補丁級別 16，當低版本成員離開組時，使用者必須手動重新配置只讀模式。注意：這僅適用於多主模式。例子例1：多主模式的組成員：8.0.19 / 8.0.20版本 8.0.19 的伺服器將是可寫的，而 8.0.20 將是隻讀的。例2：組成員在單主模式到多主模式切換期間：8.0.19（主）/ 8.0.19（副）/ 8.0.20（副）/ 8.0.21（副）版本 8.0.19 的伺服器將是可寫的，而 8.0.20 和 8.0.21 將是隻讀的多主模式開關。例3：多主模式的組成員：5.7.21 / 8.0.15版本為 5.7.21 的伺服器是可寫的，而 8.0.15 將是隻讀的。例4：組成員在單主模式到多主模式切換期間：8.0.14（副）/ 8.0.15（副）/ 8.0.20（副）/ 8.0.21（主）版本 8.0.14 和 8.0.15 的伺服器是可寫的（舊版本），而 8.0.20 和 8.0.21 將是隻讀的。Server 8.0.21 將啟用只讀模式。最低版本相容性從 8.0.17 開始，如果新成員版本低於該組的最低成員版本（考慮補丁級別），則新成員將不加入該組。版本 5.7 的成員無法加入僅包含 8.0+ 成員的組。8.0.16 或更低版本的成員可以加入任何組，因為它只考慮主要版本。例子例1：小組成員：8.0.19 / 8.0.20 / 8.0.20版本為 8.0.17 或 8.0.18 的伺服器將無法加入該組。例2：小組成員：8.0.15 / 8.0.16版本為 5.7.27 的伺服器將無法加入該組。捐贈者版本相容性從 8.0.17 開始，在形成可能的捐贈者組列表的同時，具有與新成員相同或更低版本的 ONLINE 成員被視為有效捐贈者。但是，如果設定了 allow_local_lower_version_join，則該組的所有 ONLINE 成員都可以充當有效的捐贈者，因為沒有相同或更低版本的成員。5.7 級別或 MySQL 8.0 至 8.0.16 的組複製版本將所有 ONLINE 成員視為恢復的主動捐助者。例子例1：組成員：5.7.22 / 8.0.20 / 8.0.21新成員 8.0.20 可以使用 5.7.22 或 8.0.20 作為捐贈者。例2：組成員：5.7.22 / 8.0.20 / 8.0.21新成員 5.7.22 可以使用 5.7.22, 8.0.20 或 8.0.20 作為捐贈者。升級對於單主升級，使用者可以先更新每個副成員，然後再更新主成員。以後的使用者可以使用 UDF group_replication_set_as_primary 使所需的成員成為主成員。或者使用者可以將更高的成員權重分配給所需的成員和升級組，首先升級所需的主成員。對於多主升級，可以按任何順序升級成員。在完成組升級的過程中，由於版本較高，升級後的成員將處於只讀模式。一旦該組的所有成員升級到相同的補丁級別，所有成員都將變為可寫。關於不期望升級的一些注意事項：如果其版本低於該組的最低成員版本，則成員將不會加入該組（考慮補丁級別）∘ 如果升級後，版本不會是相同的補丁級別，則應首先啟動新的最低成員版本。如果組中的所有成員的版本都大於 8.0.16，則只有當成員是組中的最低版本（包括修補程式級別）時，才允許該成員成為主要成員。∘ 如果主要升級後必須保持相同的升級，則主要升級（包括補丁級別）可能不會透過此 WL。應將組的輔助成員升級到高於或等於主要成員版本的版本。例子例1（單主升級）M1：8.0.20（舊主）/ M2：8.0.20（新主）/ M3：8.0.201. DBA 希望將所有組成員升級到 8.0.212. 在 M2 上設定更高的成員權重並升級 M2 3. 立即升級 M3 和 M14. M1 和 M3 升級後， M2 將成為主要例2（單主升級）M1：8.0.20（主）/ M2：8.0.20 / M3：8.0.201. DBA 希望將所有組成員升級到 8.0.212. 將 M2 和 M3 升級到 8.0.21 或更高版本3. 在 M2 和 M3 升級後，M1 可以升級到 8.0.214. 使用 UDF group_replication_set_as_primary M1 可以成為主例3：（多主升級）M1：8.0.20 / M2：8.0.201. DBA 希望將所有組成員升級到 8.0.212. 升級 M13. M1 升級後，M1 將是隻讀的，直到 M2 升級到 8.0.214. 一旦 M2 升級到 8.0.21，M1 將變為可寫結論MySQL 8.0.17 是公開可用的，隨之而來的是對組複製的改進。現在，組複製可以增加安全性，並確保成員生成的事務與組中的每個成員相容。