mongodb内置角色

mongodb内置角色(Built-In Roles)
内置角色是MongoDB预定义的角色,操作的资源是在DB级别上。MongoDB拥有一个SuperUser的角色:root,拥有最大权限,能够在系统的所有资源上执行任意操作。

数据库用户角色(Database User Roles):
read:授予User只读数据的权限
readWrite:授予User读写数据的权限

数据库管理角色(Database Administration Roles):
dbAdmin:在当前dB中执行管理操作
dbOwner:在当前DB中执行任意操作
userAdmin:在当前DB中管理User

备份和还原角色(Backup and Restoration Roles):
backup
restore

跨库角色(All-Database Roles):
readAnyDatabase:授予在所有数据库上读取数据的权限
readWriteAnyDatabase:授予在所有数据库上读写数据的权限
userAdminAnyDatabase:授予在所有数据库上管理User的权限
dbAdminAnyDatabase:授予管理所有数据库的权限

集群管理角色(Cluster Administration Roles):
clusterAdmin:授予管理集群的最高权限
clusterManager:授予管理和监控集群的权限,A user with this role can access the config and local databases, which are used in sharding and replication, respectively.
clusterMonitor:授予监控集群的权限,对监控工具具有readonly的权限
hostManager:管理Server


RestTemplate 文件下载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/*下载签字文件
* inUrl - 请求文件地址:http://blog.hachuizi.com/aaa.docx
* outUrl - 本地缓存文件地址: /home/filePath/aaa.docx
*/

public static String restPdfFile(String inUrl, String outUrl) throws Exception{
    RestTemplate restTemplate = new RestTemplate();
    HttpHeaders headers = new HttpHeaders();
    HttpEntity<Resource> httpEntity = new HttpEntity<Resource>(headers);
    ResponseEntity<byte[]> response = restTemplate.exchange(inUrl, HttpMethod.GET,
            httpEntity, byte[].class);
    System.out.println("状态码"+response.getStatusCodeValue());
    System.out.println("返回信息"+response.getHeaders().getContentType());
    System.out.println("返回信息"+response.getHeaders().getContentType().getSubtype());
    try {
        File file = new File(outUrl);
        FileOutputStream fos = new FileOutputStream(file);
        fos.write(response.getBody());
        fos.flush();
        fos.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return outUrl;
}




MySQL 查询字段类型注释等信息

table_schema :库名
table_name :表名
表名及表注释

1
SELECT TABLE_NAME,TABLE_COMMENT FROM information_schema.TABLES WHERE table_schema='table_schema';

所有:

1
2
3
select *
from information_schema.columns
where table_schema ='databaseName' and table_name = 'tableName';

主要信息:

1
2
3
4
5
6
7
8
select COLUMN_NAME,COLUMN_TYPE,
CASE WHEN IS_NULLABLE = 'NO'
THEN ('是')
ELSE ('否')
END,
COLUMN_DEFAULT,COLUMN_COMMENT
from information_schema.columns
where table_schema ='databaseName' and table_name = 'tableName';

win/linux 下查看端口占用

win下查看端口:
cmd命令

根据端口查看占用进程/PID: netstat -aon|findstr 8080

根据PID查看占用服务: tasklist|findstr 10612

打开任务管理器,找到对应的进程,结束进程
根据服务名关闭进程(尽量不用): taskkill /f /t /im java.exe

linux下查看端口:
根据端口查看占用进程/PID: netstat -anp |grep 8005

查看java相关进程: ps -ef | grep java
停止相关进程(PID=第二列数字): kill -9 [PID]


linux ps查询进程,出现两个进程

1
2
3
4
5
6
7
[root@ADM01B ~]# ps -ef|grep iesmgr
root      5929  5321  0 09:38 pts/7    00:00:00 grep iesmgr
root      9798     1  0 Jun28 ?        00:00:05 iesmgr
[root@ADM01B ~]# kill -9 5929
-bash: kill: (5929) - 没有那个进程
[root@ADM01B ~]# kill -9 9798
[root@ADM01B ~]#

当我在linux系统下查询某个程序的进程时出现两个进程,进程号分别为5929和9798
我想把该进程杀掉 kill -9 5929,但是显示没有那个进程,然后我又杀掉9798这个进程kill -9 9798,成功杀掉了。

对此现象疑惑不解。为啥有这个进程,kill的时候有显示没有。
最后通过查资料知道,ps -ef|grep iesmgr命令其实是分两步完成的。第一步执行ps -ef查询所有进程,第二步执行grep iesmgr过滤出进程中带有iesmgr关键字的进程。

这样就出现了一个问题:其中grep iesmgr这个命令本身执行的时候也是个进程,并且也带有关键字iesmgr。所以也会显示出来,这其实是grep进程,而不是iesmgr进程。grep进程在命令执行完之后就结束了,所以kill该进程的时候显示-bash: kill: (5929) – 没有那个进程 。

如果不想显示grep进程怎么办,可以使用下面的命令:
# ps -ef|grep iesmgr |grep -v grep

grep的-v参数是取反,也就是说grep -v grep是过滤掉那些带grep关键字进程,即把grep iesmgr这个进程过滤掉。

补充:

ps命令
ps [选项]
下面对命令选项进行说明:
-e 显示所有进程。
-f 全格式。
-h 不显示标题。
-l 长格式。
-w 宽输出。
a 显示终端上的所有进程,包括其他用户的进程。
r 只显示正在运行的进程。
u  以用户为主的格式来显示程序状况。
x 显示所有程序,不以终端机来区分。

grep命令
grep [options]
[options]主要参数:
-c:只输出匹配行的计数。
-I:不区分大 小写(只适用于单字符)。
-h:查询多文件时不显示文件名。
-l:查询多文件时只输出包含匹配字符的文件名。
-n:显示匹配行及 行号。
-s:不显示不存在或无匹配文本的错误信息。
-v:显示不包含匹配文本的所有行。


ˆ Back To Top