MySQL命令行参数整理

一、MySQL命令行参数:

Usage: mysql [OPTIONS] [database]   //命令方式  
 -?, --help          //显示帮助信息并退出  
 -I, --help          //显示帮助信息并退出  
 --auto-rehash       //自动补全功能,就像linux里面,按Tab键出提示差不多,下面有例子  
  
 -A, --no-auto-rehash  //默认状态是没有自动补全功能的。-A就是不要自动补全功能  
 -B, --batch         //ysql不使用历史文件,禁用交互  
 (Enables --silent)  
 --character-sets-dir=name   //字体集的安装目录                      
 --default-character-set=name    //设置数据库的默认字符集  
 -C, --compress      //在客户端和服务器端传递信息时使用压缩  
 -#, --debug[=#]     //bug调用功能  
 -D, --database=name //使用哪个数据库  
 --delimiter=name    //mysql默认命令结束符是分号,下面有例子  
 -e, --execute=name  //执行mysql的sql语句  常用于配合shell脚本
 -E, --vertical      //垂直打印查询输出  
 -f, --force         //如果有错误跳过去,继续执行下面的  
 -G, --named-commands  
 /*Enable named commands. Named commands mean this program's 
 internal commands; see mysql> help . When enabled, the 
 named commands can be used from any line of the query, 
 otherwise only from the first line, before an enter. 
 Disable with --disable-named-commands. This option is 
 disabled by default.*/  
 -g, --no-named-commands  
 /*Named commands are disabled. Use \* form only, or use 
 named commands only in the beginning of a line ending 
 with a semicolon (;) Since version 10.9 the client now 
 starts with this option ENABLED by default! Disable with 
 '-G'. Long format commands still work from the first 
 line. WARNING: option deprecated; use 
 --disable-named-commands instead.*/  
 -i, --ignore-spaces //忽视函数名后面的空格.  
 --local-infile      //启动/禁用 LOAD DATA LOCAL INFILE.  
 -b, --no-beep       //sql错误时,禁止嘟的一声  
 -h, --host=name     //设置连接的服务器名或者Ip  
 -H, --html          //以html的方式输出  
 -X, --xml           //以xml的方式输出  
 --line-numbers      //显示错误的行号  
 -L, --skip-line-numbers  //忽略错误的行号  
 -n, --unbuffered    //每执行一次sql后,刷新缓存  
 --column-names      //查寻时显示列信息,默认是加上的  
 -N, --skip-column-names  //不显示列信息  
 -O, --set-variable=name  //设置变量用法是--set-variable=var_name=var_value  
 --sigint-ignore     //忽视SIGINT符号(登录退出时Control-C的结果)  
 -o, --one-database  //忽视除了为命令行中命名的默认数据库的语句。可以帮跳过日志中的其它数据库的更新。  
 --pager[=name]      //使用分页器来显示查询输出,这个要在linux可以用more,less等。  
 --no-pager          //不使用分页器来显示查询输出。  
 -p, --password[=name] //输入密码  
 -P, --port=#        //设置端口  
 --prompt=name       //设置mysql提示符  
 --protocol=name     //使用什么协议  
 -q, --quick         //不缓存查询的结果,顺序打印每一行。如果输出被挂起,服务器会慢下来,mysql不使用历史文件。  
 -r, --raw           //写列的值而不转义转换。通常结合--batch选项使用。  
 --reconnect         //如果与服务器之间的连接断开,自动尝试重新连接。禁止重新连接,使用--disable-reconnect。  
 -s, --silent        //一行一行输出,中间有tab分隔  
 -S, --socket=name   //连接服务器的sockey文件  
 --ssl               //激活ssl连接,不激活--skip-ssl  
 --ssl-ca=name       //CA证书  
 --ssl-capath=name   //CA路径  
 --ssl-cert=name     //X509 证书  
 --ssl-cipher=name   //SSL cipher to use (implies --ssl).  
 --ssl-key=name      //X509 密钥名  
 --ssl-verify-server-cert //连接时审核服务器的证书  
 -t, --table         //以表格的形势输出  
 --tee=name          //将输出拷贝添加到给定的文件中,禁时用--disable-tee  
 --no-tee            //根--disable-tee功能一样  
 -u, --user=name     //用户名  
 -U, --safe-updates  //Only allow UPDATE and DELETE that uses keys.  
 -U, --i-am-a-dummy  //Synonym for option --safe-updates, -U.  
 -v, --verbose       //输出mysql执行的语句  
 -V, --version       //版本信息  
 -w, --wait          //服务器down后,等待到重起的时间  
 --connect_timeout=# //连接前要等待的时间  
 --max_allowed_packet=# //服务器接收/发送包的最大长度  
 --net_buffer_length=# //TCP / IP和套接字通信缓冲区大小。  
 --select_limit=#    //使用--safe-updates时SELECT语句的自动限制  
 --max_join_size=#   //使用--safe-updates时联接中的行的自动限制  
 --secure-auth       //拒绝用(pre-4.1.1)的方式连接到数据库  
 --server-arg=name   //Send embedded server this as a parameter.  
 --show-warnings     //显示警告  

提取jks证书配置Nginx使其支持https

证书配置在nginx上,对外提供https服务,内部和tomcat做反向代理走http,提取jks证书步骤如下:
提取jks证书(keytool命令安装jdk以后就默认安装了)
查看jks文件中的entry

keytool -list -keystore server.jks

查看是否有entries,如果有下个命令需要加 -srcalias 参数指定entry

转换jks文件为p12

keytool -importkeystore -srckeystore server.jks -destkeystore server.p12 -deststoretype PKCS12

查看新格式(pkcs12)证书库

keytool -deststoretype PKCS12 -keystore server.p12 -list

使用openssl提取证书并合并

openssl pkcs12 -in server.p12 -nokeys -clcerts -out server-ssl.crt
openssl pkcs12 -in server.p12 -nokeys -cacerts -out gs_intermediate_ca.crt

server-ssl.crt是SSL证书,gs_intermediate_ca.crt是中级证书,合并到一起才是nginx所需要的证书

cat server-ssl.crt gs_intermediate_ca.crt > server.crt

提取私钥及免密码

openssl pkcs12 -nocerts -nodes -in server.p12 -out server.key

避免重启是总是要输入私有key的密码

openssl rsa -in server.key -out server.key.unsecure

配置nginx


worker_processes  8;

error_log  logs/error.log  notice;

pid        logs/nginx.pid;


events {
    worker_connections  65535;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout 300;
    proxy_read_timeout 300;
    add_header Access-Control-Allow-Origin *;
    client_max_body_size    1000m;
    client_header_buffer_size 100m;
    large_client_header_buffers 4 102400k;
    set_real_ip_from  10.201.21.199;
    real_ip_header    X-Forwarded-For;
    real_ip_recursive on;
    ssl_certificate   /etc/pki/cn/server.crt;
    ssl_certificate_key /etc/pki/cn/server.key;
    include gzip.conf;
    include apmweb_upstream.conf;


    server {
        listen       80;
        listen       443 ssl;
        server_name  localhost;

        ssl_certificate   /etc/pki/cn/server.crt;
        ssl_certificate_key /etc/pki/cn/server.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5";
        ssl_prefer_server_ciphers on;
        ssl_session_timeout 1d;
        ssl_stapling on;
        ssl_stapling_verify on;
        add_header Strict-Transport-Security max-age=15768000;

        #proxy_redirect http:// $scheme://;
        proxy_redirect ~^http://inamp.xxx.com/(.*)$  https://inamp.xxx.com/$1;

        port_in_redirect on;
        proxy_set_header Host $host:$server_port;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;

        location / {
            root   /data/apm_static;
            index  index.html index.htm;
        }

       location ~*  ^/$ {
        rewrite ^/$ http://inamp.xxx.com/enrolment_web/enrolment/index.htm ;
       }

        include apmweb_tomcat.conf;

        error_page  404              /404.html;
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }


    }

}

apmweb_tomcat.conf内容

           location ~* ^/management_service.*$ {
           include deny.conf;

           proxy_pass http://apmserapp6300;
           include proxy.conf;

           error_log  logs/apm_management_service_error.log error;
           access_log  logs/apm_management_service_access.log  main;
       

apmweb_upstream.conf内容

    upstream apmwebapp6300 {
      server 10.101.1.160:6300 weight=1 max_fails=2 fail_timeout=10s;
      server 10.101.1.161:6300 weight=1 max_fails=2 fail_timeout=10s;
      server 10.101.1.162:6300 weight=1 max_fails=2 fail_timeout=10s;
    }
.......

gzip.conf

gzip on;
gzip_comp_level 2;
gzip_http_version 1.1;
gzip_proxied any;
gzip_min_length 1;
gzip_buffers 16 8k;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript application/jsp application/html application/htm;

Tomcat查看占用CPU过高的原因

应用服务器服务起来以后占用CPU一直很高,排查方法如下:
1、使用top命令查看使用CPU过高的进程的pid,按“shift+P”键按照cpu从高到低排列,按“shift+M”键按照内存用高到低排列。
2、根据pid定位占用cpu的线程,并按照占用从高到低排列

#此处的pid为15217
$ ps -mp 15254 -o THREAD,tid,time|sort -rn|head -10 
USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME
tomcat   99.9   -    - -         -      -     - 05:10:34
tomcat   99.8  19    - -         -      - 15820 05:10:05
tomcat    0.0  19    - poll_s    -      - 15921 00:00:00
tomcat    0.0  19    - poll_s    -      - 15917 00:00:00
tomcat    0.0  19    - poll_s    -      - 15257 00:00:05
tomcat    0.0  19    - futex_    -      - 15922 00:00:00
tomcat    0.0  19    - futex_    -      - 15920 00:00:00
tomcat    0.0  19    - futex_    -      - 15919 00:00:00
tomcat    0.0  19    - futex_    -      - 15918 00:00:00

3、将占用cpu高的线程id转换为16进制格式

printf "%x\n" 15820
3dcc

4、打印线程的堆栈信息

jstack 15254 | grep 3dcc -A 30

"Thread-2" prio=10 tid=0x00007fe7745cc800 nid=0x3dcc runnable [0x00007fe744c4a000]
   java.lang.Thread.State: RUNNABLE
        at com.yueworldframework.core.support.EventHelper$1.run(EventHelper.java:50)
        at java.lang.Thread.run(Thread.java:745)

"GC Daemon" daemon prio=10 tid=0x00007fe774347800 nid=0x3d04 in Object.wait() [0x00007fe7459dd000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000fd7b8530> (a sun.misc.GC$LatencyLock)
        at sun.misc.GC$Daemon.run(GC.java:117)
        - locked <0x00000000fd7b8530> (a sun.misc.GC$LatencyLock)

"Service Thread" daemon prio=10 tid=0x00007fe7740aa000 nid=0x3bdd runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007fe7740a7800 nid=0x3bdb waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007fe7740a4800 nid=0x3bd9 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007fe77409a800 nid=0x3bd8 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007fe774083800 nid=0x3bb9 in Object.wait() [0x00007fe746dec000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000fd7b0da0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
        - locked <0x00000000fd7b0da0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)

根据输出信息定位或将结果发给开发。

Nginx目录浏览功能autoindex设置

Nginx默认是不允许列出整个目录的。如需此功能,打开nginx.conf文件或你要启用目录浏览虚拟主机的配置文件,在server或location 段里添加上autoindex on;来启用目录流量,下面会分情况进行说明。

另外Nginx的目录流量有两个比较有用的参数,可以根据自己的需求添加:

autoindex_exact_size off;
默认为on,显示出文件的确切大小,单位是bytes。
改为off后,显示出文件的大概大小,单位是kB或者MB或者GB

autoindex_localtime on;
默认为off,显示的文件时间为GMT时间。
改为on后,显示的文件时间为文件的服务器时间

1、整个虚拟主机开启目录流量

在server段添加

location / {
autoindex on;
autoindex_localtime on; #之类的参数写这里
}

2、单独目录开启目录流量
2.1:直接二级目录开启目录流量

location /down {
autoindex on;
}

2.2:虚拟目录开启目录流量

location /tools {
alias /data/tools/;
autoindex on;
}

详细参照:http://nginx.org/en/docs/http/ngx_http_autoindex_module.html

dd创建测试文件

使用dd这个linux命令可以创建一定大小文件。

linux创建文件命令:dd命令
把指定的输入文件拷贝到指定的输出文件中,并且在拷贝的过程中可以进行格式转换。语法:
CODE:[Copy to clipboard]dd 〔选项〕
QUOTE:

if =输入文件(或设备名称)。
of =输出文件(或设备名称)。
ibs = bytes 一次读取bytes字节,即读入缓冲区的字节数。
skip = blocks 跳过读入缓冲区开头的ibs*blocks块。
obs = bytes 一次写入bytes字节,即写 入缓冲区的字节数。
bs = bytes 同时设置读/写缓冲区的字节数(等于设置obs和obs)。
cbs = bytes 一次转换bytes字节。
count = blocks 只拷贝输入的blocks块。
conv = ASCII 把EBCDIC码转换为ASCII码。
conv = ebcdic 把ASCII码转换为EBCDIC码。
conv = ibm 把ASCII码转换为alternate EBCDIC码。
conv = blick 把变动位转换成固定字符。
conv = ublock 把固定们转换成变动位
conv = ucase 把字母由小写变为大写。
conv = lcase 把字母由大写变为小写。
conv = notrunc 不截短输出文件。
conv = swab 交换每一对输入字节。
conv = noerror 出错时不停止处理。
conv = sync 把每个输入记录的大小都调到ibs的大小(用ibs填充)。
fdformat命令
低级格式化软盘。

创建一个2G的文件

dd if=/dev/zero  of=/tmp/test bs=1M count=2048

得到最恰当的block size
通过比较dd指令输出中所显示的命令执行时间,即可确定系统最佳的block size大小:

dd if=/dev/zero bs=1024 count=1000000 of=/root/1Gb.filedd if=/dev/zero bs=2048 count=500000 of=/root/1Gb.file
dd if=/dev/zero bs=4096 count=250000 of=/root/1Gb.file
dd if=/dev/zero bs=8192 count=125000 of=/root/1Gb.file

测试硬盘读写速度
通过两个命令输出的执行时间,可以计算出测试硬盘的读/写速度:

dd if=/root/1Gb.file bs=64k | dd of=/dev/null
dd if=/dev/zero of=/root/1Gb.file bs=1024 count=1000000

MySQL的max_allowed_packet参数说明

max_allowed_packet 定义的是所允许的单条sql语句的大小。
引用官方的说法: http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_allowed_packet

You must increase this value if you are using large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for max_allowed_packet is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.

Property    Value
Command-Line Format    --max-allowed-packet=#
System Variable    max_allowed_packet
Scope    Global, Session
Dynamic    Yes
Type    integer
Default Value    4194304
Minimum Value    1024
Maximum Value    1073741824

解释:
该值的类型为integer,允许的最大值为1G (理论上4个字节的表达能力的上限是4G,也或许协议实现上硬编码了吧),修改
该变量的默认值为4MB,一般来讲是够的,如果存储大的BLOB列,可能不够,需要修改该配置
该值总是1KB的整数倍,最小值为1KB;修改的值应该是1024的整数倍,如果不是整数倍,则会按照小于该值的最接近的那个1024的整数倍进行截断处理,并产生1个warning;(注意: 如果设置的值小于1024,则自动调整为1024)如下:

将max_allowed_packet 设置为比 net_buffer_length 小的意义不大,所以,这里同样会出现一个warning,只是不会强制将max_allowed_packet修改为大于等于net_buffer_length的
比较专业的设置该值的方法为:
set global max_allowed_packet=102410241024;
session的max_allowed_packet是不允许修改的,修改了全局配置对当前session也不会生效的,只有重新连接才能看到变化,一般设置为1024M即可;

用mysqlslap对MySQL进行压力测试

MySQL从5.1.4版开始带有一个压力测试工具mysqlslap,通过模拟多个并发客户端访问mysql来执行测试。

[root@test-db data]# mysqlslap -a --concurrency=10000 --number-of-queries 10000 --iterations=10 --engine=innodb –debug-info -uroot -pyueworldtest
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
Benchmark
        Running for engine innodb
        Average number of seconds to run all queries: 6.451 seconds
        Minimum number of seconds to run all queries: 1.963 seconds
        Maximum number of seconds to run all queries: 24.031 seconds
        Number of clients running queries: 10000
        Average number of queries per client: 1

参数说明:

–auto-generate-sql, -a
自动生成测试表和数据
–auto-generate-sql-load-type=type
测试语句的类型。取值包括:read,key,write,update和mixed(默认)。
–number-char-cols=N, -x N
自动生成的测试表中包含多少个字符类型的列,默认1
–number-int-cols=N, -y N
自动生成的测试表中包含多少个数字类型的列,默认1
–number-of-queries=N
总的测试查询次数(并发客户数×每客户查询次数)
–query=name,-q
使用自定义脚本执行测试,例如可以调用自定义的一个存储过程或者sql语句来执行测试。
–create-schema
测试的schema,MySQL中schema也就是database
–commint=N
多少条DML后提交一次
–compress, -C
如果服务器和客户端支持都压缩,则压缩信息传递
–concurrency=N, -c N
并发量,也就是模拟多少个客户端同时执行select。可指定多个值,以逗号或者–delimiter参数指定的值做为分隔符
–engine=engine_name, -e engine_name
创建测试表所使用的存储引擎,可指定多个
–iterations=N, -i N
测试执行的迭代次数
–detach=N
执行N条语句后断开重连
–debug-info, -T
打印内存和CPU的信息
–only-print
只打印测试语句而不实际执行

iostat命令参数说明

Linux系统中的 iostat是I/O statistics(输入/输出统计)的缩写,iostat工具将对系统的磁盘操作活动进行监视。它的特点是汇报磁盘活动统计情况,同时也会汇报出CPU使用情况。同vmstat一样,iostat也有一个弱点,就是它不能对某个进程进行深入分析,仅对系统的整体情况进行分析。iostat属于sysstat软件包。
用yum install sysstat 直接安装。

1.命令格式:
iostat[参数][时间][次数]

2.命令功能:
通过iostat方便查看CPU、网卡、tty设备、磁盘、CD-ROM 等等设备的活动情况,负载信息。

3.命令参数:

-C 显示CPU使用情况
-d 显示磁盘使用情况
-k 以 KB 为单位显示
-m 以 M 为单位显示
-N 显示磁盘阵列(LVM) 信息
-n 显示NFS 使用情况
-p[磁盘] 显示磁盘和分区的情况
-t 显示终端和CPU的信息
-x 显示详细信息
-V 显示版本信息

[root@huafadb1 ~]# iostat 1
Linux 2.6.32-642.el6.x86_64 (huafadb1) 05/14/2018 x86_64 (64 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

       0.01    0.00    0.01    0.00    0.00   99.98

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.44 1.42 5.86 376234 1550788
dm-0 0.80 1.30 5.86 343586 1550704
dm-1 0.00 0.01 0.00 2600 0
up-1 2.93 0.74 41.03 195418 10859128
sdb 5.86 1.51 81.92 399706 21683632
up-3 2.93 0.77 40.90 204288 10824504
dm-2 0.00 0.01 0.00 3298 24

avg-cpu: %user %nice %system %iowait %steal %idle

       0.02    0.00    0.03    0.02    0.00   99.94
参数说明:

rrqms:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge)
wrqm/s:每秒这个设备相关的写入请求有多少被Merge了。
rsec/s:The number of sectors read from the device per second.
wsec/s:The number of sectors written to the device per second.
rKB/s:The number of kilobytes read from the device per second.
wKB/s:The number of kilobytes written to the device per second.
avgrq-sz:平均请求扇区的大小,The average size (in sectors) of the requests that were issued to the device.
avgqu-sz:是平均请求队列的长度。毫无疑问,队列长度越短越好,The average queue length of the requests that were issued to the device.
await:每一个IO请求的处理的平均时间(单位是微秒毫秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了。
这个时间包括了队列时间和服务时间,也就是说,一般情况下,await大于svctm,它们的差值越小,则说明队列时间越短,反之差值越大,队列时间越长,说明系统出了问题。
svctm:表示平均每次设备I/O操作的服务时间(以毫秒为单位)。如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好。
如果await的值远高于svctm的值,则表示I/O队列等待太长,系统上运行的应用程序将变慢。
%util: 在统计时间内所有处理IO时间,除以总共统计时间。例如,如果统计间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util = 0.8/1 = 80%,
所以该参数暗示了设备的繁忙程度,一般地,如果该参数是100%表示磁盘设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。

使用FIO测试云主机IOPS及写入读取速度

先安装fio工具:

yum install fio -y

fio参数说明:

filename=/dev/emcpowerb 支持文件系统或者裸设备,-filename=/dev/sda2或-filename=/dev/sdb
direct=1                 测试过程绕过机器自带的buffer,使测试结果更真实
rw=randwread             测试随机读的I/O
rw=randwrite             测试随机写的I/O
rw=randrw                测试随机混合写和读的I/O
rw=read                  测试顺序读的I/O
rw=write                 测试顺序写的I/O
rw=rw                    测试顺序混合写和读的I/O
bs=4k                    单次io的块文件大小为4k
bsrange=512-2048         同上,提定数据块的大小范围
size=5g                  本次的测试文件大小为5g,以每次4k的io进行测试
numjobs=30               本次的测试线程为30
runtime=1000             测试时间为1000秒,如果不写则一直将5g文件分4k每次写完为止
ioengine=psync           io引擎使用pync方式,如果要使用libaio引擎,需要yum install libaio-devel包
rwmixwrite=30            在混合读写的模式下,写占30%
group_reporting          关于显示结果的,汇总每个进程的信息
此外
lockmem=1g               只使用1g内存进行测试
zero_buffers             用0初始化系统buffer
nrfiles=8                每个进程生成文件的数量

测试命令(创建100G容量大小的文件)

fio -direct=1 -iodepth=128 -rw=write -ioengine=libaio -bs=4k -size=100G -numjobs=1 -runtime=1000 -group_reporting -name=test -filename=/data/test111
运行结果:
test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.0.13
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 102400MB)
Jobs: 1 (f=1): [W] [100.0% done] [0K/129.3M/0K /s] [0 /33.1K/0  iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=594: Mon May 14 10:27:54 2018
  write: io=102400MB, bw=129763KB/s, iops=32440 , runt=808070msec
    slat (usec): min=0 , max=80322 , avg=12.06, stdev=24.73
    clat (usec): min=222 , max=254410 , avg=3932.47, stdev=5007.90
     lat (usec): min=622 , max=254416 , avg=3944.82, stdev=5007.26
    clat percentiles (usec):
     |  1.00th=[ 1288],  5.00th=[ 1560], 10.00th=[ 1736], 20.00th=[ 1992],
     | 30.00th=[ 2224], 40.00th=[ 2480], 50.00th=[ 2736], 60.00th=[ 3088],
     | 70.00th=[ 3536], 80.00th=[ 4320], 90.00th=[ 6624], 95.00th=[ 9664],
     | 99.00th=[21120], 99.50th=[37632], 99.90th=[54528], 99.95th=[78336],
     | 99.99th=[177152]
    bw (KB/s)  : min=20720, max=215424, per=100.00%, avg=129801.50, stdev=19878.75
    lat (usec) : 250=0.01%, 750=0.01%, 1000=0.09%
    lat (msec) : 2=20.47%, 4=56.01%, 10=18.78%, 20=3.20%, 50=1.33%
    lat (msec) : 100=0.09%, 250=0.02%, 500=0.01%
  cpu          : usr=4.88%, sys=36.64%, ctx=9409837, majf=0, minf=23
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued    : total=r=0/w=26214400/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=102400MB, aggrb=129763KB/s, minb=129763KB/s, maxb=129763KB/s, mint=808070msec, maxt=808070msec

Disk stats (read/write):
  vdb: ios=0/26203032, merge=0/3962, ticks=0/90681446, in_queue=90672667, util=100.00%

100%随机,100%读,4K

[root@test-db data]# fio -filename=/dev/vdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=4k -size=100G -numjobs=50 -runtime=180 -group_reporting -name=rand_100read_4k
运行结果:
rand_100read_4k: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
...
rand_100read_4k: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.0.13
Starting 50 threads
Jobs: 50 (f=50): [rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr] [100.0% done] [47544K/0K/0K /s] [11.9K/0 /0  iops] [eta 00m:00s]
rand_100read_4k: (groupid=0, jobs=50): err= 0: pid=25884: Mon May 14 14:59:44 2018
  read : io=8454.3MB, bw=48091KB/s, iops=12022 , runt=180018msec
    clat (usec): min=318 , max=167471 , avg=4156.60, stdev=8363.94
     lat (usec): min=318 , max=167472 , avg=4156.89, stdev=8363.95
    clat percentiles (usec):
     |  1.00th=[ 1032],  5.00th=[ 1176], 10.00th=[ 1240], 20.00th=[ 1352],
     | 30.00th=[ 1464], 40.00th=[ 1688], 50.00th=[ 1832], 60.00th=[ 1944],
     | 70.00th=[ 2064], 80.00th=[ 2288], 90.00th=[15808], 95.00th=[18560],
     | 99.00th=[20608], 99.50th=[39168], 99.90th=[134144], 99.95th=[144384],
     | 99.99th=[156672]
    bw (KB/s)  : min=  231, max= 7248, per=2.00%, avg=961.78, stdev=384.46
    lat (usec) : 500=0.05%, 750=0.20%, 1000=0.51%
    lat (msec) : 2=64.37%, 4=19.62%, 10=2.88%, 20=10.62%, 50=1.52%
    lat (msec) : 100=0.02%, 250=0.23%
  cpu          : usr=0.00%, sys=0.02%, ctx=1813752, majf=18446744073709550866, minf=18446744073698419008
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=2164296/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=8454.3MB, aggrb=48090KB/s, minb=48090KB/s, maxb=48090KB/s, mint=180018msec, maxt=180018msec

Disk stats (read/write):
  vdb: ios=2163559/42, merge=23/10, ticks=8925036/223, in_queue=8922540, util=99.94%

100%随机,100%写, 4K

[root@test-db data]# fio -filename=/dev/vdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=100G -numjobs=50 -runtime=180 -group_reporting -name=rand_100write_4k
运行结果:
rand_100write_4k: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
...
rand_100write_4k: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.0.13
Starting 50 threads
Jobs: 50 (f=50): [wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww] [100.0% done] [0K/47996K/0K /s] [0 /11.1K/0  iops] [eta 00m:00s]
rand_100write_4k: (groupid=0, jobs=50): err= 0: pid=25963: Mon May 14 15:08:43 2018
  write: io=8445.5MB, bw=48039KB/s, iops=12009 , runt=180024msec
    clat (usec): min=558 , max=248717 , avg=4160.45, stdev=8315.33
     lat (usec): min=559 , max=248717 , avg=4161.04, stdev=8315.34
    clat percentiles (usec):
     |  1.00th=[ 1256],  5.00th=[ 1528], 10.00th=[ 1656], 20.00th=[ 1816],
     | 30.00th=[ 1928], 40.00th=[ 2024], 50.00th=[ 2128], 60.00th=[ 2224],
     | 70.00th=[ 2384], 80.00th=[ 2704], 90.00th=[ 8768], 95.00th=[17792],
     | 99.00th=[24448], 99.50th=[38656], 99.90th=[130560], 99.95th=[191488],
     | 99.99th=[226304]
    bw (KB/s)  : min=  220, max= 4272, per=2.00%, avg=960.02, stdev=343.97
    lat (usec) : 750=0.04%, 1000=0.28%
    lat (msec) : 2=36.58%, 4=48.13%, 10=5.45%, 20=6.74%, 50=2.59%
    lat (msec) : 100=0.05%, 250=0.14%
  cpu          : usr=0.00%, sys=0.08%, ctx=1907994, majf=0, minf=18446744073699280913
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2162044/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=8445.5MB, aggrb=48039KB/s, minb=48039KB/s, maxb=48039KB/s, mint=180024msec, maxt=180024msec

Disk stats (read/write):
  vdb: ios=148/2158380, merge=22/10, ticks=256/8928184, in_queue=8926408, util=99.96%

100%顺序,100%读 ,4K

fio -filename=/dev/vdb1 -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=4k -size=100G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100read_4k
运行结果:
sqe_100read_4k: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.0.13
Starting 50 threads
Jobs: 50 (f=50): [RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR] [100.0% done] [59996K/0K/0K /s] [14.1K/0 /0  iops] [eta 00m:00s]
sqe_100read_4k: (groupid=0, jobs=50): err= 0: pid=26047: Mon May 14 15:13:02 2018
  read : io=10599MB, bw=60295KB/s, iops=15073 , runt=180006msec
    clat (usec): min=253 , max=550591 , avg=3315.70, stdev=26406.30
     lat (usec): min=254 , max=550591 , avg=3315.95, stdev=26406.30
    clat percentiles (usec):
     |  1.00th=[ 1176],  5.00th=[ 1240], 10.00th=[ 1256], 20.00th=[ 1288],
     | 30.00th=[ 1336], 40.00th=[ 1368], 50.00th=[ 1416], 60.00th=[ 1480],
     | 70.00th=[ 1528], 80.00th=[ 1592], 90.00th=[ 1736], 95.00th=[ 2800],
     | 99.00th=[17792], 99.50th=[18816], 99.90th=[522240], 99.95th=[528384],
     | 99.99th=[536576]
    bw (KB/s)  : min=   15, max= 2475, per=2.00%, avg=1206.47, stdev=634.32
    lat (usec) : 500=0.01%, 750=0.01%, 1000=0.04%
    lat (msec) : 2=92.64%, 4=3.87%, 10=1.05%, 20=2.03%, 50=0.01%
    lat (msec) : 250=0.01%, 500=0.17%, 750=0.15%
  cpu          : usr=0.05%, sys=0.23%, ctx=2697397, majf=0, minf=18446744073708900853
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=2713362/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=10599MB, aggrb=60294KB/s, minb=60294KB/s, maxb=60294KB/s, mint=180006msec, maxt=180006msec

Disk stats (read/write):
  vdb: ios=2711304/55, merge=1805/10, ticks=8899022/202, in_queue=8898860, util=100.00%

100%顺序,100%写 ,4K

fio -filename=/dev/vdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=100G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100write_4k
运行结果:
sqe_100write_4k: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
...
sqe_100write_4k: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.0.13
Starting 50 threads
Jobs: 50 (f=50): [WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW] [100.0% done] [0K/55788K/0K /s] [0 /13.1K/0  iops] [eta 00m:00s]
sqe_100write_4k: (groupid=0, jobs=50): err= 0: pid=26100: Mon May 14 15:17:24 2018
  write: io=10002MB, bw=56896KB/s, iops=14224 , runt=180019msec
    clat (usec): min=583 , max=457330 , avg=3513.01, stdev=9958.13
     lat (usec): min=584 , max=457331 , avg=3513.60, stdev=9958.13
    clat percentiles (usec):
     |  1.00th=[ 1224],  5.00th=[ 1384], 10.00th=[ 1480], 20.00th=[ 1592],
     | 30.00th=[ 1672], 40.00th=[ 1752], 50.00th=[ 1832], 60.00th=[ 1928],
     | 70.00th=[ 2096], 80.00th=[ 2480], 90.00th=[ 6368], 95.00th=[12480],
     | 99.00th=[20608], 99.50th=[37120], 99.90th=[166912], 99.95th=[268288],
     | 99.99th=[346112]
    bw (KB/s)  : min=  152, max= 2432, per=2.01%, avg=1141.03, stdev=401.10
    lat (usec) : 750=0.01%, 1000=0.11%
    lat (msec) : 2=65.06%, 4=21.62%, 10=7.36%, 20=4.40%, 50=1.24%
    lat (msec) : 100=0.08%, 250=0.06%, 500=0.07%
  cpu          : usr=0.05%, sys=0.38%, ctx=2547790, majf=0, minf=18446744073708899536
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2560604/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=10002MB, aggrb=56896KB/s, minb=56896KB/s, maxb=56896KB/s, mint=180019msec, maxt=180019msec

Disk stats (read/write):
  vdb: ios=63/2558949, merge=0/275, ticks=12/8897256, in_queue=8895411, util=100.00%

100%随机,70%读,30%写 4K

fio -filename=/dev/vdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=4k -size=100G -numjobs=50 -runtime=180 -group_reporting -name=randrw_70read_4k
运行结果:
randrw_70read_4k: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
...
randrw_70read_4k: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.0.13
Starting 50 threads
Jobs: 50 (f=50): [mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm] [100.0% done] [48012K/20800K/0K /s] [12.3K/5200 /0  iops] [eta 00m:00s]
randrw_70read_4k: (groupid=0, jobs=50): err= 0: pid=26162: Mon May 14 15:29:18 2018
  read : io=8430.4MB, bw=47954KB/s, iops=11988 , runt=180020msec
    clat (usec): min=304 , max=177969 , avg=3045.60, stdev=5103.08
     lat (usec): min=304 , max=177970 , avg=3045.87, stdev=5103.08
    clat percentiles (usec):
     |  1.00th=[  860],  5.00th=[ 1048], 10.00th=[ 1160], 20.00th=[ 1320],
     | 30.00th=[ 1448], 40.00th=[ 1560], 50.00th=[ 1656], 60.00th=[ 1768],
     | 70.00th=[ 1896], 80.00th=[ 2128], 90.00th=[ 4384], 95.00th=[17792],
     | 99.00th=[20352], 99.50th=[28544], 99.90th=[41216], 99.95th=[57088],
     | 99.99th=[127488]
    bw (KB/s)  : min=  206, max= 4424, per=2.00%, avg=959.77, stdev=408.18
  write: io=3613.8MB, bw=20556KB/s, iops=5138 , runt=180020msec
    clat (usec): min=569 , max=157336 , avg=2617.23, stdev=2821.20
     lat (usec): min=570 , max=157337 , avg=2617.81, stdev=2821.20
    clat percentiles (usec):
     |  1.00th=[ 1096],  5.00th=[ 1432], 10.00th=[ 1592], 20.00th=[ 1768],
     | 30.00th=[ 1912], 40.00th=[ 2040], 50.00th=[ 2160], 60.00th=[ 2288],
     | 70.00th=[ 2416], 80.00th=[ 2576], 90.00th=[ 2864], 95.00th=[ 3472],
     | 99.00th=[19328], 99.50th=[20352], 99.90th=[22400], 99.95th=[37632],
     | 99.99th=[52992]
    bw (KB/s)  : min=   62, max= 1888, per=2.00%, avg=411.23, stdev=178.61
    lat (usec) : 500=0.06%, 750=0.22%, 1000=2.28%
    lat (msec) : 2=61.13%, 4=27.68%, 10=3.02%, 20=4.48%, 50=1.07%
    lat (msec) : 100=0.04%, 250=0.01%
  cpu          : usr=0.01%, sys=0.08%, ctx=2743663, majf=0, minf=18446744073698904078
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=2158165/w=925122/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=8430.4MB, aggrb=47953KB/s, minb=47953KB/s, maxb=47953KB/s, mint=180020msec, maxt=180020msec
  WRITE: io=3613.8MB, aggrb=20555KB/s, minb=20555KB/s, maxb=20555KB/s, mint=180020msec, maxt=180020msec

Disk stats (read/write):
  vdb: ios=2154562/923535, merge=0/0, ticks=6503566/2394699, in_queue=8896553, util=99.93%

执行结果说明:

io=执行了多少M的IO

bw=平均IO带宽
iops=IOPS
runt=线程运行时间
slat=提交延迟
clat=完成延迟
lat=响应时间
bw=带宽
cpu=利用率
IO depths=io队列
IO submit=单个IO提交要提交的IO数
IO complete=Like the above submit number, but for completions instead.
IO issued=The number of read/write requests issued, and how many of them were short.
IO latencies=IO完延迟的分布

io=总共执行了多少size的IO
aggrb=group总带宽
minb=最小.平均带宽.
maxb=最大平均带宽.
mint=group中线程的最短运行时间.
maxt=group中线程的最长运行时间.

ios=所有group总共执行的IO数.
merge=总共发生的IO合并数.
ticks=Number of ticks we kept the disk busy.
io_queue=花费在队列上的总共时间.
util=磁盘利用率

Nginx请求报Not Allowed 405解决方法

nginx不允许向静态文件提交post方式的请求,否则会返回“HTTP/1.1 405 Method not allowed”错误,
405.jpg
解决方法有三种:
一、重定向405错误码到200
在nginx server{}里面添加以下内容,root为站点的根目录

   location ~ (.*\.json) {
        root  html;
        error_page 405 =200 $1;
   }

最后reload nginx即可。
二、转换静态文件接收的POST请求到GET方法

upstream static80 {
    server localhost:80;
}

server {
    listen 80;
    ...

    error_page 405 =200 @405;
    location @405 {
        root  html;
        proxy_method GET;
        proxy_pass http://static80;
    }
}

三、安装编译的时候修改源码(不推荐此方法)
源码文件位于/nginx源码目录/src/http/modules/ngx_http_static_module.c,找到如下代码:

if (r->method & NGX_HTTP_POST) {
     return NGX_HTTP_NOT_ALLOWED;
}

整段注释掉,然后重新编译 make,不需要make install,把编译生成的nginx文件复制到sbin下的nginx文件,重启nginx即可。

ORACLE内核参数说明

服务器为16核16G虚拟机配置,oracle11gR2推荐的参数设置为:

kernel.shmmax = 4294967296
//公式:4G*1024*1024*1024=4294967296(字节) 
//表示最大共享内存,如果小的话可以按实际情况而定(单位:字节) 

kernel.shmall = 2097152
//公式:8G*1024*1024/4K = 2097152(页) 
//表示所有内存大小(单位:页) 一般为物理内存的一半

kernel.shmmni = 4096
//表示最小共享内存固定4096KB(由于32位操作系统默认一页为4K) 

net.ipv4.ip_local_port_range = 9000 65500
//ip_local_port_range表示端口的范围,为指定的内容 

net.core.wmem_max = 1048576
//最大的TCP数据发送窗口大小(字节)

kernel.sem = 250 32000 100 128
//4个参数依次是SEMMSL:每个用户拥有信号量最大数,SEMMNS:系统信号量最大数,SEMOPM:每次semopm系统调用操作数,SEMMNI:系统辛苦量集数最大数。这4个参数为固定内容大小 

fs.file-max = 6815744
//file-max固定大小65536 

net.core.rmem_default = 262144
//默认的TCP数据接收窗口大小(字节)

net.core.wmem_default = 262144
//默认的TCP数据发送窗口大小(字节)

net.core.rmem_max = 4194304
//最大的TCP数据接收窗口大小(字节)

fs.aio-max-nr = 1048576
//aio最大值

Could not execute auto check for display colors using command /usr/bin/xdpyinfo. Check if the DISPLAY variable is set.

CentOS7.4安装Oracle11GR2的时候,执行 ./runInstaller 安装时报错:

Checking Temp space: must be greater than 120 MB.   Actual 179056 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 15359 MB    Passed
Checking monitor: must be configured to display at least 256 colors    Failed <<<<
    >>> Could not execute auto check for display colors using command /usr/bin/xdpyinfo. Check if the DISPLAY variable is set.

Some requirement checks failed. You must fulfill these requirements before

continuing with the installation,Continue? (y/n) [n] 

>>> Ignoring required pre-requisite failures. Continuing...
解决方法:

使用root登陆VNC窗口,打开终端:

sh-4.2# su -l root    #切换到root账号下
xhost +SI:localuser:oracle   #执行xhost
su - oracle  #切换oracle
export DISPLAY=:1   #设置DISPLAY
./runInstaller  #安装即可

使用gotop查看系统负载情况

Gotop 是一个 TUI 图形活动监视器,使用 Go 语言编写。它是完全免费、开源的,受到了 gtop 和 vtop 的启发。
在此简要的指南中,我们将讨论如何安装和使用 Gotop 来监视 Linux 系统的活动。
Gotop 是用 Go 编写的,所以我们需要先安装它。要在 Linux 中安装 Go 语言,请参阅以下指南。
安装 Go 之后,使用以下命令下载最新的 Gotop 二进制文件。
安装:

sh -c "$(curl https://raw.githubusercontent.com/cjbassi/gotop/master/download.sh)"

将下载的二进制文件移动到您的 $PATH 中:

cp gotop /usr/local/bin

赋予执行权限

chmod +x /usr/local/bin/gotop

从终端直接运行gotop命令即可:
命令参数:

c – CPU
m – 内存
p – PID

对于进程浏览,请使用以下键。

上/下 箭头或者 j/k 键用于上移下移。
Ctrl-d 和 Ctrl-u – 上移和下移半页。
Ctrl-f 和 Ctrl-b – 上移和下移整页。
gg 和 G – 跳转顶部和底部。

按下 TAB 切换进程分组。要杀死选定的进程或进程组,请输入 dd。要选择一个进程,只需点击它。要向下/向上滚动,请使用鼠标滚动按钮。要放大和缩小 CPU 和内存的图形,请使用 h 和 l。要显示帮助菜单,只需按 ?。
gotop.png

via: https://www.ostechnix.com/gotop-yet-another-tui-graphical-activity-monitor-written-in-go/
github: https://github.com/cjbassi/gotop

mysqldump导出报错-Got error: 1449错误解决办法

mysqldump -uroot -pPasswd DBName > /home/lsf/DB_Backup.sql

报错,显示:

Got error: 1449: The user specified as a definer ('xxx'@'') does not exist when using LOCK TABLES

或者直接报:

the user specified as a definer ('xxx'@'') does not exist

解决办法:

给xxx用户再添加一个对全部host都有可以访问的权限:

mysql -uroot -pPasswd
mysql >grant all privileges on *.* to xxx@"%" identified by "Passwd";
mysql >flush privileges;

oem启动报错解决方法及dbconsole的重新配置

Win10下安装的ORACLE11g R2,修改了主机名重启笔记本以后,oem启动报错:

C:\app\ice\product\11.2.0\dbhome_1\BIN>emctl start dbcpnsole
Environment variable ORACLE_UNQNAME not defined. Please set ORACLE_UNQNAME to database unique name.

解决方法:
根据提示先设置ORACLE_UNQNAME,然后再尝试启动

SET ORACLE_UNQNAME=ORCL(orcl为SID)
emctl start dbconsole

如果启动成功即可使用https://localhost:1158/em登陆oem管理面板了;
如果不行可以尝试重新创建DBCONSOLE:

emca -config dbcontrol db -repos recreate
根据提示,先输入SID,再输入Y继续;
输入端口1521,输入SYS密码,输入DBSNMP密码,输入SYSMAN 密码,输入Y继续
完成。
C:\app\ice\product\11.2.0\dbhome_1\BIN>emca -config dbcontrol db -repos recreate

EMCA 开始于 2018-5-6 16:21:22
EM Configuration Assistant, 11.2.0.0.2 正式版
版权所有 (c) 2003, 2005, Oracle。保留所有权利。

输入以下信息:
数据库 SID: unixsodb
监听程序端口号: 1521
监听程序 ORACLE_HOME [ c:\app\ice\product\11.2.0\dbhome_1 ]:
SYS 用户的口令:
DBSNMP 用户的口令:
SYSMAN 用户的口令:
通知的电子邮件地址 (可选):
通知的发件 (SMTP) 服务器 (可选):
-----------------------------------------------------------------

已指定以下设置

数据库 ORACLE_HOME ................ c:\app\ice\product\11.2.0\dbhome_1

本地主机名 ................ ice110
监听程序 ORACLE_HOME ................ c:\app\ice\product\11.2.0\dbhome_1
监听程序端口号 ................ 1521
数据库 SID ................ unixsodb
通知的电子邮件地址 ...............
通知的发件 (SMTP) 服务器 ...............

-----------------------------------------------------------------
是否继续? [是(Y)/否(N)]: y
2018-5-6 16:22:24 oracle.sysman.emcp.EMConfig perform
信息: 正在将此操作记录到 c:\app\ice\cfgtoollogs\emca\unixsodb\emca_2018_05_06_16_21_22.log。
2018-5-6 16:22:25 oracle.sysman.emcp.EMReposConfig invoke
信息: 正在删除 EM 资料档案库 (此操作可能需要一段时间)...
2018-5-6 16:23:06 oracle.sysman.emcp.EMReposConfig invoke
信息: 已成功删除资料档案库
2018-5-6 16:23:27 oracle.sysman.emcp.EMReposConfig createRepository
信息: 正在创建 EM 资料档案库 (此操作可能需要一段时间)...
2018-5-6 16:26:00 oracle.sysman.emcp.EMReposConfig invoke
信息: 已成功创建资料档案库
2018-5-6 16:26:02 oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository
信息: 正在将配置数据上载到 EM 资料档案库 (此操作可能需要一段时间)...
2018-5-6 16:26:23 oracle.sysman.emcp.EMReposConfig invoke
信息: 已成功上载配置数据
2018-5-6 16:26:32 oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
信息: 软件库已配置成功。
2018-5-6 16:26:32 oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
信息: 正在部署预配档案...
2018-5-6 16:26:58 oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
信息: 预配档案部署成功。
2018-5-6 16:26:58 oracle.sysman.emcp.util.DBControlUtil secureDBConsole
信息: 正在保护 Database Control (此操作可能需要一段时间)...
2018-5-6 16:27:04 oracle.sysman.emcp.util.DBControlUtil secureDBConsole
信息: 已成功保护 Database Control。
2018-5-6 16:27:04 oracle.sysman.emcp.util.DBControlUtil startOMS
信息: 正在启动 Database Control (此操作可能需要一段时间)...
2018-5-6 16:27:50 oracle.sysman.emcp.EMDBPostConfig performConfiguration
信息: 已成功启动 Database Control
2018-5-6 16:27:50 oracle.sysman.emcp.EMDBPostConfig performConfiguration
信息: >>>>>>>>>>> Database Control URL 为 https://ice110:5500/em <<<<<<<<<<<
2018-5-6 16:27:52 oracle.sysman.emcp.EMDBPostConfig invoke
警告:
************************  WARNING  ************************

管理资料档案库已置于安全模式下, 在此模式下将对 Enterprise Manager 数据进行加密。加密密钥已放置在文件 c:/app/ice/product/11.2.0/dbhome_1/ice110_unixsodb/sysman/config/emkey.ora 中。请务必备份此文件, 因为如果此文件丢失, 则加密数据将不可用。

***********************************************************
已成功完成 Enterprise Manager 的配置
EMCA 结束于 2018-5-6 16:27:52

C:\app\ice\product\11.2.0\dbhome_1\BIN>

查看状态:

emctl status dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation.  All rights reserved.
https://ice110:5500/em/console/aboutApplication
Oracle Enterprise Manager 11g is running.
------------------------------------------------------------------
Logs are generated in directory c:\app\ice\product\11.2.0\dbhome_1/ice110_unixsodb/sysman/log

注意重建以后oem的端口变成了5500,默认端口是1158
oem.png
emca常用命令:

创建一个EM资料库
emca -repos create

重建一个EM资料库
emca -repos recreate

删除一个EM资料库
emca -repos drop

配置数据库的 Database Control
emca -config dbcontrol db

删除数据库的 Database Control配置
emca -deconfig dbcontrol db

重新配置db control的端口,默认端口在1158
emca -reconfig ports
emca -reconfig ports -dbcontrol_http_port 1160
emca -reconfig ports -agent_port 3940

启动EM console服务
SET ORACLE_UNQNAME=ORCL(orcl为SID)
emctl start dbconsole

停止EM console服务
emctl stop dbconsole

查看EM console服务的状态
emctl status dbconsole

配置dbconsole的步骤
emca -repos create
emca -config dbcontrol db
emctl start dbconsole

重新配置dbconsole的步骤
emca -repos drop
emca -repos create
emca -config dbcontrol db
emctl start dbconsole

SVN Skipped 'xxx' -- Node remains in conflict svn文件冲突解决方法

开发在执行svn up更新静态文件的时候报错,

# svn up
Updating '.':
Skipped 'xxx' -- Node remains in conflict
At revision 2635.
Summary of conflicts:
  Skipped paths: 1

xxx为文件名

处理方式:

svn remove --force filename
svn resolve --accept=working  filename
svn up

一般就可以了,如果还是不行可以把目录mv掉,重新全量拉下·

Kafka主要配置文件参数详解

官方文档地址:http://kafka.apache.org/documentation.html

############################# System #############################
#唯一标识在集群中的ID,要求是正数。
broker.id=0
#服务端口,默认9092
port=9092
#监听地址,不设为所有地址
host.name=debugo01

# 处理网络请求的最大线程数
num.network.threads=2
# 处理磁盘I/O的线程数
num.io.threads=8
# 一些后台线程数
background.threads = 4
# 等待IO线程处理的请求队列最大数
queued.max.requests = 500

#  socket的发送缓冲区(SO_SNDBUF)
socket.send.buffer.bytes=1048576
# socket的接收缓冲区 (SO_RCVBUF) 
socket.receive.buffer.bytes=1048576
# socket请求的最大字节数。为了防止内存溢出,message.max.bytes必然要小于
socket.request.max.bytes = 104857600

############################# Topic #############################
# 每个topic的分区个数,更多的partition会产生更多的segment file
num.partitions=2
# 是否允许自动创建topic ,若是false,就需要通过命令创建topic
auto.create.topics.enable =true
# 一个topic ,默认分区的replication个数 ,不能大于集群中broker的个数。
default.replication.factor =1
# 消息体的最大大小,单位是字节
message.max.bytes = 1000000

############################# ZooKeeper #############################
# Zookeeper quorum设置。如果有多个使用逗号分割
zookeeper.connect=debugo01:2181,debugo02,debugo03
# 连接zk的超时时间
zookeeper.connection.timeout.ms=1000000
# ZooKeeper集群中leader和follower之间的同步实际
zookeeper.sync.time.ms = 2000

############################# Log #############################
#日志存放目录,多个目录使用逗号分割
log.dirs=/var/log/kafka

# 当达到下面的消息数量时,会将数据flush到日志文件中。默认10000
#log.flush.interval.messages=10000
# 当达到下面的时间(ms)时,执行一次强制的flush操作。interval.ms和interval.messages无论哪个达到,都会flush。默认3000ms
#log.flush.interval.ms=1000
# 检查是否需要将日志flush的时间间隔
log.flush.scheduler.interval.ms = 3000

# 日志清理策略(delete|compact)
log.cleanup.policy = delete
# 日志保存时间 (hours|minutes),默认为7天(168小时)。超过这个时间会根据policy处理数据。bytes和minutes无论哪个先达到都会触发。
log.retention.hours=168
# 日志数据存储的最大字节数。超过这个时间会根据policy处理数据。
#log.retention.bytes=1073741824

# 控制日志segment文件的大小,超出该大小则追加到一个新的日志segment文件中(-1表示没有限制)
log.segment.bytes=536870912
# 当达到下面时间,会强制新建一个segment
log.roll.hours = 24*7
# 日志片段文件的检查周期,查看它们是否达到了删除策略的设置(log.retention.hours或log.retention.bytes)
log.retention.check.interval.ms=60000

# 是否开启压缩
log.cleaner.enable=false
# 对于压缩的日志保留的最长时间
log.cleaner.delete.retention.ms = 1 day

# 对于segment日志的索引文件大小限制
log.index.size.max.bytes = 10 * 1024 * 1024
#y索引计算的一个缓冲区,一般不需要设置。
log.index.interval.bytes = 4096

############################# replica #############################
# partition management controller 与replicas之间通讯的超时时间
controller.socket.timeout.ms = 30000
# controller-to-broker-channels消息队列的尺寸大小
controller.message.queue.size=10
# replicas响应leader的最长等待时间,若是超过这个时间,就将replicas排除在管理之外
replica.lag.time.max.ms = 10000
# 是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader,并转移到其他broker
controlled.shutdown.enable = false
# 控制器关闭的尝试次数
controlled.shutdown.max.retries = 3
# 每次关闭尝试的时间间隔
controlled.shutdown.retry.backoff.ms = 5000

# 如果relicas落后太多,将会认为此partition relicas已经失效。而一般情况下,因为网络延迟等原因,总会导致replicas中消息同步滞后。如果消息严重滞后,leader将认为此relicas网络延迟较大或者消息吞吐能力有限。在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.lag.max.messages = 4000
#leader与relicas的socket超时时间
replica.socket.timeout.ms= 30 * 1000
# leader复制的socket缓存大小
replica.socket.receive.buffer.bytes=64 * 1024
# replicas每次获取数据的最大字节数
replica.fetch.max.bytes = 1024 * 1024
# replicas同leader之间通信的最大等待时间,失败了会重试
replica.fetch.wait.max.ms = 500
# 每一个fetch操作的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会等待直到数据达到这个大小
replica.fetch.min.bytes =1
# leader中进行复制的线程数,增大这个数值会增加relipca的IO
num.replica.fetchers = 1
# 每个replica将最高水位进行flush的时间间隔
replica.high.watermark.checkpoint.interval.ms = 5000
 
# 是否自动平衡broker之间的分配策略
auto.leader.rebalance.enable = false
# leader的不平衡比例,若是超过这个数值,会对分区进行重新的平衡
leader.imbalance.per.broker.percentage = 10
# 检查leader是否不平衡的时间间隔
leader.imbalance.check.interval.seconds = 300
# 客户端保留offset信息的最大空间大小
offset.metadata.max.bytes = 1024

#############################Consumer #############################
# Consumer端核心的配置是group.id、zookeeper.connect
# 决定该Consumer归属的唯一组ID,By setting the same group id multiple processes indicate that they are all part of the same consumer group.
group.id
# 消费者的ID,若是没有设置的话,会自增
consumer.id
# 一个用于跟踪调查的ID ,最好同group.id相同
client.id = <group_id>
 
# 对于zookeeper集群的指定,必须和broker使用同样的zk配置
zookeeper.connect=debugo01:2182,debugo02:2182,debugo03:2182
# zookeeper的心跳超时时间,查过这个时间就认为是无效的消费者
zookeeper.session.timeout.ms = 6000
# zookeeper的等待连接时间
zookeeper.connection.timeout.ms = 6000
# zookeeper的follower同leader的同步时间
zookeeper.sync.time.ms = 2000
# 当zookeeper中没有初始的offset时,或者超出offset上限时的处理方式 。
# smallest :重置为最小值 
# largest:重置为最大值 
# anything else:抛出异常给consumer
auto.offset.reset = largest

# socket的超时时间,实际的超时时间为max.fetch.wait + socket.timeout.ms.
socket.timeout.ms= 30 * 1000
# socket的接收缓存空间大小
socket.receive.buffer.bytes=64 * 1024
#从每个分区fetch的消息大小限制
fetch.message.max.bytes = 1024 * 1024
 
# true时,Consumer会在消费消息后将offset同步到zookeeper,这样当Consumer失败后,新的consumer就能从zookeeper获取最新的offset
auto.commit.enable = true
# 自动提交的时间间隔
auto.commit.interval.ms = 60 * 1000
 
# 用于消费的最大数量的消息块缓冲大小,每个块可以等同于fetch.message.max.bytes中数值
queued.max.message.chunks = 10

# 当有新的consumer加入到group时,将尝试reblance,将partitions的消费端迁移到新的consumer中, 该设置是尝试的次数
rebalance.max.retries = 4
# 每次reblance的时间间隔
rebalance.backoff.ms = 2000
# 每次重新选举leader的时间
refresh.leader.backoff.ms
 
# server发送到消费端的最小数据,若是不满足这个数值则会等待直到满足指定大小。默认为1表示立即接收。
fetch.min.bytes = 1
# 若是不满足fetch.min.bytes时,等待消费端请求的最长等待时间
fetch.wait.max.ms = 100
# 如果指定时间内没有新消息可用于消费,就抛出异常,默认-1表示不受限
consumer.timeout.ms = -1

#############################Producer#############################
# 核心的配置包括:
# metadata.broker.list
# request.required.acks
# producer.type
# serializer.class

# 消费者获取消息元信息(topics, partitions and replicas)的地址,配置格式是:host1:port1,host2:port2,也可以在外面设置一个vip
metadata.broker.list
 
#消息的确认模式
# 0:不保证消息的到达确认,只管发送,低延迟但是会出现消息的丢失,在某个server失败的情况下,有点像TCP
# 1:发送消息,并会等待leader 收到确认后,一定的可靠性
# -1:发送消息,等待leader收到确认,并进行复制操作后,才返回,最高的可靠性
request.required.acks = 0
 
# 消息发送的最长等待时间
request.timeout.ms = 10000
# socket的缓存大小
send.buffer.bytes=100*1024
# key的序列化方式,若是没有设置,同serializer.class
key.serializer.class
# 分区的策略,默认是取模
partitioner.class=kafka.producer.DefaultPartitioner
# 消息的压缩模式,默认是none,可以有gzip和snappy
compression.codec = none
# 可以针对默写特定的topic进行压缩
compressed.topics=null
# 消息发送失败后的重试次数
message.send.max.retries = 3
# 每次失败后的间隔时间
retry.backoff.ms = 100
# 生产者定时更新topic元信息的时间间隔 ,若是设置为0,那么会在每个消息发送后都去更新数据
topic.metadata.refresh.interval.ms = 600 * 1000
# 用户随意指定,但是不能重复,主要用于跟踪记录消息
client.id=""
 
# 异步模式下缓冲数据的最大时间。例如设置为100则会集合100ms内的消息后发送,这样会提高吞吐量,但是会增加消息发送的延时
queue.buffering.max.ms = 5000
# 异步模式下缓冲的最大消息数,同上
queue.buffering.max.messages = 10000
# 异步模式下,消息进入队列的等待时间。若是设置为0,则消息不等待,如果进入不了队列,则直接被抛弃
queue.enqueue.timeout.ms = -1
# 异步模式下,每次发送的消息数,当queue.buffering.max.messages或queue.buffering.max.ms满足条件之一时producer会触发发送。
batch.num.messages=200

MySQL创建函数-存储过程报“ERROR 1418 ”错误 解决方法

MySQL创建函数或存储过程的时候报error 1418错误:

This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

是因为log_bin_trust_function_creators参数在起作用:
当二进制日志启用后,这个变量就会启用。它控制是否可以信任存储函数创建者,不会创建写入二进制日志引起不安全事件的存储函数。
如果设置为0(默认值),用户不得创建或修改存储函数,除非它们具有除CREATE ROUTINE或ALTER ROUTINE特权之外的SUPER权限。 设置为0还强制使用DETERMINISTIC特性或READS SQL DATA或NO SQL特性声明函数的限制。 如果变量设置为1,MySQL不会对创建存储函数实施这些限制,此变量也适用于触发器的创建。

mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)
 
mysql>  show variables like '%log_bin_trust_function_creators%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin_trust_function_creators | OFF   |
+---------------------------------+-------+
1 row in set (0.00 sec)

如果数据库没有使用主从复制,那么就可以将参数log_bin_trust_function_creators设置为1。

mysql> set global log_bin_trust_function_creators=1;

这个动态设置的方式会在服务重启后失效,所以我们还必须在my.cnf中设置,加上

log_bin_trust_function_creators=1

这样就会永久生效。
注意:如果开启了主从复制,同时又打开了log_bin_trust_function_creators参数,可以创建函数、存储过程,可能会引起主从复制故障·

解决virt-manager启动管理器出错:unsupported format character

virt-manager出错,报错信息如下:

启动管理器出错:unsupported format character ‘��0xffffffef) at index 30

virt.png

系统版本:CentOS release 6.9 (Final)
解决方法如下:
先卸载0.9.0-34版本:

yum remove virt-manager1

找到virt-manager-0.9.0-31的CentOS版本,安装就可以了

wget http://vault.centos.org/6.7/cr/x86_64/Packages/virt-manager-0.9.0-31.el6.x86_64.rpm
rpm -ivh virt-manager-0.9.0-31.el6.x86_64.rpm

即可解决。

使用gprecoverseg修复Segment节点

greenplum环境中测试的时候, segment节点sdw2由于硬盘空间不足,显示宕机了,重新启动的时候节点报错,启动不了;
使用gpstate -m查看节点状态显示sdw2节点失败:

[gpadmin@dw01 gpmaster]$ gpstate -m

gpstate:dw01:gpadmin-[INFO]:-Starting gpstate with args: -m
gpstate:dw01:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.12.0 build 1'
gpstate:dw01:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.12.0 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Feb 27 2017 20:45:12'
gpstate:dw01:gpadmin-[INFO]:-Obtaining Segment details from master...
gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------
gpstate:dw01:gpadmin-[INFO]:--Current GPDB mirror list and status
gpstate:dw01:gpadmin-[INFO]:--Type = Group
gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------
gpstate:dw01:gpadmin-[INFO]:-   Mirror   Datadir                        Port    Status    Data Status    
gpstate:dw01:gpadmin-[WARNING]:-sdw2     /data/gpdata/gpdatam1/gpseg0   50000   Failed                   <<<<<<<<
gpstate:dw01:gpadmin-[WARNING]:-sdw2     /data/gpdata/gpdatam1/gpseg1   50001   Failed                   <<<<<<<<
gpstate:dw01:gpadmin-[INFO]:-   sdw1     /data/gpdata/gpdatam1/gpseg2   50000   Passive   Synchronized
gpstate:dw01:gpadmin-[INFO]:-   sdw1     /data/gpdata/gpdatam1/gpseg3   50001   Passive   Synchronized
gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------
gpstate:dw01:gpadmin-[WARNING]:-2 segment(s) configured as mirror(s) have failed

gprecoverseg参数选项

-a (不提示)
不要提示用户确认。
-B parallel_processes
并行恢复的Segment数。如果未指定,则实用程序将启动最多四个并行进程,具体取决于需要恢复多少个Segment实例。
-d master_data_directory
可选。Master主机的数据目录。如果未指定,则使用为$MASTER_DATA_DIRECTORY设置的值。
-F (完全恢复)
可选。执行活动Segment实例的完整副本以恢复出现故障的Segment。 默认情况下,仅复制Segment关闭时发生的增量更改。
-i recover_config_file
指定文件的名称以及有关失效Segment要恢复的详细信息。文件中的每一行都是以下格式。SPACE关键字表示所需空间的位置。不要添加额外的空间。
filespaceOrder=[filespace1_fsname[, filespace2_fsname[, ...]]
<failed_host_address>:<port>:<data_directory>SPACE 
<recovery_host_address>:<port>:<replication_port>:<data_directory>
[:<fselocation>:...]

恢复所有失效的Segment实例:

gprecoverseg
恢复后,重新平衡用户的Greenplum数据库系统,将所有Segment重置为其首选角色。 首先检查所有Segment已启动并同步

将任何失效的Segment实例恢复到新配置的空闲Segment主机:

$ gprecoverseg -i recover_config_file

本例使用gprecoverseg修复:

20180420_172.28.95.255038[gpadmin@dw01 pg_log]$ gprecoverseg
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Starting gprecoverseg with args: 
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.12.0 build 1'
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.12.0 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Feb 27 2017 20:45:12'
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Checking if segments are ready to connect
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Obtaining Segment details from master...
20180420_172.28.95.25503820180420:21:50:37:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Obtaining Segment details from master...
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Greenplum instance recovery parameters
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Recovery type              = Standard
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Recovery 1 of 2
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Synchronization mode                        = Incremental
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance host                        = dw04
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance address                     = sdw2
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance directory                   = /data/gpdata/gpdatam1/gpseg0
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance port                        = 50000
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance replication port            = 51000
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance host               = dw03
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance address            = sdw1
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance directory          = /data/gpdata/gpdatap1/gpseg0
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance port               = 40000
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance replication port   = 41000
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Target                             = in-place
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Recovery 2 of 2
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Synchronization mode                        = Incremental
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance host                        = dw04
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance address                     = sdw2
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance directory                   = /data/gpdata/gpdatam1/gpseg1
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance port                        = 50001
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Failed instance replication port            = 51001
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance host               = dw03
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance address            = sdw1
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance directory          = /data/gpdata/gpdatap1/gpseg1
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance port               = 40001
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Source instance replication port   = 41001
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:-   Recovery Target                             = in-place
20180420_172.28.95.25503920180420:21:50:38:002098 gprecoverseg:dw01:gpadmin-[INFO]:----------------------------------------------------------
20180420_172.28.95.255039
20180420_172.28.95.255039Continue with segment recovery procedure Yy|Nn (default=N):
20180420_172.28.95.255041> y
20180420_172.28.95.25504120180420:21:50:40:002098 gprecoverseg:dw01:gpadmin-[INFO]:-2 segment(s) to recover
20180420_172.28.95.25504120180420:21:50:40:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Ensuring 2 failed segment(s) are stopped
20180420_172.28.95.255042 
20180420_172.28.95.25504220180420:21:50:41:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Ensuring that shared memory is cleaned up for stopped segments
20180420_172.28.95.255047updating flat files
20180420_172.28.95.25504720180420:21:50:46:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Updating configuration with new mirrors
20180420_172.28.95.25504720180420:21:50:46:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Updating mirrors
20180420_172.28.95.255048. 
20180420_172.28.95.25504820180420:21:50:47:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Starting mirrors
20180420_172.28.95.25504820180420:21:50:48:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Commencing parallel primary and mirror segment instance startup, please wait...
20180420_172.28.95.255052.... 
20180420_172.28.95.25505220180420:21:50:52:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Process results...
20180420_172.28.95.25505220180420:21:50:52:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Updating configuration to mark mirrors up
20180420_172.28.95.25505220180420:21:50:52:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Updating primaries
20180420_172.28.95.25505220180420:21:50:52:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Commencing parallel primary conversion of 2 segments, please wait...
20180420_172.28.95.255054.. 
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Process results...
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Done updating primaries
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-******************************************************************
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Updating segments for resynchronization is completed.
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-For segments updated successfully, resynchronization will continue in the background.
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-Use  gpstate -s  to check the resynchronization progress.
20180420_172.28.95.25505420180420:21:50:54:002098 gprecoverseg:dw01:gpadmin-[INFO]:-******************************************************************

修复完成查看节点状态:

20180420_172.28.95.255110[gpadmin@dw01 pg_log]$ gpstate -m
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-Starting gpstate with args: -m
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.12.0 build 1'
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.12.0 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Feb 27 2017 20:45:12'
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-Obtaining Segment details from master...
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:--Current GPDB mirror list and status
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:--Type = Group
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-   Mirror   Datadir                        Port    Status    Data Status       
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-   sdw2     /data/gpdata/gpdatam1/gpseg0   50000   Passive   Resynchronizing
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-   sdw2     /data/gpdata/gpdatam1/gpseg1   50001   Passive   Resynchronizing
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-   sdw1     /data/gpdata/gpdatam1/gpseg2   50000   Passive   Synchronized
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:-   sdw1     /data/gpdata/gpdatam1/gpseg3   50001   Passive   Synchronized
20180420_172.28.95.25511120180420:21:51:10:002350 gpstate:dw01:gpadmin-[INFO]:--------------------------------------------------------------

节点全部启动,sdw2节点正在重新同步,过一段时间一般几分钟即可,根据数据量大小而定,一般很很快同步完毕;
参考文档:
https://gp-docs-cn.github.io/docs/utility_guide/admin_utilities/gprecoverseg.html
http://mysql.taobao.org/monthly/2016/04/03/

最新

分类

归档

评论

  • 安安: 都是af
  • Liang: 嗯,有点不通顺·
  • 王庭威: “MySQL互为主从...
  • Liang: 贴下编译参数和步骤,...
  • shao3911: 您好,为什么我在编译...
  • aliang: 先看是yum安装还是...
  • aliang: 将原来的nginx安...
  • yen: 3、如果要回滚的话,...
  • yen: 刚好需要升级ngin...
  • 文雨: 一些新的method...

其它