ITPub博客

首页 > 数据库 > PostgreSQL > PostgreSQL DBA(20) - WAL full-page-write浅析

PostgreSQL DBA(20) - WAL full-page-write浅析

原创 PostgreSQL 作者:husthxd 时间:2018-12-26 12:33:28 0 删除 编辑

PG以page(大小默认为8K)为基本的存储单元,但OS的存取单元(block)不一定是8k,常见的是4k,而且物理持久化存储块设备扇区大小是512字节,这些不一致的情况会导致PG page的读写不是原子操作,也就是说可能会出现page的部分写问题:
在写一个page的时候,部分写入成功但部分写入失败,这时候的page中的内容是不一致的,也就是说这个page已经被损坏(corrupted page)。为了解决这个问题,PG引入了full-page-write的机制。

一、full-page-write的机制

考察以下的情况(为方便起见,省略了buffer等相关的信息):


full-page-write

在T1,数据库成功执行checkpoint;
在T2,执行DML语句,这时候相关的数据会写入到WAL中(此处忽略了WAL buffer);
在T3,提交该事务;
在T4,bgwriter把dirty pages写入到Data file中,但在写入过程中机器出现故障导致Crash(如掉电等),出现了部分写的情况。
为了应对这种情况,PG在T2写入WAL的时候,会把出现变化的page整页写入到WAL中,而不仅仅是tuple data。在数据库重启执行恢复的时候,在Redo point开始回放WAL时,如发现XLOG Record是FPI(full-page-image),则整页替换,通过这种机制解决了部分写的问题。

二、full-page-write的代价

当然这种机制不是免费的,其主要的负面影响是写放大。
由于整页写,不可避免的出现冗余数据;考虑这么一种情况:如果数据库很繁忙,而且数据的热点分散在不同的table上,同时checkpoint执行间隔较短,那非常多的page就会通过full-page-write写入的WAL中,导致日志空间快速膨胀。在极端情况下,page“满载”(基本没有空闲空间)的情况下更新其中一条记录都会导致整页写入WAL。
关于这部分的机制和解决方案,参考资料中的《如何遏制PostgreSQL WAL的疯狂增长》有详细论述。

三、参考资料

Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的疯狂增长
PostgreSQL 可靠性分析 - 关于redo block原子写

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/6906/viewspace-2374773/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
ITPUB数据库版块资深版主,对Oracle、PostgreSQL有深入研究。

注册时间:2007-12-28

  • 博文量
    1472
  • 访问量
    3905196