MGR新節點RECOVERING狀態的分析與解決：caching_sha2_password驗證插件的影響

来源:https://www.cnblogs.com/greatsql/archive/2023/09/13/17698667.html
-Advertisement-
Play Games

起因 在GreatSQL社區上有一位用戶提出了“手工構建MGR碰到的次節點一直處於recovering狀態”，經過排查後，發現了是因為新密碼驗證插件caching_sha2_password導致的從節點一直無法連接主節點，帖子地址：(https://greatsql.cn/thread-420-2- ...


起因

在GreatSQL社區上有一位用戶提出了“手工構建MGR碰到的次節點一直處於recovering狀態”，經過排查後，發現了是因為新密碼驗證插件caching_sha2_password導致的從節點一直無法連接主節點，帖子地址：(https://greatsql.cn/thread-420-2-1.html)）

復現

環境介紹

本文驗證環境，以及本文所採用資料庫為GreatSQL 8.0.32-24

$ cat /etc/system-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)
$ uname -a
Linux gip 3.10.0-1160.el7.x86_64 #1 SMP Tue Aug 18 14:50:17 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux

部署準備：

採用的是單機多實例的部署方式，如何部署單機多實例可以前往(https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/6-oper-guide/6-6-multi-instances.md)

IP 埠 角色
172.17.139.77 3306 mgr01
172.17.139.77 3307 mgr02

MGR有關配置參數：

#mgr settings
loose-plugin_load_add = 'mysql_clone.so'
loose-plugin_load_add = 'group_replication.so'
loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1"
loose-group_replication_group_seeds = '172.17.139.77:33061,172.17.139.77:33071'
loose-group_replication_start_on_boot = ON
loose-group_replication_bootstrap_group = OFF
loose-group_replication_exit_state_action = READ_ONLY
loose-group_replication_flow_control_mode = "DISABLED"
loose-group_replication_single_primary_mode = ON
loose-group_replication_communication_max_message_size = 10M
loose-group_replication_transaction_size_limit = 3G
loose-group_replication_arbitrator = 0
loose-group_replication_single_primary_fast_mode = 0
loose-group_replication_request_time_threshold = 20000
report_host = "172.17.139.77"

MGR01節點配置如下：

[mysqld@mgr01]
datadir=/data/GreatSQL/mgr01
socket=/data/GreatSQL/mgr01/mysql.sock
port=3306
server_id=103306
log-error=/data/GreatSQL/mgr01/error.log
loose-group_replication_local_address= "172.17.139.77:33061"

MGR02節點配置如下：

[mysqld@mgr02]
datadir=/data/GreatSQL/mgr02
socket=/data/GreatSQL/mgr02/mysql.sock
port=3307
server_id=103317
log-error=/data/GreatSQL/mgr02/error.log
loose-group_replication_local_address= "172.17.139.77:33071"

啟動MGR01實例、MGR02實例，並修改密碼

#啟動兩個實例
$ systemctl restart greatsql@mgr01 &
$ systemctl restart greatsql@mgr02 &
#獲取初始化密碼
$ grep root /data/GreatSQL/mgr01/error.log
$ grep root /data/GreatSQL/mgr02/error.log
#登錄資料庫並修改密碼
$ mysql -S /data/GreatSQL/mgr01/mysql.sock -uroot -p
greatsql> alter user root@'localhost' identified by 'GreatSQL@666';
$ mysql -S /data/GreatSQL/mgr02/mysql.sock -uroot -p
greatsql> alter user root@'localhost' identified by 'GreatSQL@666';

檢查兩個實例是否正確載入group_replicaiton 插件

greatsql> show plugins;
+----------------------------------+----------+--------------------+----------------------+---------+
| Name                             | Status   | Type               | Library              | License |
+----------------------------------+----------+--------------------+----------------------+---------+
| group_replication                | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------------+----------+--------------------+----------------------+---------+

沒有載入的話可以手動載入這個plugin

greatsql> install plugin group_replication soname 'group_replication.so';

搭建MGR

接下來就可以手工搭建MGR，流程如下可參考安裝部署MGR集群 | 深入淺出MGR(https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/deep-dive-mgr/deep-dive-mgr-03.md)）

MGR01實例操作：

greatsql> set session sql_log_bin=0;
# 特別註意下麵因為8.0.4版本開始使用的預設是“caching_sha2_password”，所以這樣創建會採用最新的身份認證插件
greatsql> create user repl@'%' identified by 'GreatSQL@666';
greatsql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
greatsql> set session sql_log_bin=1;
greatsql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='GreatSQL@666' FOR CHANNEL 'group_replication_recovery';

接下來即可啟動MGR集群：

greatsql> set global group_replication_bootstrap_group=ON;

greatsql> start group_replication;

greatsql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 2920447e-35bf-11ee-89a5-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: PRIMARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom

MGR02實例操作：

greatsql> set session sql_log_bin=0;
greatsql> create user repl@'%' identified by 'GreatSQL@666';
greatsql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
greatsql> set session sql_log_bin=1;
greatsql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='GreatSQL@666' FOR CHANNEL 'group_replication_recovery';
greatsql> start group_replication;
Query OK, 0 rows affected (5.39 sec)

此時創建的用戶採用的都是caching_sha2_password身份認證插件

greatsql> SELECT USER,PLUGIN FROM mysql.`user` ;
+------------------+-----------------------+
| USER             | PLUGIN                |
+------------------+-----------------------+
| repl             | caching_sha2_password |
| mysql.infoschema | caching_sha2_password |
| mysql.session    | caching_sha2_password |
| mysql.sys        | caching_sha2_password |
| root             | caching_sha2_password |
+------------------+-----------------------+

雖然啟動MGR成功，但是查看下節點狀態：

greatsql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 2920447e-35bf-11ee-89a5-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: PRIMARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom
*************************** 2. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 2a4f068b-35bf-11ee-9504-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3307
              MEMBER_STATE: RECOVERING
               MEMBER_ROLE: SECONDARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom
2 rows in set (0.00 sec)

此時節點一直處於RECOVERING狀態，查看mgr02實例的錯誤日誌如下：

2023-08-08T08:00:47.034870Z 42 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'group_replication_recovery': error connecting to master '[email protected]:3306' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. Error_code: MY-002061
2023-08-08T08:00:47.037631Z 35 [ERROR] [MY-011582] [Repl] Plugin group_replication reported: 'There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'
2023-08-08T08:00:47.037671Z 35 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'

這是由於caching_sha2_password 是 MySQL 8.0.4 引入的一個新的身份驗證插件，caching_sha2_password 對密碼安全性要求更高，要求用戶認證過程中在網路傳輸的密碼是加密的，所以導致的這個問題的出現，caching_sha2_password的介紹可以看社區文章“淺談 MySQL 新的身份驗證插件 caching_sha2_password【微信導入、微信導入】”

解決方式

1、採用舊密碼驗證插件

舊的身份驗證插件mysql_native_password，mysql_native_password的特點是不需要加密的連接。該插件驗證速度特別快，但是不夠安全，只需要更改創建用戶的語句

create user repl@'%' identified with mysql_native_password by 'GreatSQL@666';

舊密碼驗證插件容易被破解，如果有 GreatSQL 服務要公網上使用，建議還是儘量使用 caching_sha2_password作為認證插件

2、啟用group_replication_recovery_get_public_key

設置 group_replication_recovery_get_public_key=ON 可以確保從節點在連接到主節點時能夠獲取所需的公鑰，從而允許安全連接併成功進行身份驗證，避免了連接錯誤和身份驗證問題。

手冊中也有明確說明：

18.6.3.1.1 Replication User With The Caching SHA-2 Authentication Plugin
By default, users created in MySQL 8 use Section 6.4.1.2, “Caching SHA-2 Pluggable Authentication”. If the replication user you configure for distributed recovery uses the caching SHA-2 authentication plugin, and you are not using SSL for distributed recovery connections, RSA key-pairs are used for password exchange. For more information on RSA key-pairs, see Section 6.3.3, “Creating SSL and RSA Certificates and Keys”.

In this situation, you can either copy the public key of the to the joining member, or configure the donors to provide the public key when requested. The more secure approach is to copy the public key of the replication user account to the joining member. Then you need to configure the group_replication_recovery_public_key_path system variable on the joining member with the path to the public key for the replication user account. rpl_user

The less secure approach is to set group_replication_recovery_get_public_key=ON on donors so that they provide the public key of the replication user account to joining members. There is no way to verify the identity of a server, therefore only set group_replication_recovery_get_public_key=ON when you are sure there is no risk of server identity being compromised, for example by a man-in-the-middle attack.

可以看到，當確認環境安全以及沒人任何人攻擊集群時，如果不配置ssl，可以最低配置group_replication_recovery_get_public_key=ON來在請求複製用戶密鑰時給公鑰

3、為組複製通道啟用SSL支持

以下操作方法僅使用於 GreatSQL/MySQL 8.0.27版本及以上

更安全的方法是將repl用戶所需的公鑰文件複製到joiner節點的Server所在主機中。然後，在joiner節點的Server中配置group_replication_recovery_public_key_path系統變數，指定rpl_user用戶所需的公鑰文件路徑。

使用caching_sha2_password 插件身份驗證會在數據目錄下生成如下兩個RSA文件：

private_key.pem
public_key.pem
  • private_key.pem：RSA私鑰
  • public_key.pem： RSA公鑰

對於 MGR ，如果設置 group_replication_ssl_mode=DISABLED 必須使用下麵的變數來指定 RSA 公鑰，否則報錯：

  • group_replication_recovery_get_public_key ：向服務端請求 RSA 公鑰；
  • group_replication_recovery_public_key_path ：指定本地 RSA 公鑰文件；

指定本地RSA公鑰，首先需要全局MGR配置開啟SSL

[mysqld]
#開啟use_ssl，指定組成員之間的組複製分散式恢復連接是否應使用 SSL
loose-group_replication_recovery_use_ssl=ON

進入MGR01實例配置

greatsql> set session sql_log_bin=0;
# 此時就可以使用“caching_sha2_password”身份認證插件
greatsql> create user repl@'%' identified by 'GreatSQL@666';
greatsql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
greatsql> set session sql_log_bin=1;
greatsql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='GreatSQL@666' FOR CHANNEL 'group_replication_recovery';

啟動MGR01實例的MGR集群

greatsql> set global group_replication_bootstrap_group=ON;
greatsql> start group_replication;
greatsql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 35b653d2-3658-11ee-93c9-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: PRIMARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom

啟動成功後，需要把MGR01節點的RSA公鑰拷貝到MGR02節點上,因為MGR02也會生成此公鑰，所以最好創建一個文件夾

$ mkdir mgr01_key
$ chown mysql:mysql mgr01_key/
# 將public_key.pem移動到MGR02
$ mv /data/GreatSQL/mgr01/public_key.pem /data/GreatSQL/mgr02/mgr01_key/

當然，如果有多個節點，也需要把主節點的RSA公鑰移動到各個節點上

MGR02節點操作

greatsql> set session sql_log_bin=0;
greatsql> create user repl@'%' identified by 'GreatSQL@666';
greatsql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
greatsql> set session sql_log_bin=1;
greatsql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='GreatSQL@666' FOR CHANNEL 'group_replication_recovery';

# 此命令設置完成後，最好寫進my.cnf文件中持久化
greatsql> set global group_replication_recovery_public_key_path = "/data/GreatSQL/mgr02/mgr01key/public_key.pem";

greatsql> start group_replication;
greatsql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 35b653d2-3658-11ee-93c9-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: PRIMARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom
*************************** 2. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: aa031fb9-365a-11ee-9925-00163e566da1
               MEMBER_HOST: 172.17.139.77
               MEMBER_PORT: 3307
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: SECONDARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom

可以看到雙節點ONLINE，新加入的節點不會一直是RECOVERING狀態

總結

新身份驗證插件caching_sha2_password安全度相比其他的身份驗證插件，既解決安全性問題又解決性能問題，建議使用新密碼驗證插件。

也感謝社區用戶指出GreatSQL社區文檔中的不足，並給予用戶金幣獎勵，同時歡迎大家來GreatSQL社區捉蟲~

Enjoy GreatSQL

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • docker鏡像倉庫hub.docker.com無法訪問-解決辦法
    目錄docker鏡像倉庫hub.docker.com無法訪問-解決辦法1 個人鏡像站點2 dockerhub為什麼無法訪問2.1 查看dockerhub實際IP2.2 ping檢測3 鏡像加速3.1 使用國內鏡像加速3.1.1 docker配置：3.1.2 containerd配置：3.2 使用博主 ...
  • linux系統創建新的Swap分區
    先執行 free -h 查看現在的swap分配情況 執行 swapon -s 查看swap的分區文件 執行 swapoff /dev/dm-1 取消已經掛上的swap文件 現在擴充swap到4G，並將swap文件掛到/vm_memory/swapfile上 先創建/vm_memory/swapfil ...
  • Linux禁止root用戶ssh登錄
    1、背景描述 出於安全考慮，需要禁止使用root用戶通過ssh遠程登錄Linux 禁用root用戶遠程登錄後，需要提供一個許可權用戶用於ssh遠程登錄 2、創建擁有sudo許可權的用戶 2.1、創建一個普通用戶rain useradd命令用於創建一個用戶， 選項 -m 表示創建用戶的主目錄， -c 表示 ...
  • 讀高性能MySQL（第4版）筆記08_創建高性能索引（上）
    1. 索引 1.1. 鍵（key） 1.2. 存儲引擎用於快速找到記錄的一種數據結構 1.3. 當表中的數據量越來越大時，索引對性能的影響愈發重要 1.4. 在數據量較小且負載較低時，缺少合適的索引對性能的影響可能還不明顯 1.5. 索引優化是對查詢性能優化最有效的手段 1.6. 索引能夠輕易將查詢 ...
  • 一次性全講透GaussDB（DWS）鎖的問題
    本文分享自華為雲社區《GaussDB（DWS）鎖問題全解》，作者： yd_211043076。 一、gaussdb有哪些鎖 1、常規鎖：常規鎖主要用於業務訪問資料庫對象的加鎖，保護併發操作的對象，保持數據一致性；常見的常規鎖有表鎖（relation）和行鎖（tuple）。 表鎖：當對錶進行DDL、D ...
  • 【共建開源】手把手教你貢獻一個 SeaTunnel PR，超級詳細教程！
    Apache SeaTunnel是一個非常易於使用的、超高性能的分散式數據集成平臺，支持海量數據的實時同步。每天可穩定高效同步數百億數據，已被近百家企業投入生產使用。 現在的版本不支持通過jtds的方式鏈接sqlserver，我們來自己寫代碼來實現它，並把代碼提交給apache seatunnel。 ...
  • 性能、安全和穩定，袋鼠雲數據服務平臺 DataAPI 為企業 API 保駕護航
    通過 API 對外提供數據服務是大部分企業中比較常見的數據應用方式，對於 API 平臺管理者、開發者和調用者來說，API 的調用性能、安全性和穩定性是在平臺選型時最需要考慮的三個因素。 袋鼠雲API開發及管理平臺【數棧-數據服務 DataAPI】通過多種手段標準化管控服務，可完成從 API 創建、發 ...
  • 白鯨開源 X SelectDB 金融大數據聯合解決方案公佈！從源頭解決大數據開發挑戰
    業務挑戰與痛點 隨著互聯網技術的發展、雲計算技術的成熟、人工智慧技術的興起和數字化經濟的崛起，數據已成為企業的核心資產。在金融行業中，數字化已成為了支撐各類業務場景的核心力量，包括個人理財、企業融資、股票交易、保險理賠、貸款服務、支付結算、投資咨詢、資產管理等等。然而，在基於大數據分析與處理技術的業 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類