KunlunBase 功能体验范例
KunlunBase 功能体验范例
1 数据库的读写测试
相关性能测试推荐使用 sysbench,详情可参考:https://github.com/akopytov/sysbench/blob/master/README.md
- 相关的 sysbench 选项可以参考:https://github.com/akopytov/sysbench/blob/master/README.md#general-command-line-options
在安装完 sysbench 后,测试前需要先准备 sysbench 数据
sysbench oltp_point_select \
--tables=[共有几张数据表] \
--table-size=[每张数据表要灌的数据量,推荐至少为 10000000] \
--db-driver=[pgsql/mysql] \
--pgsql-host=[host] \
--pgsql-port=[port] \
--pgsql-user=[userNmae] \
--pgsql-password=[userPwd] \
--pgsql-db=[dbName] \
prepare
1.1 写入测试
当前 sysbench 关于写入性能相关的测试 case 有 read_write、update_index、update_non_index、write_only、insert (将下面示例的 ${case} 改成 read_write 等 case )。
命令可以参考
sysbench oltp_${case} \
--tables=${tables} \
--table-size=${tb_size} \
--db-ps-mode=disable \
--db-driver=[pgsql/mysql] \
--pgsql-host=${host} \
--report-interval=[间隔s报告一次结果] \
--pgsql-port=${port} \
--pgsql-user=${user} \
--pgsql-password=${pwd} \
--pgsql-db=${db} \
--threads=${threads} \
--time=${tim} \
--rand-type=uniform
run
1.2 查询及 join
当前 sysbench 关于查询性能相关的测试 case 有 read_only、point_select
- 相关命令可以参考第二步
当前版本 sysbench 并不支持多表 join,因此我们需要自定义 lua 测试脚本
- 以下是简单范例,可以根据需求自行修改
- vim oltp_mutli_join.lua
require("oltp_common")
-- 根据自己的需求选择是否需要引用其它lua文件
function thread_init()
drv = sysbench.sql.driver()
con = drv:connect()
end
function thread_done()
con:disconnect()
end
function event()
local tableNum1
local tableNum2
local rs
tableNum1 = math.random(1,sysbench.opt.tables)
tableNum2 = math.random(1,sysbench.opt.tables)
local table1 = "sbtest" .. tableNum1
local table2 = "sbtest" .. tableNum2
local id = math.random(1,sysbench.opt.table_size)
-- db_query("begin")
rs = db_query("SELECT a.k FROM " .. table1 .. " a left join " .. table2 .. " b ON a.id = b.id WHERE a.id= " .. id)
-- db_query("commit")
end
在自定义脚本中,必须要提供 thread_init() thread_done() event() 这三个函数
- event() 就是要运行的测试函数
- sysbench.opt.tables 则是在运行脚本时传入的 --tables 参数,sysbench.opt.table_size 是 --table_size 参数。其它传入的参数都可以通过 sysbench.opt 来获取
- db_query 就是要运行的 sql 语句,在 event() 方法中,有一个 db_query,则运行中 TPS=QPS/1。有 n 个 db_query,则运行中 TPS=QPS/n
- 不可以在自定义的lua脚本里面使用 print(),否则不会产生结果
使用 sysbench 运行自定义 lua 脚本
2 数据库的安全性
2.1 create user 和 create role 的区别
使用超级用户先创建
create role u1;
create user u2;
\du
create database vito;
\c vito
create table t1(a int, b int);
create table t2(a int, b int);
create table t3(a int, b int);
u1 是没有登录的权限,不能够进行登录数据库
在超级用户中修改用户 u1 登录权限
ALTER ROLE u1 WITH LOGIN;
2.2 创建用户和角色语法
CREATE USER/ROLE name [ [ WITH ] option [ ... ] ] : 关键词 USER,ROLE; name 用户或角色名;
where option can be:
SUPERUSER | NOSUPERUSER :超级权限,拥有所有权限,默认nosuperuser。
| CREATEDB | NOCREATEDB :建库权限,默认nocreatedb。
| CREATEROLE | NOCREATEROLE :建角色权限,拥有创建、修改、删除角色,默认nocreaterole。
| LOGIN | NOLOGIN :登录权限,作为连接的用户,默认nologin,除非是create user(默认登录)。
| REPLICATION | NOREPLICATION :复制权限,用于物理或则逻辑复制(复制和删除slots),默认是noreplication。
| BYPASSRLS | NOBYPASSRLS :安全策略RLS权限,默认nobypassrls。
| CONNECTION LIMIT connlimit :限制用户并发数,默认-1,不限制。正常连接会受限制,后台连接和prepared事务不受限制。
| [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL :设置密码,密码仅用于有login属性的用户,不使用密码身份验证,则可以省略此选项。可以选择将空密码显式写为PASSWORD NULL。
加密方法由配置参数password_encryption确定,密码始终以加密方式存储在系统目录中。
| VALID UNTIL 'timestamp' :密码有效期时间,不设置则用不失效。
| IN ROLE role_name [, ...] :新角色将立即添加为新成员。
| IN GROUP role_name [, ...] :同上
| ROLE role_name [, ...] :ROLE子句列出一个或多个现有角色,这些角色自动添加为新角色的成员。 (这实际上使新角色成为“组”)。
| ADMIN role_name [, ...] :与ROLE类似,但命名角色将添加到新角色WITH ADMIN OPTION,使他们有权将此角色的成员资格授予其他人。
| USER role_name [, ...] :同上
| SYSID uid :被忽略,但是为向后兼容性而存在。
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { USAGE | SELECT | UPDATE }
[, ...] | ALL [ PRIVILEGES ] }
ON { SEQUENCE sequence_name [, ...]
| ALL SEQUENCES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
ON DATABASE database_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN domain_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { { FUNCTION | PROCEDURE | ROUTINE } routine_name [ ( [ [ argmode ] [ arg_name ] arg_type [, ...] ] ) ] [, ...]
| ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON LANGUAGE lang_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
ON LARGE OBJECT loid [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
ON SCHEMA schema_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE tablespace_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON TYPE type_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
其中role_specification可以是:
[ GROUP ] role_name
| PUBLIC
| CURRENT_USER
| SESSION_USER
GRANT role_name [, ...] TO role_name [, ...] [ WITH ADMIN OPTION ]
2.3 权限示例
创建 database
登录u2进行创建数据库d1,目前用户u2没有创建的权限会失败 psql postgres://u2@192.168.0.126:8888/postgres
\c
SELECT session_user, current_user;
create database d1;
使用超级用户授权 u2 可以在数据库中创建 schema
alter user u2 createdb;
授权后切换到 u2 账户下再次进行创建
create database d1;
创建 schema
用户 u2进 入到不属于自己的数据库 进行创建schema,会失败 先用超级用户创建个数据库 d2,用户 u2 在 d2 数据库中进行创建 schema(s1);
使用超级用户授权用户 u2 可以在数据库 d2 中创建 schema(s1);
grant create on database d2 to u2;
授权之后再次进行创建 s1;
单表/所有表授权
使用 u1 账户进行登录 psql postgres://u1@192.168.0.126:8888/vito 由于没有表的权限,进行的增删改查都会失败
超级用户进行赋予权限,因为只为 t1 表的权限赋予 u1,所以表 t2,t3 依然失败
grant select,insert,update,delete on t1 to u1;
#GRANT
向所有表赋予权限,表 t2,t3 都获得了权限
grant select,insert,update,delete on all tables in schema public to u1;
列授权
使用超级用户创建 t4 表,并且回收 t4 表中的 insert 权限,为 t4 表中的 id 与 name 赋予权限,age 字段是没有权限的
create table t4(id int, name varchar(10), age int);
insert into t4 values (1,'zhangsan',18),(2,'lisi',13),(3,'wangwu',16);
# 收回t4表中的insert权限
REVOKE insert on public.t4 from u1;
# 赋予t4列id和name的insert权限
grant insert (id,name) on public.t4 to u1;
insert into t4 values (4,'liuliu');
#没有给插入的age列赋予权限,失败
insert into t4 values (5,'shibai',19);
非超级用户不能删除非自己Owner的database,schema,table
用户 u1 在数据库 vito 中删除属于用户 abc 的表 t1,这是失败的
使用 u1 用户删除表 t1,需要更改表 t1 的 owner
ALTER table t1 OWNER TO u1;
3 数据库高可靠性、备份恢复
预置条件:创建一个 rbr 集群
3.1 kill 掉存储节点的主,其被自动拉起。
3.1.1. 元数据下查询存储节点的主: 根据 member_state 为 source,得知 192.168.0.132 51401 即为主。
3.1.2. 在 132 机器上 ps 查看相关的进程信息:
3.1.3. 然后 kill 掉其进程:
3.1.4. 一分钟左右后,再 ps 检查其进程: 发现其被自动拉起。
3.1.5. 连接 mysql,检查 mysql 的主备关系:
3.1.6. 在 192.168.0.132 51401 主上,show slave hosts;
在 192.168.0.132 51403 备上, show slave status;
另一个备机 192.168.0.132 51405 上, show slave status; 主备关系正常。
3.2 连续 3 次 kill 掉存储节点的主,触发其主备切换。
3.2.1. 元数据下查询存储节点的主: 根据member_state为source,得知 192.168.0.132 51401 即为主。
3.2.2. 在 132 机器上 ps 查看相关的进程信息:
3.2.3. 然后 kill 掉其进程:
3.2.4. 一分钟左右后,再 ps 检查其进程: 发现其被自动拉起。
3.2.5. 连续 3 次重复步骤 3,kill 掉存储节点的主,触发了存储节点的主备切换
检查 clustermgr 的日志:
且在元数据表的 rbr_consfailover 中看到这样的信息:
3.3 kill 掉元数据集群的主,其重新选举主,且原主会被自动拉起
3.3.1. 元数据下查询存储节点的主 根据 MEMBER_ROLE 为 PRIMARY,得知 192.168.0.140 59301 即为主。
3.3.2. 在 140 机器上 ps 查看相关的进程信息:
3.3.3. 然后 kill 掉其进程:
3.3.4. 此时在元数据表中检查元数据集群的信息:
发现 192.168.0.132 59301 成为新的元数据集群的主,且 192.168.0.140 59301不在表中。
检查 clustermgr 的日志,有如下信息:
3.3.5. 一分钟左右后,再到 192.168.0.140 上 ps 检查其进程 192.168.0.140 59301被重新拉起
3.3.6. 再次到元数据表中检查元数据集群的信息: 192.168.0.140 59301 加入到元数据集群中,且降为 SECONDARY。
3.4 kill 掉计算节点,其被自动拉起。
3.4.1. 元数据下查询计算节点的信息: 得知 192.168.0.132 51701 即为计算节点。
3.4.2. 在 132 机器上 ps 查看相关的进程信息:
3.4.3. 然后 kill 掉其进程:
3.4.4. 一分钟左右后,再 ps 检查其进程: 发现其被自动拉起。
3.4.5. 连接 pg,检查数据是否能正常读写: pg 读写正常。
3.5 kill 掉 clustermgr 的主,其会进行主备切换。
3.5.1. 元数据下查询 clustermgr 的主: 根据 member_state 为 source,得知 192.168.0.140 59011 即为主。
3.5.2. 在 140 机器上 ps 查看 clustermgr 的进程信息:
3.5.3. 进入 ~kunlun-cluster-manager-1.0.1/bin 下,停掉 clustermgr:
3.5.4. 再到元数据表中检查 clustermgr 的主备信息:
3.5.5. 发现 clustermgr 的主由原来的 192.168.0.140 59011 切换到 192.168.0.129 59011 上去了。
3.5.6. 再到 192.168.0.140 59011 上启动 clustermgr,clustermgr 启动成功: 但是 clustermgr 的主仍然是 192.168.0.129 59011。
3.6 备份恢复
3.6.1. 创建 rbr 集群:
此集群作为源集群; 集群创建成功后,连接计算节点,如: psql postgres://abc:abc@192.168.0.129:51701/postgres 建立 t1111 表并写入数据。
3.6.2. 发起备份操作:(需保证 hdfs server 已启动)
hdfs 下记录恢复的时间,如:2022-08-23 13:52
3.6.3. 创建另一个集群: 规格需与步骤1中的集群一致,参考步骤1,作为目标集群。
3.6.4. 发起恢复操作:
3.6.5. 恢复成功后,链接步骤 3 中集群的计算节点,如: psql postgres://abc:abc@192.168.0.129:59701/postgres t1111表会同步到目标集群中。