前言:
在上篇中我们已经成功的部署了Nebula Graph 服务:Nebula Graph-01-Nebula Graph简介和安装以及客户端连接,
现在我们来谈一下Nebula Graph 的各项配置
NebulaGraph高阶配置 文件
在上篇文章中,我们成功的启动了NebulaGraph 服务,但是根本没有修改什么配置,这是因为如果我们在本地单机部署的话,那么我们Graph 服务、Meta 服务和 Storage 服务 全部部署在一个服务器,默认配置已经够了,但是如果有其他需要,我们可以修改配置;
官网说明:https://docs.nebula-graph.com.cn/3.6.0/5.configurations-and-logs/1.configurations/1.configurations/
Meta 服务配置
Meta 服务提供了两份初始配置文件nebula-metad.conf.default和nebula-metad.conf.production,方便在不同场景中使用。文件的默认路径为/usr/local/nebula/etc/。
如需使用初始配置文件,从上述两个文件选择其一,删除后缀.default或.production,Meta 服务才能将其识别为配置文件并从中获取配置信息。
- basics 配置
名称 | 预设值 | 说明 | 是否支持运行时动态修改 |
---|---|---|---|
daemonize | true | 是否启动守护进程。 | 不支持 |
pid_file | pids/nebula-metad.pid | 记录进程 ID 的文件。 | 不支持 |
timezone_name | 指定 NebulaGraph 的时区。初始配置文件中未设置该参数,如需使用请手动添加。系统默认值为UTC+00:00:00。格式请参见 Specifying the Time Zone with TZ。例如,东八区的设置方式为–timezone_name=UTC+08:00。 | 不支持 |
注:在插入时间类型的属性值时,NebulaGraph 会根据timezone_name设置的时区将该时间值(TIMESTAMP 类型例外)转换成相应的 UTC 时间,因此在查询中返回的时间类型属性值为 UTC 时间。
timezone_name参数只用于转换 NebulaGraph 中存储的数据,NebulaGraph 进程中其它时区相关数据,例如日志打印的时间等,仍然使用主机系统默认的时区。
- logging 配置
- networking 配置
注:使用 IP 时建议使用真实的 IP。否则某些情况下127.0.0.1/0.0.0.0无法正确解析。
- storage 配置
- misc 配置
- rocksdb options
Graph 服务配置
Graph 服务提供了两份初始配置文件nebula-graphd.conf.default和nebula-graphd.conf.production,方便在不同场景中使用。文件的默认路径为/usr/local/nebula/etc/。
如需使用初始配置文件,从上述两个文件选择其一,删除后缀.default或.production,Graph 服务才能将其识别为配置文件并从中获取配置信息。
- basics 配置
在插入时间类型 的属性值时,NebulaGraph 会根据timezone_name设置的时区将该时间值(TIMESTAMP 类型例外)转换成相应的 UTC 时间,因此在查询中返回的时间类型属性值为 UTC 时间。
timezone_name参数只用于转换 NebulaGraph 中存储的数据,NebulaGraph 进程中其它时区相关数据,例如日志打印的时间等,仍然使用主机系统默认的时区。
- logging 配置
- query 配置
- networking 配置
使用 IP 时建议使用真实的 IP。否则某些情况下127.0.0.1/0.0.0.0无法正确解析。
-
authorization 配置
-
memory 配置
-
metrics 配置
-
session 配置
-
experimental 配置
-
memory tracker 配置
-
performance optimization 配置
Storage 服务配置
Storage 服务提供了两份初始配置文件nebula-storaged.conf.default和nebula-storaged.conf.production,方便在不同场景中使用。文件的默认路径为/usr/local/nebula/etc/。
如需使用初始配置文件,从上述两个文件选择其一,删除后缀.default或.production,Storage 服务才能将其识别为配置文件并从中获取配置信息。
- basics 配置
在插入时间类型的属性值时,NebulaGraph 会根据timezone_name设置的时区将该时间值(TIMESTAMP 类型例外)转换成相应的 UTC 时间,因此在查询中返回的时间类型属性值为 UTC 时间。
timezone_name参数只用于转换 NebulaGraph 中存储的数据,NebulaGraph 进程中其它时区相关数据,例如日志打印的时间等,仍然使用主机系统默认的时区。
-
logging 配置
-
networking 配置
-
raft 配置
-
disk 配置
-
rocksdb options 配置
-
misc 配置
-
memory tracker 配置
查看各服务运行配置
使用curl命令获取运行中的配置项的值,即 NebulaGraph 的运行配置。
$ curl <ws_ip>:<ws_port>/flags
参数 | 说明 |
---|---|
ws_ip | HTTP 服务的 IP 地址,可以在配置文件中查看。默认值为127.0.0.1。 |
ws_port | HTTP 服务的端口,可以在配置文件中查看。默认值分别为19559(Meta)、19669(Graph)19779(Storage)。 |
# 获取 Meta 服务的运行配置
curl 127.0.0.1:19559/flags
# 获取 Graph 服务的运行配置
curl 127.0.0.1:19669/flags
# 获取 Storage 服务的运行配置
curl 127.0.0.1:19779/flags
使用-s或者–silent参数可以隐藏进度条和错误信息。例如:
curl -s 127.0.0.1:19559/flags
使用命令动态修改配置
用户可以通过curl命令动态修改 NebulaGraph 服务的配置。例如,修改 Storage 服务的wal_ttl参数为600,命令如下:
curl -X PUT -H “Content-Type: application/json” -d’{“wal_ttl”:“600”}’ -s “http://192.168.15.6:19779/flags”
其中,{“wal_ttl”:“600”}为待修改的配置参数及其值;192.168.15.6:19779为 Storage 服务的 IP 地址和 HTTP 端口号。
注:动态修改配置功能仅适用于原型验证和测试环境,不建议在生产环境中使用。因为当local_config值设置为true时,动态修改的配置不会持久化,重启服务后配置会恢复为初始配置。
仅支持动态修改部分配置参数,具体支持的参数列表,参见各服务配置中是否支持运行时动态修改的描述。
Nebula Graph 日志管理
日志管理
NebulaGraph 默认使用 glog 打印运行日志,使用 gflags 控制日志级别,并在运行时通过 HTTP 接口动态修改日志级别,方便跟踪问题。
- minloglevel:最小日志级别,即不会记录低于这个级别的日志。可选值为0(INFO)、1(WARNING)、2(ERROR)、3(FATAL)。建议在调试时设置为0,生产环境中设置为1。如果设置为4,NebulaGraph 不会记录任何日志。
- v:日志详细级别,值越大,日志记录越详细。可选值为0、1、2、3。
也可以通过命令查看各服务的日志级别
$ curl <ws_ip>:<ws_port>/flags
参数 | 说明 |
---|---|
ws_ip | HTTP 服务的 IP 地址,可以在配置文件中查看。默认值为127.0.0.1。 |
ws_port | HTTP 服务的端口,可以在配置文件中查看。默认值分别为19559(Meta)、19669(Graph)19779(Storage)。 |
示例:$ curl 127.0.0.1:19559/flags | grep ‘minloglevel’
日志查看
运行日志的默认目录为/usr/local/nebula/logs/。
如果在 NebulaGraph 运行过程中删除运行日志目录,日志不会继续打印,但是不会影响业务。重启服务可以恢复正常。
Nebula Graph 用户权限管理
开启身份验证
本地身份验证是指在服务器本地存储用户名、加密密码,当用户尝试访问 NebulaGraph 时,将进行身份验证。
默认情况下,身份验证功能是关闭的,用户可以使用root用户名和任意密码连接到 NebulaGraph 。
开启身份验证后,默认的 God 角色账号为root,密码为nebula。角色详情请参见内置角色权限。
1:编辑配置文件nebula-graphd.conf(默认目录为/usr/local/nebula/etc/),设置如下参数:
- –enable_authorize:是否启用身份验证,可选值:true、false。
- –failed_login_attempts:可选项,需要手动添加该参数。单个 Graph 节点允许连续输入错误密码的次数。超过该次数时,账户会被锁定。如果有多个 Graph 节点,允许的次数为节点数 * 次数。
- –password_lock_time_in_secs:可选项,需要手动添加该参数。多次输入错误密码后,账户被锁定的时间。单位:秒。
2:重启 NebulaGraph 服务。
用户管理
开启身份验证后,用户需要使用已创建的用户才能连接 NebulaGraph,而且连接后可以进行的操作也取决于该用户拥有的角色权限。
创建用户(CREATE USER)
执行CREATE USER语句可以创建新的 NebulaGraph 用户。当前仅 God 角色用户(即root用户)能够执行CREATE USER语句。
语法
CREATE USER [IF NOT EXISTS] <user_name> [WITH PASSWORD ‘’];
- IF NOT EXISTS:检测待创建的用户名是否存在,只有不存在时,才会创建新用户。
- user_name:待创建的用户名。长度最多为 16 个字符。
- password:用户名对应的密码。默认密码为空字符串(‘’)。长度最多为 24 个字符。
示例
nebula> CREATE USER user1 WITH PASSWORD 'nebula';
授权用户(GRANT ROLE)
执行GRANT ROLE语句可以将指定图空间的内置角色权限授予用户。当前仅 God 角色用户和 Admin 角色用户能够执行GRANT ROLE语句。具体角色可以看【系统内置角色权限】
语法
GRANT ROLE <role_type> ON <space_name> TO <user_name>;
示例
nebula> GRANT ROLE USER ON basketballplayer TO user1;
撤销用户权限(REVOKE ROLE)
执行REVOKE ROLE语句可以撤销用户的指定图空间的内置角色权限。当前仅 God 角色用户和 Admin 角色用户能够执行REVOKE ROLE语句。
语法
REVOKE ROLE <role_type> ON <space_name> FROM <user_name>;
示例
nebula> REVOKE ROLE USER ON basketballplayer FROM user1;
查看指定用户权限(DESCRIBE USER)
执行DESCRIBE USER语句可以查看指定用户的角色权限信息。
语法
DESCRIBE USER <user_name>;
DESC USER <user_name>;
示例
nebula> DESCRIBE USER user1;
查看指定空间内用户权限(SHOW ROLES)¶
执行SHOW ROLES语句可以查看指定空间内的所有用户(除root以外)和对应角色权限的信息。
语法
SHOW ROLES IN <space_name>;
示例
nebula> SHOW ROLES IN basketballplayer;
修改用户密码(CHANGE PASSWORD)¶
执行CHANGE PASSWORD语句可以修改用户密码,修改时需要提供旧密码和新密码。
语法
CHANGE PASSWORD <user_name> FROM ‘<old_password>’ TO ‘<new_password>’;
示例
nebula> CHANGE PASSWORD user1 FROM 'nebula' TO 'nebula123';
修改用户密码(ALTER USER)¶
执行ALTER USER语句可以修改用户密码,修改时不需要提供旧密码。当前仅 God 角色用户(即root用户)能够执行ALTER USER语句。
语法
ALTER USER <user_name> WITH PASSWORD ‘’;
示例
nebula> ALTER USER user2 WITH PASSWORD 'change_password';
删除用户(DROP USER)¶
执行DROP USER语句可以删除用户。当前仅 God 角色用户能够执行DROP USER语句。
删除用户不会自动断开该用户当前会话,而且权限仍在当前会话中生效。
语法
DROP USER [IF EXISTS] <user_name>;
示例
nebula> DROP USER user1;
查看用户列表(SHOW USERS)¶
执行SHOW USERS语句可以查看用户列表。当前仅 God 角色用户能够执行SHOW USERS语句。
语法
SHOW USERS;
示例
nebula> SHOW USERS;
系统内置角色权限
所谓角色,就是一组相关权限的集合。用户可以把角色分配给创建的用户,从而实现访问控制。
NebulaGraph 内置了多种角色,说明如下:
God
-
初始最高权限角色,拥有所有操作的权限。类似于 Linux 中的root和 Windows 中的administrator。
-
Meta 服务初始化时,会自动创建 God 角色用户root,密码为nebula。
-
在nebula-graphd.conf文件中(默认目录为/usr/local/nebula/etc/),当–enable_authorize为true时:
一个集群只能有一个 God 角色用户,该用户可以管理集群内所有图空间。
不支持手动授权 God 角色,只能使用默认 God 角色用户root。
Admin
- 对权限内的图空间拥有 Schema 和 data 的读写权限。
- 可以将权限内的图空间授权给其他用户。只能授权低于 ADMIN 级别的角色给其他用户。
DBA
- 对权限内的图空间拥有 Schema 和 data 的读写权限。
- 无法将权限内的图空间授权给其他用户。
User
- 对权限内的图空间拥有 Schema 的只读权限。
- 对权限内的图空间拥有 data 的读写权限。
Guest
- 对权限内的图空间拥有 Schema 和 data 的只读权限。