高效的log工具：Logrotate

Logrotate的介绍

显而易见，Logrotate是基于CRON来运行的，其脚本是「/etc/cron.daily/logrotate」：

实际运行时，Logrotate会调用配置文件「/etc/logrotate.conf」：

这里的设置可以理解为Logrotate的缺省值，当然了，可以我们在「/etc/logrotate.d」目录里放置自己的配置文件，用来覆盖Logrotate的缺省值。

Logrotate的演示

按天保存一周的Nginx日志压缩文件，配置文件为「/etc/logrotate.d/nginx」：

如果你等不及CRON，可以通过如下命令来手动执行：

当然，正式执行前最好通过Debug选项来验证一下，这对调试也很重要：

BTW：类似的还有Verbose选项，这里就不多说了。

Logrotate的疑问

大家可能注意到了，我在前面Nginx的例子里声明日志文件的时候用了星号通配符，也就是说这里可能涉及多个日志文件，比如：access.log和error.log。说到这里大家或许就明白了，sharedscripts的作用是在所有的日志文件都轮转完毕后统一执行一次脚本。如果没有配置这条指令，那么每个日志文件轮转完毕后都会执行一次脚本。

它们都是用来控制保存多少日志文件的，区别在于rotate是以个数为单位的，而maxage是以天数为单位的。如果我们是以按天来轮转日志，那么二者的差别就不大了。

前面我们说过，Logrotate是基于CRON运行的，所以这个时间是由CRON控制的，具体可以查询CRON的配置文件「/etc/crontab」，可以手动改成如23:59等时间执行：

如果使用的是新版CentOS，那么配置文件为：/etc/anacrontab。

以Nginx为例，是通过postrotate指令发送USR1信号来通知Nginx重新打开日志文件的。但是其他的应用程序不一定遵循这样的约定，比如说MySQL是通过flush-logs来重新打开日志文件的。更有甚者，有些应用程序就压根没有提供类似的方法，此时如果想重新打开日志文件，就必须重启服务，但为了高可用性，这往往不能接受。还好Logrotate提供了一个名为copytruncate的指令，此方法采用的是先拷贝再清空的方式，整个过程中日志文件的 *** 作句柄没有发生改变，所以不需要通知应用程序重新打开日志文件，但是需要注意的是，在拷贝和清空之间有一个时间差，所以可能会丢失部分日志数据。

BTW：MySQL本身在support-files目录已经包含了一个名为mysql-log-rotate的脚本，不过它比较简单，更详细的日志轮转详见「 Rotating MySQL Slow Logs Safely 」。

…

熟悉Apache的朋友可能会记得 cronolog ，不过Nginx并不支持它，有人通过mkfifo命令曲线救国，先给日志文件创建管道，再搭配cronolog轮转，虽然理论上没有问题，但效率上有折扣。另外，Debian/Ubuntu下有一个简化版工具savelog，有兴趣可以看看。

mysql命令行下怎样实现数据的回滚 *** 作

在MySQL有时执行了错误的update或者delete时导致大量数据错误恢复的办法。执行时没有开启事务，也没有对数据进行。这时就需要使用到sqlbinlog工具。

sqlbinlog需要开启，具体的打开方法就不说了。

使用sqlbinlog会产生bin文件，恢复就需要用到这些文件。文件中记录着数据库的所有 *** 作。（此方法的 *** 作是将数据库之前所执行的语句重新执行一次，以达到恢复效果）

具体步骤：1，先找到bin文件，一般都是在mysql的data文件夹中，结尾以.00000X等形式结束。

2，寻找需要还原的时间点 使用语句 mysqlbinlog 文件名 例（MySQLbinlog xxbin.000001）来查看内容，然后找到对应的具体时间

3，导出sql语句，使用语句 mysqlbinlog 文件名>sql文件路径例(mysqlbinlog xxxbin,00001>>a.sql | mysql -u root -p )

如果需要指定时间导出--start--date -stop='' --date='' 来导出指定时间执行的语句例(sqlbinlog --start-stop='2015-11-22 10:00:00' xxbin.000001>a.sql | mysql -u root -p )这句意思是导出在2015-11-22 10点之前的语句，反之start是导出时间之后的。 start和stop可以同时使用。

如果存在多个bin文件，则按照需要导出。

4，使用mysql将导出的语句执行一次。

---