前言：
在上篇中我们已经成功的部署了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 的只读权限。
