WSL环境下GridDB出现10008 TXN_CLUSTER_ROLE_UNMATCH错误求助

错误原因分析 #

错误码10008对应的TXN_CLUSTER_ROLE_UNMATCH，核心问题是客户端发起的操作与目标节点的集群权限不匹配，常见触发场景：

• 客户端连接的是从属节点（Slave），但执行了仅主节点（Master）允许的写操作（如创建容器、插入数据）
• 集群主节点选举未完成，节点角色处于未同步的异常状态
• gs_joincluster执行后，节点角色未成功切换，或集群配置未生效

解决步骤 #

1. 检查目标节点的集群角色 #

登录WSL内的GridDB节点，执行命令查看节点当前角色：

gs_stat -u admin -w adminpass

在输出中定位clusterRole字段，确认是否为MASTER。若显示SLAVE或UNKNOWN，说明当前连接的节点无写权限。

2. 确认集群主节点地址 #

若当前连接的是从属节点，执行命令获取集群内所有节点的角色信息，找到主节点IP：

gs_clustercheck -u admin -w adminpass -s 192.168.0.1 -p 10001

3. 修改客户端连接配置 #

将代码中props的连接地址替换为主节点IP，示例如下：

Properties props = new Properties();
props.setProperty("notificationAddress", "主节点实际IP");
props.setProperty("notificationPort", "10001");
props.setProperty("user", "admin");
props.setProperty("password", "adminpass");

4. 重启节点刷新集群状态 #

若gs_joincluster执行后角色未更新，重启GridDB服务：

gs_stopnode -u admin -w adminpass
gs_startnode

重启后再次用gs_stat检查角色是否切换为MASTER（若该节点被选举为主节点）。

5. 校验集群配置一致性 #

确保所有节点的gs_cluster.json中clusterName与gs_joincluster命令的-c myCluster完全一致，避免因集群名称不匹配导致角色异常。

单节点集群补充处理 #

如果是单节点部署，需确认gs_node.json中的clusterRole字段设置为MASTER，修改后重启节点即可。

内容的提问来源于stack exchange，提问作者Omar Esawy