域名shunzi.me突然被GFW墙了.无解...
突然有几天想放弃了
既然我不怎么写blog
又何必折腾来,折腾去呢
缓了好久，想了好久
然后重新注册域名mydba.me
blog从wordpress迁移到typecho
web跟db分开.
然后继续折腾.
还是那句话：生命不息，折腾不止！

昨天基于某种需求，需要web服务器对外提供目录的浏览下载；
网上查了下Nginx的配置如下：

location / {   
        root /www/wwwroot/seafile;
        autoindex on;         
        autoindex_exact_size off;   
        autoindex_localtime on;  
        charset utf-8,gbk;
}

其中：
root /www/wwwroot/seafile //指定实际目录绝对路径；
autoindex on; //开启目录浏览功能
autoindex_exact_size off; //关闭详细文件大小统计，让文件大小显示MB，GB单位，默认为b；
autoindex_localtime on; //开启以服务器本地时区显示文件修改日期！
charset utf-8,gbk; //解决中文字符集乱码

这样就行了，mark下。

最近在学Python，网上找了一张图，看起来介绍的蛮详细的。
入门神图，据说30分钟就能入门^v^!

这几天发现VPS上的mysql数据库告警日志里报了很多如下错误：

2017-04-10 05:37:49 14557 [Warning] Aborted connection 162746 to db: 'bigbiglife' user: 'bigbiglife' host: 'localhost' (Got an error reading communication packets)

虽然不是大问题，但是对于处女座的我，不能忍！

我这个问题可能是PHP连接MySQL后超过wait_timeout设置的时间限制被kill后造成的。
详情可以看https://dev.mysql.com/doc/refman/5.7/en/communication-errors.html

If a client is unable even to connect, the server increments the Aborted_connects status variable. Unsuccessful connection attempts can occur for the following reasons:

• A client attempts to access a database but has no privileges for it.
• A client uses an incorrect password.
• A connection packet does not contain the right information.
• It takes more than connect_timeout seconds to obtain a connect packet. See Section 6.1.5, “Server System Variables”.

If a client successfully connects but later disconnects improperly or is terminated, the server increments the Aborted_clients status variable, and logs an Aborted connection message to the error log. The cause can be any of the following:

• The client program did not call mysql_close() before exiting.
• The client had been sleeping more than wait_timeout or interactive_timeout seconds without issuing any requests to the server. See Section 6.1.5, “Server System Variables”.
• The client program ended abruptly in the middle of a data transfer.

Other reasons for problems with aborted connections or aborted clients:

• The max_allowed_packet variable value is too small or queries require more memory than you have allocated for mysqld. See Section B.5.2.10, “Packet Too Large”.

下面是我修改后参数，观察一段时间先：

[root@shunzi ~]# grep -E 'max_allowed_packet|wait_timeout|interactive_timeout' /etc/my.cnf
wait_timeout                    = 600
interactive_timeout             = 600
max_allowed_packet              = 32M

昨天同事遇到一个问题，jdbc连接数据库的时候报ora-12505错误。原始写法如下：

jdbc:oracle:thin:@192.168.10.11:1521:ivldb

了解到这台数据库是11gRAC，jdbc连接的是rac的scan ip。经过查找发现jdbc连接scan ip的格式如下：

jdbc:oracle:thin:@{scan-listener-hostname}:{port}/{service-name}

顾把原始写法改成如下即可：

jdbc:oracle:thin:@192.168.10.11:1521/ivldb

参考MOS文档：Using SCAN With Oracle JDBC 11g Thin Driver (文档 ID 1290193.1)
mark一下，留作记录！

新换了一家国外VPS,搭好环境，弄好备份脚本后，突然发现crontab里的脚本不执行。
经过一顿google，发现是crontab里必须加上执行脚本的完整路径，如下：

[root@shunzi ~]# crontab -l
*/2 * * * * /bin/sh /bk/.sqlbak.sh >/dev/null

原先没加/bin/sh，所以crontab执行的时候取不到相应的环境变量。
然后测试了一下发现脚本是执行了，但是日志里的时间跟当前系统的时间不一致。
我的VPS的时区已经改成+8了，系统时间跟国内时间也是一致的，但是日志里记录的时间不对。
经过一顿google，找到我想要的了。详细操作如下：

1. service crond restart
2. service rsyslog restart

最后问题解决，留此做个记录，本人所用系统是centos。