1.数据库的容量测试
-
相干性能测试举荐应用sysbench,详情可参考:https://github.com/akopytov/s…
- 相干的sysbench选项能够参考:https://github.com/akopytov/s…
- 容量测试能够在装置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
2.写入性能测试case
- 以后sysbench对于写入性能相干的测试case有 read_write、update_index、update_non_index、write_only、insert
- 命令能够参考
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
3.查问性能 ,多表 join
-
以后sysbench对于查问性能相干的测试case有 read_only、point_select
- 相干命令能够参考第二步
-
以后版本sysbench并不反对多表join,因而咱们须要自定义lua测试脚本
- 以下是简略范例,能够依据需要自行批改
- vim oltp_mutli_join.lua
require("oltp_common")
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脚本
4.数据库的安全性
4.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;
4.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 ]
4.3 权限示例
创立database
登录u2进行创立数据库d1,目前用户u2没有创立的权限会失败
psql postgres://[email protected]: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://[email protected]: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;
5.数据库高可靠性、备份复原
预置条件:创立一个rbr集群
5.1 kill 掉存储节点的主,其被主动拉起。
5.1.1. 元数据下查问存储节点的主:
依据member_state为source,得悉 192.168.0.132 51401 即为主。
5.1.2. 在132机器上ps 查看相干的过程信息:
5.1.3. 而后kill掉其过程:
5.1.4. 一分钟左右后,再ps查看其过程:
发现其被主动拉起。
5.1.5. 连贯mysql,查看mysql的主备关系:
5.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;
主备关系失常。
5.2 间断3次kill 掉存储节点的主,触发其主备切换。
5.2.1. 元数据下查问存储节点的主:
依据member_state为source,得悉 192.168.0.132 51401 即为主。
5.2.2. 在132机器上ps 查看相干的过程信息:
5.2.3. 而后kill掉其过程:
5.2.4. 一分钟左右后,再ps查看其过程:
发现其被主动拉起。
5.2.5. 间断3次反复步骤3,kill掉存储节点的主,触发了存储节点的主备切换
查看clustermgr的日志:
且在元数据表的rbr_consfailover中看到这样的信息:
5.3 kill 掉元数据集群的主,其从新选举主,且原主会被主动拉起
5.3.1. 元数据下查问存储节点的主
依据MEMBER_ROLE为PRIMARY,得悉 192.168.0.140 59301 即为主。
5.3.2. 在140机器上ps 查看相干的过程信息:
5.3.3. 而后kill掉其过程:
5.3.4. 此时在元数据表中查看元数据集群的信息:
发现 192.168.0.132 59301成为新的元数据集群的主,且 192.168.0.140 59301不在表中。
查看clustermgr的日志,有如下信息:
5.3.5. 一分钟左右后,再到192.168.0.140上ps查看其过程
192.168.0.140 59301被从新拉起
5.3.6. 再次到元数据表中查看元数据集群的信息:
192.168.0.140 59301退出到元数据集群中,且降为SECONDARY。
5.4 kill 掉计算节点,其被主动拉起。
5.4.1. 元数据下查问计算节点的信息:
得悉 192.168.0.132 51701 即为计算节点。
5.4.2. 在132机器上ps 查看相干的过程信息:
5.4.3. 而后kill掉其过程:
5.4.4. 一分钟左右后,再ps查看其过程:
发现其被主动拉起。
5.4.5. 连贯pg,检查数据是否能失常读写:
pg读写失常。
5.5 kill 掉clustermgr的主,其会进行主备切换。
5.5.1. 元数据下查问clustermgr的主:
依据member_state为source,得悉 192.168.0.140 59011 即为主。
5.5.2. 在140机器上ps查看clustermgr的过程信息:
5.5.3. 进入~kunlun-cluster-manager-1.0.1/bin下,停掉clustermgr:
5.5.4. 再到元数据表中查看clustermgr的主备信息:
5.5.5. 发现clustermgr的主由原来的 192.168.0.140 59011切换到 192.168.0.129 59011下来了。
5.5.6. 再到 192.168.0.140 59011上启动clustermgr,clustermgr启动胜利:
然而clustermgr的主依然是 192.168.0.129 59011。
5.6 备份复原
5.6.1. 创立rbr集群:
此集群作为源集群;
集群创立胜利后,连贯计算节点,如:
psql postgres://abc:[email protected]:51701/postgres
建设t1111表并写入数据。
5.6.2. 发动备份操作:(需保障hdfs server已启动)
hdfs下记录复原的工夫,如:2022-08-23 13:52
5.6.3. 创立另一个集群:
规格需与步骤1中的集群统一,参考步骤1,作为指标集群。
5.6.4. 发动复原操作:
5.6.5. 复原胜利后,链接步骤3中集群的计算节点,如:
psql postgres://abc:[email protected]:59701/postgres
t1111表会同步到指标集群中。
点击浏览原文
举荐浏览
KunlunBase架构介绍
KunlunBase技术劣势介绍
KunlunBase技术特点介绍
PostgreSQL vs MySQL TPC-H 测试
Kunlun-Storage vs PostgreSQL OLTP 测试
END
昆仑数据库是一个HTAP NewSQL分布式数据库管理系统,能够满足用户对海量关系数据的存储管理和利用的全方位需要。
利用开发者和DBA的应用昆仑数据库的体验与单机MySQL和单机PostgreSQL简直完全相同,因为首先昆仑数据库反对PostgreSQL和MySQL双协定,反对规范SQL:2011的 DML 语法和性能以及PostgreSQL和MySQL对规范 SQL的扩大。同时,昆仑数据库集群反对程度弹性扩容,数据主动拆分,分布式事务处理和分布式查询处理,强壮的容错容灾能力,欠缺直观的监测剖析告警能力,集群数据备份和复原等 罕用的DBA 数据管理和操作。所有这些性能无需任何利用零碎侧的编码工作,也无需DBA人工染指,不停服不影响业务失常运行。
昆仑数据库具备全面的OLAP 数据分析能力,通过了TPC-H和TPC-DS规范测试集,能够实时剖析最新的业务数据,帮忙用户发掘出数据的价值。昆仑数据库反对私有云和公有云环境的部署,能够与docker,k8s等云基础设施无缝合作,能够轻松搭建云数据库服务。
请拜访 http://www.kunlunbase.com/ 获取更多信息并且下载昆仑数据库软件、文档和材料。
KunlunBase我的项目已开源
【GitHub:】
https://github.com/zettadb
【Gitee:】
https://gitee.com/zettadb
发表回复