通过编写脚本，先查询出集群的用户信息，再使用show grants语句查询出该用户的权限。如:

[gbase@rhel6201 ~]$ cat get_privileges.sh 
#!/bin/sh
user=$1
password=$2 
/opt/gcluster/server/bin/gbase -u$user -p$password -e"select concat('show grants for ''',trim(user),'''@''',trim(host),''';') from gbase.user;" | grep 'grant' | grep -v concat > showgrants.sql
/opt/gcluster/server/bin/gbase -u$user -p$password < showgrants.sql | grep -v -i 'Grants for' | sed 's/\(GRANT .*\)/\1;/'

测试结果:

[gbase@rhel6201 ~]$ sh get_privileges.sh root
Enter password: 输入两次回车是因为root的密码为空。
Enter password: 
GRANT ALL PRIVILEGES ON *.* TO 'gbase'@'%' IDENTIFIED BY PASSWORD '*9C0ADBD7F08FA9D49D82760B104110C55B943B8D' WITH GRANT OPTION;
GRANT USAGE ON *.* TO 'jihui'@'%' IDENTIFIED BY PASSWORD '*DD4F4D0B20DEE5E8A4A7512FD870DAD13613E2CE';
GRANT SELECT ON "test".* TO 'jihui'@'%' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
[gbase@rhel6201 ~]$

nodedatamap系统表用于计算一致性hash，数据hash分布时要访问此表。该表存储于每个节点gcluster和gnode的gclusterdb数据库和gbase数据库下。此表是安装集群后，通过initnodedatamap命令初始化的。
表中记录数为65536行。表结构如下：

CREATE TABLE "nodedatamap" (
  "hashkey" int(11) DEFAULT NULL,
  "nodeid" int(11) DEFAULT NULL
) ENGINE=EXPRESS DEFAULT CHARSET=utf8 TABLESPACE='sys_tablespace' 

可以利用crc32函数查询判断数据hash分布后落在哪个节点，如：

select nodeid from nodedatamap where hashkey = crc32('13184647638')%65536;

可以使用以下SQL判断表是否损坏，如SQL执行报错，则说明表已经损坏

select count(*) from gclusterdb.nodedatamap;
select distinct nodeid from gclusterdb.nodedatamap;
select * from gclusterdb.nodedatamap;

如果确认nodedatamap表损坏，可以执行以下命令重新初始化此表：refreshnodedatamap
执行前需确保gcluster没有其它操作。

GBase集群hash分布列支持varchar、int类型。
char、date、datetime、decimal等类型不能作为HASH分布键。

因为两种表使用的是不同的数据库引擎，因此需要创建与系统表同样表结构的Express引擎表。
打开_gbase_query_path参数（set global _gbase_query_path=1）。
执行insert select，将系统表的数据转存到对应的Express引擎表中。
基于Express引擎的表进行两表JOIN查询。

core文件是进程由于各种原因导致crash而产生。
core文件的大小由当时程序占用的内存空间决定，因为他要dump程序的整个内存空间的内容。
core文件可以删除。但在删除之前，需要确认这些crash的原因、状况是否已经记录。

查看方法：
以查看gclusterd的core文件的方式为例（其他程序crash的查看方式类似）：
gdb /opt/gcluster/server/bin/gclusterd /opt/gcluster/userdata/gcluster/core文件
然后执行：thread apply all bt得到宕机堆栈。
同时查看/opt/gcluster/log/gcluster/system.log文件，这里面一般情况下都能记录到宕机堆栈以及宕机SQL。