重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
在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),则整页替换,通过这种机制解决了部分写的问题。
创新互联公司-专业网站定制、快速模板网站建设、高性价比龙潭网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式龙潭网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖龙潭地区。费用合理售后完善,十多年实体公司更值得信赖。
当然这种机制不是免费的,其主要的负面影响是写放大。
由于整页写,不可避免的出现冗余数据;考虑这么一种情况:如果数据库很繁忙,而且数据的热点分散在不同的table上,同时checkpoint执行间隔较短,那非常多的page就会通过full-page-write写入的WAL中,导致日志空间快速膨胀。在极端情况下,page“满载”(基本没有空闲空间)的情况下更新其中一条记录都会导致整页写入WAL。
关于这部分的机制和解决方案,参考资料中的《如何遏制PostgreSQL WAL的疯狂增长》有详细论述。
Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的疯狂增长
PostgreSQL 可靠性分析 - 关于redo block原子写