手工构建MGR碰到的次节点一直处于recovering状态
下午按照Gitee上的GreatSQL-Doc/deep-dive-mgr /deep-dive-mgr-03.md文件手动构建了一个MGR集群，三节点，其中主节点一直正常起来online，但两个次节点一直处于recovering状态，然后自动重试一段时间后最终被移除出集群，日志报错信息是次节点通过repl账户连不上主节点，报错如下：Aug6 16:14:34 mgr02 mysqld: 2023-08-06T08:14:34.665660Z 82 Slave I/O for channel 'group_replication_recovery': error connecting to master 'repl@192.168.1.21:3306' - retry-time: 60 retries: 1 message: Host '192.168.1.22' is not allowed to connect to this MySQL server, Error_code: MY-001130
Aug6 16:14:34 mgr02 mysqld: 2023-08-06T08:14:34.672550Z 54 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.'
Aug6 16:14:34 mgr02 mysqld: 2023-08-06T08:14:34.672656Z 54 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.'
然后人工试了下创建的repl账户去次节点连接主节点，果然不行，提示需要改为mysql_native_password插件才行（突然想起这是8.0版本，尴尬），于是乎急忙改了，结果提示还是有问题，说密码不对，如下：
Aug6 16:56:38 mgr02 mysqld: 2023-08-06T08:56:38.122974Z 144 Slave I/O for channel 'group_replication_recovery': error connecting to master 'repl@192.168.1.21:3306' - retry-time: 60 retries: 1 message: Access denied for user 'repl'@'192.168.1.22' (using password: YES), Error_code: MY-001045
结果又手工试了下去次节点连接主节点，果真不行，一下子懵了，于是好好研究了一下修改的语句，语句如下：
set session sql_log_bin=0;
set global super_read_only=off;
alter user repl identified with mysql_native_password;
set session sql_log_bin=1;
然后特地百度了一下alter语法，果然又是我搞错了（欲速则不达，问题alter这么写，MySQL也给通过:sleepy:），应该是alter user repl@‘%’ identified 。。。。最终ok
ps：过程当中我其实通过以下办法仍无法解决，仍然报密码不对，后面新建账户用了新账户去连。
set session sql_log_bin=0;
set global super_read_only=off;
update mysql.user set plugin ="mysql_native_password" where user = 'repl' and host = '%';
flush privileges;
set session sql_log_bin=1;
set session sql_log_bin=0;
update mysql.user set host = '192.168.1.%' where user = 'repl' and host = '%';
flush privileges;
set session sql_log_bin=1;
下午有点晕，心想可能通过update修改可能真的不行吧，show grants for的时候都提示没这个授权信息，于是就干脆新建账户去搞了
上文中有错误提示Host '192.168.1.22' is not allowed to connect to this MySQL server
表示该主机没有权限连接，这时候应该检查授权里指定的IP/HOST是否正确。
用户认证的plugin选用默认的caching_sha2_password是不影响MGR的，应该不是这个的原因。
建议你把详细过程完整贴出来，估计就能定位出问题在哪了。 本帖最后由 greatSQL_user01 于 2023-8-6 22:04 编辑
yejr 发表于 2023-8-6 21:37
上文中有错误提示
表示该主机没有权限连接，这时候应该检查授权里指定的IP/HOST是否正确。
我是完全按照这个手册笔记去搭建的，除了版本是最新的。如果说认证插件不影响mgr连接，那我用手册创建的repl在次节点上直接命令行也真的是无法连通访问主节点的MySQL呢，然后改了认证插件才不报这个not allowed的错误。我环境是centos 7.6 64位，配置文件也跟手册笔记一样极简。之前报错信息如下（每次重启一下mysql服务就能短暂提示reachable，但还是recovering，然后不断地自动重试，最终被移除）：
greatSQL_user01 发表于 2023-8-6 21:59
我是完全按照这个手册笔记去搭建的，除了版本是最新的。如果说认证插件不影响mgr连接，那我用手册创建的re ...
后续重新搭建继续验证，正常起了主节点，尝试起一个从节点的时候依然一直是recovering状态，如下（有个附件是正常部署单机环境的步骤，之后搭建mgr是按照官方03笔记的第3/4步骤反复搞，先起引导主节点正常，再起从节点报错）：
greatSQL_user01 发表于 2023-8-6 23:46
后续重新搭建继续验证，正常起了主节点，尝试起一个从节点的时候依然一直是recovering状态，如下（有个附 ...
如果你了解ansible(学习几个小时的水平)，可以尝试使用我的这个ansible自动化部署工具部署。支持GreatSQL MGR。
如果部署成功，之后可以查看ansible源代码，(一般看task name就明白了每个步骤是做什么)知道我的部署的每一步骤细节。 greatSQL_user01 发表于 2023-8-6 23:46
后续重新搭建继续验证，正常起了主节点，尝试起一个从节点的时候依然一直是recovering状态，如下（有个附 ...
看了GreatSQL初始化过程没问题。
构建MGR的详细过程，以及错误日志也请提供下。
如果是想快速体验，也可以用Docker快速部署（https://gitee.com/GreatSQL/GreatSQL-Docker）
或者用Ansible（https://gitee.com/GreatSQL/GreatSQL-Ansible），还有上面芬达老师的项目，都可以尝试。 yejr 发表于 2023-8-7 08:28
看了GreatSQL初始化过程没问题。
构建MGR的详细过程，以及错误日志也请提供下。
此为相关数据，麻烦大佬看看
fander 发表于 2023-8-7 01:10
如果你了解ansible(学习几个小时的水平)，可以尝试使用我的这个ansible自动化部署工具部署。支持GreatSQL ...
这是下一步的打算，一步步来嘛:lol greatSQL_user01 发表于 2023-8-7 11:06
此为相关数据，麻烦大佬看看
在各个节点上分别执行类似下面的SQL
SET SQL_LOG_BIN=0;
alter USER repl@'%' IDENTIFIED WITH mysql_native_passwrod BY 'repl';
SET SQL_LOG_BIN=1;
# 再次change master设置MGR复制通道
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
先排除auth plugin因素再说是否还有其他原因
似乎还有网络连接方面的原因，建议在个节点分别设置 report_host = '本地IP' 选项 yejr 发表于 2023-8-7 12:18
在各个节点上分别执行类似下面的SQL
改了认证插件就好了，现在已经全部起来，跟昨天情况差不多，感谢大佬指导。最终效果如下：
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 88285299-34cc-11ee-af69-000c29af0d62 | 192.168.7.5 | 3306 | ONLINE | SECONDARY | 8.0.32 | XCom |
| group_replication_applier | e4f0aadd-34e1-11ee-8207-000c2969cc41 | 192.168.7.6 | 3306 | ONLINE | SECONDARY | 8.0.32 | XCom |
| group_replication_applier | eb34c304-34c9-11ee-a5ac-000c29016f21 | 192.168.7.4 | 3306 | ONLINE | PRIMARY | 8.0.32 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
mysql>
页:
[1]
2