和Oracle 一样, PostgreSQL也有着比较完善的日志写入流程,也是在将缓存的数据刷入到磁盘之前,先写日志, 这就是PostgreSQL WAL ( Write-Ahead Log )方式,中文为预写日志方式, 那么PG的日志数据是如何确定各数的呢?这个问题困扰了我很久,今天总算有了比较清明的理解,写出来,给有需要的人分享。
WAL 相关参数
checkpoint_segments (integer)
Maximum number of log file segments between automatic WAL checkpoints (each segment is normally 16 megabytes). The default is three segments. Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.
checkpoint_timeout (integer)
Maximum time between automatic WAL checkpoints, in seconds. The default is five minutes (5min). Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.
checkpoint_completion_target (floating point)
Specifies the target of checkpoint completion, as a fraction of total time between checkpoints. The default is 0.5. This parameter can only be set in the postgresql.conf file or on the server command line.
WAL 文件数估计方法
通常地说,WAL segment 最大个数不超过如下:
1 |
( 2 + checkpoint_completion_target ) * checkpoint_segments + 1 |
在流复制环境下, WAL 最大数不超过如下:
1 |
wal_keep_segments + checkpoint_segments + 1 |
WAL 文件数验证
主机 pg_xlog 日志数
1 |
[postgres@172_16_3_216 pg_root]$ ll $PGDATA/pg_xlog | wc -l |
当前 checkpoint_segments 值
1 |
postgres=# show checkpoint_segments; |
备注: 当前数据库的 checkpoint_segments 的值为 64, 而目前操作系统上 wal segments 为 131 ( 除去 pg_xlog 中的 archive_status), 上面的公式符合。
WAL Segments 占用空间计算
由于 wal segments 日志个数会在一个范围变化,因此占用空间会随着 wal segments 个数变化,那么在设置 checkpoint_segments 参数时,需要考虑到PG SERVER 最多会产生多少个 wal segments 并且,并且最多会占用多少硬盘空间,下面是一个统计,前提条件: 每个 wal segments 为 16 M, 即系统的默认值。
如何设置 WAL Segments 大小?
默认的 WAL segments 为 16 M, 这个参数在PG server 编译时指定,当执行 ./configure
时,指定 “–with-wal-segsize=target_value” 参数,即可设置。
总结
-
checkpoint_segments 值默认为 3, 这个值较小,建议设置成32以上,如果业务很繁忙,这个参数
还应该调大,当然在恢复时也意味着恢复时间较长,这个需要综合考虑。 -
checkpoint_completion_target 默读值为 0.5,这个通常保持默认值即可。
原创文章,作者:6024010,如若转载,请注明出处:https://blog.ytso.com/tech/database/236380.html