减少postgresql wal日志配置

转载于德哥:

http://blog.163.com/digoal@126/blog/static/163877040201301522423261/?COLLCC=3918643875&suggestedreading&wumii

reduce PostgreSQL pg_xlog full page writes  

2013-01-15 14:31:56|  分类: PgSQL PerfTuning |字号 订阅

pg_xlog 是 PostgreSQL 可靠性的保证.
今天群里的兄弟聊到归档文件颇多, 如何减少的问题.
简单的方法是通过调整shared_buffer, checkpoint间隔.  
如下 : 
【场景1】 : 
vi postgresql.conf
    
    
shared_buffers = 32MB
checkpoint_segments = 3 
checkpoint_timeout = 1min
重启数据库.
创建测试表 : 
    
    
digoal=> create table test (id int primary key, info text);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE
digoal=> insert into test select generate_series(1,1000000),'DIGOAL';
INSERT 0 1000000
创建检查点 : 
    
    
postgres=# checkpoint;
CHECKPOINT
记下当前的xlog位置.
    
    
postgres=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 96E8/6ABEB740
(1 row)
pgbench脚本 : 
    
    
ocz@db-172-16-3-150-> cat test.sql
\setrandom id 1 1000000
update test set info=clock_timestamp()::text where id=:id;
pgbench测试, 处理80万更新事务 : 
    
    
ocz@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -c 8 -j 4 -t 100000 -U digoal digoal
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 4
number of transactions per client: 100000
number of transactions actually processed: 800000/800000
tps = 4833.566032 (including connections establishing)
tps = 4833.864802 (excluding connections establishing)
statement latencies in milliseconds:
        0.002287        \setrandom id 1 1000000
        1.640042        update test set info=clock_timestamp()::text where id=:id;
测试完后创建检查点, 并查看当前的xlog位置 : 
     
     
postgres=# checkpoint;
CHECKPOINT
digoal=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 96E9/1E7DAF50
(1 row)
计算历经了多少的XLOG数据, 如下 2860MB.  : 
    
    
digoal=# select pg_xlog_location_diff('96E9/1E7DAF50', '96E8/6ABEB740')/1024/1024;
       ?column?        
-----------------------
 2859.9355621337890625
(1 row)

【场景2】
vi $PGDATA/postgresql.conf
修改以下三个参数的值 : 
    
    
shared_buffers = 4096MB
checkpoint_segments = 256
checkpoint_timeout = 5min
xlog文件大小16MB, shared_buffers=4096MB, checkpoint_segments=shared_buffers/xlog文件大小=256;
这几个参数需要配合调节.

重启数据库 : 
    
    
ocz@db-172-16-3-150-> pg_ctl stop -m fast
waiting for server to shut down.... done
server stopped
ocz@db-172-16-3-150-> pg_ctl start
server starting
ocz@db-172-16-3-150-> LOG:  00000: loaded library "pg_stat_statements"
LOCATION:  load_libraries, miscinit.c:1249

创建检查点, 记录当前的xlog位置: 
    
    
ocz@db-172-16-3-150-> psql
psql (9.2.1)
Type "help" for help.
postgres=# checkpoint;
CHECKPOINT
postgres=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 96E9/25FE5558
(1 row)

pgbench测试, 处理80万更新事务 : 
    
    
ocz@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -c 8 -j 4 -t 100000 -U digoal digoal
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 4
number of transactions per client: 100000
number of transactions actually processed: 800000/800000
tps = 35387.346131 (including connections establishing)
tps = 35405.115679 (excluding connections establishing)
statement latencies in milliseconds:
        0.002269        \setrandom id 1 1000000
        0.202819        update test set info=clock_timestamp()::text where id=:id;

测完后, 创建检查点并记录当前的xlog位置 : 
    
    
postgres=# checkpoint;
CHECKPOINT
postgres=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 96E9/35B5FB80
(1 row)

计算历经了多少的xlog, 如下251MB.
    
    
postgres=# select pg_xlog_location_diff('96E9/35B5FB80', '96E9/25FE5558')/1024/1024;
       ?column?       
----------------------
 251.4780654907226563
(1 row)

执行同样的事务量, xlog从2860MB下降到251MB.

【小结】
1. 通过减少block_size的大小也是方法之一, 当然效果没有以上的方法明显. 并且程序编译完后就没有办法修改了.
2. 检查点的间隔太长虽然减少了xlog的产生, 但是如果数据库异常关闭(-m immediate)或者服务器异常导致服务器异常关闭后, 在数据库启动时需要recovery, 这个过程也会拉长. 因为要应用更多的变更. 

【参考】
为什么调了这几个参数能减少xlog的量, 如下 : 
    
    
If full_page_writes is set (as is the default), there is another factor to consider. To ensure data page consistency, the first modification of a data page after each checkpoint results in logging the entire page content. 
In that case, a smaller checkpoint interval increases the volume of output to the WAL log, partially negating the goal of using a smaller interval, and in any case causing more disk I/O.
<think>好的,用户问的是PostgreSQL(PG)能否清空WAL日志文件。我需要先理解WAL是什么,然后分析清空的可能性及方法。 首先,WAL(Write-Ahead Logging)是PostgreSQL的关键机制,用于保证数据的一致性和恢复。所有数据修改都会先写入WAL,再应用到数据文件。因此,WAL文件对数据库的完整性和故障恢复至关重要。 接下来,用户的问题是否可以直接删除或清空这些文件。根据经验,直接手动删除WAL文件是不推荐的,因为可能导致数据库无法正常运行或恢复。PostgreSQL有自动管理WAL的机制,通过检查点(checkpoint)来清理不再需要的旧WAL段。如果WAL文件未被使用且检查点已完成,系统会自动回收。 用户可能有空间不足的问题,或者想手动清理。这时候需要正确的处理方法,比如调整wal_keep_segments参数,减少保留的WAL数量,或者增加checkpoint的频率。此外,使用pg_archivecleanup工具可以清理归档的WAL日志,但需要确保这些文件已经备份并不再需要。 还需要考虑归档模式的情况。如果启用了归档,WAL文件会被保留直到成功归档,这时不能随意删除。需要检查归档状态,确保所有文件已处理完毕。 总结来说,直接清空当前WAL文件不可行,但可以通过配置和工具管理WAL文件,避免空间问题。同时,强调手动删除的风险,比如数据库崩溃或数据丢失,必须谨慎操作。</think>PostgreSQLWAL(Write-Ahead Logging)日志是数据库事务持久性和崩溃恢复的核心机制,直接“清空”WAL文件的操作需谨慎处理。以下是分步说明: --- ### **1. WAL日志的作用** - **数据一致性**:所有数据修改会先写入WAL,再写入数据文件。 - **故障恢复**:通过重放WAL可将数据库恢复到崩溃前的状态。 - **复制基础**:流复制和逻辑解码依赖WAL流。 --- ### **2. 能否直接删除WAL文件?** - **❌ 绝对禁止手动删除当前活跃的WAL文件** 正在使用的WAL文件(如`0000000100000001000000A2`)若被删除,会导致数据库崩溃或数据丢失。 - **✅ 自动清理机制** PostgreSQL通过`checkpoint`自动清理不再需要的旧WAL文件。当所有事务已提交且数据写入数据文件后,旧的WAL段会被回收或删除。 --- ### **3. 如何合理管理WAL文件** #### **方法1:调整参数控制WAL保留** - **`wal_keep_segments`**(或`wal_keep_size`,PostgreSQL 13+) 设置保留的WAL段数量,超出部分自动清理。 示例:`wal_keep_segments = 100` 表示最多保留100个WAL段。 - **`max_wal_size`** 控制WAL目录的最大空间,触发更频繁的checkpoint。 示例:`max_wal_size = 2GB` #### **方法2:手动触发Checkpoint** 执行强制检查点,促使系统回收旧WAL: ```sql CHECKPOINT; ``` #### **方法3:清理归档WAL(仅限归档模式)** 如果启用了WAL归档(`archive_mode = on`),使用工具`pg_archivecleanup`清理已归档的旧WAL: ```bash pg_archivecleanup /path/to/wal_archive 0000000100000001000000A2 ``` 此命令会删除比指定文件名更早的所有归档WAL。 --- ### **4. 高风险操作的后果** - **手动删除活跃WAL文件** 可能导致以下问题: - 数据库服务崩溃(PANIC状态) - 数据无法恢复 - 复制链路中断 - **错误配置参数** 若`wal_keep_segments`设置过小,可能导致复制槽(replication slot)因WAL丢失而阻塞。 --- ### **5. 特殊情况处理** #### **WAL目录占用过大** 1. 检查未清理的原因: ```sql SELECT * FROM pg_ls_waldir() ORDER BY name; ``` 2. 确认是否有未完成的复制槽: ```sql SELECT * FROM pg_replication_slots; ``` 3. 调整参数或删除无效复制槽后,再次触发CHECKPOINT。 --- ### **总结** - **禁止直接删除活跃WAL文件**,依赖PostgreSQL的自动清理机制。 - 通过调整参数(`wal_keep_segments`、`max_wal_size`)和触发CHECKPOINT优化WAL管理。 - 归档模式下使用`pg_archivecleanup`清理已备份的WAL。 - 若出现异常空间占用,需排查复制槽或长事务阻塞问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值