PostgreSQL 9.6 理解wal文件
PostgreSQL 9.6 understanding wal files
我正在尝试了解 wal 文件的行为。数据库的wal相关设置如下：
"min_wal_size" "2GB"
"max_wal_size" "20GB"
"wal_segment_size" "16MB"
"wal_keep_segments" "0"
"checkpoint_completion_target" "0.8"
"checkpoint_timeout" "15min"
wal 文件数始终为 1281 或更高：
SELECT COUNT(*) FROM pg_ls_dir('pg_xlog') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';
-- count 1281
据我了解，这意味着 wal 文件目前永远不会低于 max_wal_size (1281 * 16 MB = 20496 MB = max_wal_size) ??
我希望在到达检查点并将数据同步到磁盘后，wal 文件的数量会立即减少到最大值以下。但事实显然并非如此。我错过了什么？
As per the documentation（强调已添加）：
The number of WAL segment files in pg_xlog directory depends on min_wal_size, max_wal_size and the amount of WAL generated in previous checkpoint cycles. When old log segment files are no longer needed, they are removed or recycled (that is, renamed to become future segments in the numbered sequence). If, due to a short-term peak of log output rate, max_wal_size is exceeded, the unneeded segment files will be removed until the system gets back under this limit. Below that limit, the system recycles enough WAL files to cover the estimated need until the next checkpoint, and removes the rest
因此，根据您的观察，您可能正在观察 "recycle" 效果——旧的 WAL 文件被重命名而不是被删除。这可以节省一些磁盘 I/O，尤其是在繁忙的系统上。
请记住，一旦一个特定的文件被回收，在它被使用（即达到相关的 LSN 并 checkpointed 之前），它不会被再次考虑 removal/recycle .如果您的系统突然变得不那么活跃，这可能需要很长时间。
如果您的服务器非常繁忙，然后突然变得大部分空闲，您可能会遇到这样一种情况，即日志失败会在 max_wal_size 停留很长时间。在决定是删除还是回收文件时，它很快就用完了，因此决定回收最多 max_wal_size 以供 预测的未来使用 ，而不是删除他们。一旦回收，它们将永远不会被删除，直到它们被使用（你可能会争辩说这是一个错误），如果服务器现在大部分空闲，它们将需要很长时间才能被使用并因此被删除。
我正在尝试了解 wal 文件的行为。数据库的wal相关设置如下：
"min_wal_size" "2GB"
"max_wal_size" "20GB"
"wal_segment_size" "16MB"
"wal_keep_segments" "0"
"checkpoint_completion_target" "0.8"
"checkpoint_timeout" "15min"
wal 文件数始终为 1281 或更高：
SELECT COUNT(*) FROM pg_ls_dir('pg_xlog') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';
-- count 1281
据我了解，这意味着 wal 文件目前永远不会低于 max_wal_size (1281 * 16 MB = 20496 MB = max_wal_size) ??
我希望在到达检查点并将数据同步到磁盘后，wal 文件的数量会立即减少到最大值以下。但事实显然并非如此。我错过了什么？
As per the documentation（强调已添加）：
The number of WAL segment files in
pg_xlogdirectory depends onmin_wal_size,max_wal_sizeand the amount of WAL generated in previous checkpoint cycles. When old log segment files are no longer needed, they are removed or recycled (that is, renamed to become future segments in the numbered sequence). If, due to a short-term peak of log output rate,max_wal_sizeis exceeded, the unneeded segment files will be removed until the system gets back under this limit. Below that limit, the system recycles enough WAL files to cover the estimated need until the next checkpoint, and removes the rest
因此，根据您的观察，您可能正在观察 "recycle" 效果——旧的 WAL 文件被重命名而不是被删除。这可以节省一些磁盘 I/O，尤其是在繁忙的系统上。
请记住，一旦一个特定的文件被回收，在它被使用（即达到相关的 LSN 并 checkpointed 之前），它不会被再次考虑 removal/recycle .如果您的系统突然变得不那么活跃，这可能需要很长时间。
如果您的服务器非常繁忙，然后突然变得大部分空闲，您可能会遇到这样一种情况，即日志失败会在 max_wal_size 停留很长时间。在决定是删除还是回收文件时，它很快就用完了，因此决定回收最多 max_wal_size 以供 预测的未来使用 ，而不是删除他们。一旦回收，它们将永远不会被删除，直到它们被使用（你可能会争辩说这是一个错误），如果服务器现在大部分空闲，它们将需要很长时间才能被使用并因此被删除。