postgresql日志补充

log基础参数：

log_destination = ‘stderr’
logging_collector = on
log_directory = ‘pg_log’ —可自定义路径
log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log’ —日志文件名
log_line_prefix = ‘%t-%d-%h-%a :’ —日志每行的标准格式

查看慢日志：

postgres@pg pg_log]$ head -3 postgresql-2016-01-14_102534.log
2016-01-14 10:25:34 CST-tinadb-192.168.12.22-[unknown] :LOG: duration: 2920.522 ms statement: select package_name_statistics_single(‘com.hdc’)
2016-01-14 10:25:35 CST-tinadb-192.168.12.166-[unknown] :LOG: duration: 637.073 ms statement: SELECT id FROM t_sample_state ;
2016-01-14 10:25:35 CST-tinadb-192.168.12.22-[unknown] :LOG: duration: 4395.549 ms statement: select t_sfa_sample_tmp_cron_data_singer(‘DBM’,1)

pg_xlog大小：

改变大小需要在编译的时候进行设置：

./configure –with-wal-segsize=target_value 参数，即可设置。

查看默认大小

[postgres@pg pg_xlog]$ ll
…
-rw——- 1 postgres postgres 16777216 Jan 13 12:05 0000000100000F310000009D
-rw——- 1 postgres postgres 16777216 Jan 13 12:15 0000000100000F310000009E
-rw——- 1 postgres postgres 16777216 Jan 13 12:15 0000000100000F310000009F
-rw——- 1 postgres postgres 16777216 Jan 13 12:13 0000000100000F31000000A0
-rw——- 1 postgres postgres 16777216 Jan 13 12:15 0000000100000F31000000A1
—默认每一个大小都是16M

归档后日志查看

[postgres@pg pg_xlog]$ cd archive_status
-rw——- 1 postgres postgres 0 Jan 14 14:39 0000000100000F310000002D.done
-rw——- 1 postgres postgres 0 Jan 14 14:37 0000000100000F310000002C.done
-rw——- 1 postgres postgres 0 Jan 14 14:35 0000000100000F310000002B.done
-rw——- 1 postgres postgres 0 Jan 14 14:32 0000000100000F310000002A.done
-rw——- 1 postgres postgres 0 Jan 14 14:31 0000000100000F3100000029.done
–每个pg_xlog完成了归档后，都会在这里面生成一个.done的文件

WAL相关参数（参考网络）

fsync = on # turns forced synchronization on or off
该参数直接控制日志是否先写入磁盘。默认值是ON(先写入)。配置该参数为OFF，更新数据写入磁盘完全不用等待WAL的写入完成，
节省了时间，提高了性能。其直接隐患是无法保证在系统崩溃时最近的事务能够得到恢复，也就无法保证相关数据的真实与正确性。

synchronous_commit = on # synchronization level; on, off, or local
该参数表明是否等待WAL完成后才返回给用户事务的状态信息，默认值是ON.因参数只是控制事务的状态反馈，因此对于数据的一致性不存在风险。
但事务的状态信息影响着数据库的整个状态。该参数可以灵活的配置，对于业务没有严谨要求的事务可以配置为OFF，能够为系统的性能带来不小的提升。

wal_writer_delay = 200ms
WAL writer进程的间歇时间。默认值是200ms。准确的配置应该根据自身系统的运行状况。如果时间过长可能造成WAL buffer
的内存不足；反之过小将会引起WAL的不断的写入，对磁盘的IO也是很大考验。

commit_delay:
一个已经提交的数据在WAL buffer中存放的时间，单位ms，默认值是0，不用延迟。非0值表示可能存在多个事务的WAL同时写入磁盘。
如果设置为非0，表明了某个事务执行commit后不会立即写入WAL中，而仍存放在WAL buffer中，这样对于后面的事务申请WAL buffer时非常不利，尤其是提交事务较多的高峰期，可能引起WAL buffer内存不足。如果内存足够大，可以尽量延长该参数值，能够使数据集中写入这样降低了系统的IO，提高了性能。同样如果此时崩溃数据面临着丢失的危险。个人建议采用默认值，同时将WAL文件存放在IO性能好的磁盘上。

WAL日志的个数

先看几个相关的参数

checkpoint_segments = 128 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 20min # range 30s-1h
checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
wal_keep_segments = 1024

checkpoint执行控制:
1）数据量达到checkpoint_segments*16M时，系统自动触发；
2）时间间隔达到checkpoint_timeout参数值时;
3）用户发出checkpoint命令时。

说明：
1）checkpoint_segments 值默认为 3，这个值较小，建议设置成32以上，如果业务很繁忙，这个参数还应该调大，当然在恢复时也意味着恢复时间较长，这个需要综合考虑。
2）checkpoint_timeout 默认5分钟，系统自动执行checkpoint之间的最大时间间隔，同样间隔越大介质恢复的时间越长。
3）checkpoint_completion_target 默读值为 0.5,这个通常保持默认值即可。表示每个checkpoint需要在checkpoints间隔时间的50%内完成。

最大的日志数据估计方法（网上介绍的，只能是个大概值，也有可能会超过）

通常地说，WAL segment 最大个数不超过  (2+checkpoint_completion_target)*checkpoint_segments + 1 在流复制环境下， WAL最大数不超过 wal_keep_segments+checkpoint_segments+1 

主机 pg_xlog 日志数

[root@pg pg_xlog]# ll |wc -l
1284

清理pg_xlog

修改参数:
wal_keep_segments = 512

reload 配置文件:
pg_ctl reload -D $PGDATA

执行一次checkpoint

部分pg_xlog 日志已被删除，空间使用率降下去了，我们可以不手动操作，因为checkpoint操作数据库会自动执行，执行频率由参数checkpoint_timeout控制。

—记住千万不要直接物理删除rm之类的。

pg_clog

pg_clog这个文件也是事务日志文件，但与pg_xlog不同的是它记录的是事务的元数据(metadata)，这个日志告诉我们哪些事务完成了，哪些没有完成。这个日志文件一般非常小，但是重要性也是相当高，不得随意删除或者对其更改信息。

[root@pg-ro pg_clog]# ll -t |head -10
total 48904
-rw——- 1 postgres postgres 24576 Jan 14 14:41 0962
-rw——- 1 postgres postgres 262144 Jan 14 14:01 0961
-rw——- 1 postgres postgres 262144 Jan 14 04:19 0960
-rw——- 1 postgres postgres 262144 Jan 13 17:02 095F
-rw——- 1 postgres postgres 262144 Jan 13 06:02 095E
-rw——- 1 postgres postgres 262144 Jan 12 11:03 095D