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
  • WPF 已知問題 監聽 WMI 事件導致觸摸失效
    示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後，項目結構如下所示： MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread]特性
    [STAThread] 特性用於需要與 COM 組件交互的應用程式，尤其是依賴單線程模型（如 Windows Forms 應用程式）的組件。在 STA 模式下，線程擁有自己的消息迴圈，這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • UWP WinUI3 傳入 AddHandler 的 RoutedEventHandler 類型與事件所需不匹配將拋出參數異常
    在WinForm中使用全局異常捕獲處理 在WinForm應用程式中，全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理，可以有效地捕獲並處理未預見的異常，從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • .NET 多版本 WinForm 開源控制項庫 SunnyUI
    前言 給大家推薦一款開源的 Winform 控制項庫，可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫，同時也提供了工具類庫、擴展 ...
  • .net core8 使用Swagger（附當前源碼）
    說明 該文章是屬於OverallAuth2.0系列文章，每周更新一篇該系列文章（從0到1完成系統開發）。 該系統文章，我會儘量說的非常詳細，做到不管新手、老手都能看懂。 說明：OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友，請關註我吧(*^▽^*) ...
  • WPF 什麼時候 VisualTreeHelper.GetDescendantBounds 將返回無窮大
    一、下載安裝 1.下載git 必須先下載並安裝git，再TortoiseGit下載安裝 git安裝參考教程：https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit，Git客戶端，32/6 ...
  • C# 開源教程帶你輕鬆掌握數據結構與演算法
    前言 在項目開發過程中，理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼，還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程：Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 第22篇 生成proto文件bat腳本
    1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 記一次 .NET某上位機視覺程式 卡死分析
    一：背景 1. 講故事 前段時間有位朋友找到我，說他的窗體程式在客戶這邊出現了卡死，讓我幫忙看下怎麼回事？dump也生成了，既然有dump了那就上 windbg 分析吧。 二：WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死，入口門檻很低，後續往下分析就不一定了，不管怎麼說先用 !clrsta ...
  • 醫學DICOM文件與PACS系統進行數據傳輸
    前言 人工智慧時代，人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API，工具不僅易於集成，還具備高效處理能力。 本文將介紹一款如何利用這些API，為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...
所有分類