月份：2018年12月

mongodb内置角色

Posted on by yangxing

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 文件下载

Posted on by yangxing
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 查询字段类型注释等信息

Posted on by yangxing

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 下查看端口占用

Posted on by yangxing

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查询进程,出现两个进程

Posted on by yangxing
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