用户提出了“手工构建MGR碰到的次节点一直处于recovering状态”经过排查后发现了是因为新密码验证插件caching_sha2_password导致的从节点一直无法连接主节点帖子地址(https://greatsql.cn/thread-420-2-1.html)

环境介绍

采用的是单机多实例的部署方式如何部署单机多实例可以前往(https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/6-oper-guide/6-6-multi-instances.md)

IP端口角色172.17.139.773306mgr01172.17.139.773307mgr02

MGR有关配置参数

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

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

loose-group_replication_communication_max_message_size

10M

loose-group_replication_transaction_size_limit

loose-group_replication_arbitrator

loose-group_replication_single_primary_fast_mode

loose-group_replication_request_time_threshold

20000

socket/data/GreatSQL/mgr01/mysql.sock

port3306

log-error/data/GreatSQL/mgr01/error.log

loose-group_replication_local_address

172.17.139.77:33061

socket/data/GreatSQL/mgr02/mysql.sock

port3307

log-error/data/GreatSQL/mgr02/error.log

loose-group_replication_local_address

172.17.139.77:33071

/data/GreatSQL/mgr01/mysql.sock

-uroot

/data/GreatSQL/mgr02/mysql.sock

-uroot

-----------------------------------------------------------------------------------------------

Name

-----------------------------------------------------------------------------------------------

group_replication

-----------------------------------------------------------------------------------------------

greatsql

深入浅出MGR(https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/deep-dive-mgr/deep-dive-mgr-03.md)

MGR01实例操作

特别注意下面因为8.0.4版本开始使用的默认是“caching_sha2_password”所以这样创建会采用最新的身份认证插件

greatsql

group_replication_bootstrap_groupON;greatsql

start

performance_schema.replication_group_members\G

row

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

2920447e-35bf-11ee-89a5-00163e566da1MEMBER_HOST:

3306MEMBER_STATE:

此时创建的用户采用的都是caching_sha2_password身份认证插件

greatsql

-----------------------------------------

USER

-----------------------------------------

repl

-----------------------------------------

greatsql

performance_schema.replication_group_members\G

row

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

2920447e-35bf-11ee-89a5-00163e566da1MEMBER_HOST:

3306MEMBER_STATE:

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

2a4f068b-35bf-11ee-9504-00163e566da1MEMBER_HOST:

3307MEMBER_STATE:

此时节点一直处于RECOVERING状态查看mgr02实例的错误日志如下

[ERROR]

performance_schema.replication_group_members

table

performance_schema.replication_connection_status

table

引入的一个新的身份验证插件caching_sha2_password

对密码安全性要求更高要求用户认证过程中在网络传输的密码是加密的所以导致的这个问题的出现caching_sha2_password的介绍可以看社区文章“浅谈

MySQL

caching_sha2_password【微信导入、微信导入】”

解决方式

旧的身份验证插件mysql_native_passwordmysql_native_password的特点是不需要加密的连接。

该插件验证速度特别快但是不够安全只需要更改创建用户的语句

create

2、启用group_replication_recovery_get_public_key

group_replication_recovery_get_public_keyON

可以确保从节点在连接到主节点时能够获取所需的公钥从而允许安全连接并成功进行身份验证避免了连接错误和身份验证问题。

手册中也有明确说明

group_replication_recovery_public_key_path

system

group_replication_recovery_get_public_keyON

donors

group_replication_recovery_get_public_keyON

when

可以看到当确认环境安全以及没人任何人攻击集群时如果不配置ssl可以最低配置group_replication_recovery_get_public_keyON来在请求复制用户密钥时给公钥

GreatSQL/MySQL

更安全的方法是将repl用户所需的公钥文件复制到joiner节点的Server所在主机中。

然后在joiner节点的Server中配置group_replication_recovery_public_key_path系统变量指定rpl_user用户所需的公钥文件路径。

private_key.pem

private_key.pemRSA私钥public_key.pem

RSA公钥

group_replication_ssl_modeDISABLED

RSA

group_replication_recovery_get_public_key

向服务端请求

公钥group_replication_recovery_public_key_path

指定本地

#开启use_ssl指定组成员之间的组复制分布式恢复连接是否应使用

SSL

loose-group_replication_recovery_use_sslON

进入MGR01实例配置

此时就可以使用“caching_sha2_password”身份认证插件

greatsql

group_replication_bootstrap_groupON;

greatsql

performance_schema.replication_group_members\G

row

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

35b653d2-3658-11ee-93c9-00163e566da1MEMBER_HOST:

3306MEMBER_STATE:

启动成功后需要把MGR01节点的RSA公钥拷贝到MGR02节点上,因为MGR02也会生成此公钥所以最好创建一个文件夹

mkdir

/data/GreatSQL/mgr01/public_key.pem

/data/GreatSQL/mgr02/mgr01_key/

MGR02节点操作

group_replication_recovery_public_key_path

/data/GreatSQL/mgr02/mgr01key/public_key.pem;greatsql

start

performance_schema.replication_group_members\G

row

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

35b653d2-3658-11ee-93c9-00163e566da1MEMBER_HOST:

3306MEMBER_STATE:

***************************CHANNEL_NAME:

group_replication_applierMEMBER_ID:

aa031fb9-365a-11ee-9925-00163e566da1MEMBER_HOST:

3307MEMBER_STATE:

可以看到双节点ONLINE新加入的节点不会一直是RECOVERING状态

新身份验证插件caching_sha2_password安全度相比其他的身份验证插件既解决安全性问题又解决性能问题建议使用新密码验证插件。

也感谢社区用户指出GreatSQL社区文档中的不足并给予用户金币奖励同时欢迎大家来GreatSQL社区捉虫~

Enjoy

GreatSQL是适用于金融级应用的国内自主开源数据库具备高性能、高可靠、高易用性、高安全等多个核心特性可以作为MySQL或Percona

Server的可选替换用于线上生产环境且完全免费并兼容MySQL或Percona

相关链接

https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情

https://greatsql.cn/thread-100-1-1.html

技术交流群