PgSQL · 特性分析 · full page write 机制

理解PostgreSQL的full_page_write机制及其实现原理
最新推荐文章于 2024-08-29 09:34:53 发布
转载 最新推荐文章于 2024-08-29 09:34:53 发布 · 2.1k 阅读 · 0

本文详细介绍了PostgreSQL中full_page_write机制的作用，如何解决断电等带来的坏数据页问题，以及其在在线备份功能中的应用。讨论了full_page_write的实现原理，包括XLogInsert函数在插入记录时的判断机制和redo恢复过程。最后分析了full_page_write的优缺点，并提出了一种优化方案以减少额外的IO和磁盘消耗。

PG默认每个page的大小为8K，PG数据页写入是以page为单位，但是在断电等情况下，操作系统往往不能保证单个page原子地写入磁盘，这样就极有可能导致部分数据块只写到4K(操作系统是一般以4K为单位)，这些“部分写”的页面包含新旧数据的混合。在崩溃后的恢复期间，xlog 里面存储的记录变化信息不够完整，无法完全恢复该页。PG为了解决这类问题，full_page_write机制孕育而生。

什么是full_page_write？

PostgreSQL 在 checkpoint 之后在对数据页面的第一次写的时候会将整个数据页面写到 xlog 里面。当出现主机断电或者OS崩溃时，redo操作时通过checksum发现“部分写”的数据页，并将xlog中保存的这个完整数据页覆盖当前损坏的数据页，然后再继续redo就可以恢复整个数据库了。
除了能够解决断电等带来坏数据页问题外，full_page_write 还应用在在线备份功能上。PG进行全量备份数据库一般通过pg_basebackup工具实现，pg_basebackup类似于copy操作，在此期间，也会出现部分数据页写到一半时文件被copy走了，正是因为full_page_write存在，备份出来的数据库才可以成功恢复启动。所以即便full_page_write=off，在备份时也会被强制自动打开，保证备份成功。

实现原理

full_page_write主要在XLogInsert(插入一条xlog记录)时发挥作用，通过full_page_writer开关状态以及是否是checkpoint后对数据页面的第一次修改(lsn<RedoRecPtr)判断是否需要备份数据页。如果需要备份，那么则把数据页存放在这条记录的末尾，最终写入到xlog中。

doPageWrites = Insert->fullPageWrites || Insert->forcePageWrites;
/* Find info for buffer */
for (i = 0; i < XLR_MAX_BKP_BLOCKS; i++)
{
    if (dtbuf[i] == InvalidBuffer)
    {
    	/* OK, put it in this slot */
    	dtbuf[i] = rdt->buffer;
    	if (doPageWrites && XLogCheckBuffer(rdt, true,&(dtbuf_lsn[i]), &(dtbuf_xlg[i])))
    	{
    		dtbuf_bkp[i] = true;
    		rdt->data = NULL;
    		rdt->len = 0;
    	}
    	break;
    }
    ......
}

在redo恢复的时候只要数据块有备份，那么就是用备份的数据。

/* If we have a full-page image, restore it and we're done */
if (record->xl_info & XLR_BKP_BLOCK(0))
{
	(void) RestoreBackupBlock(lsn, record, 0, false, false);
	return;
}

fullpagewrite

full_page_write不足之处

因为full_page_write需要在xlog中记录数据页，会写更多xlog文件，不仅有数据变化信息，还有数据页本身信息，这样会增加额外的IO和磁盘消耗，同时也会引起主备延迟变大。
为了优化full_page_write，社区提供了一个patch，它的主要设计是创建两个共享内存块队列，checkpoint专用buffer队列和非checkpoint专用buffer队列，同时关闭full_page_write。当用户DML产生的数据buffer需要刷盘时，并不是立即刷到磁盘，而是先进入double write的buffer队列，当buffer队列满时，则将buffer队列里面的数据首先刷到特别的double write文件，然后再将数据刷到数据库文件。通过这种设计就不需要在checkpoint 之后在对数据页面的第一次写的时候会将整个数据页面写到 xlog 里面。当数据库需要恢复的时候，遍历所有double write文件里面的记录块，找到每个记录块对应的数据库page，然后对这个page进行checksum，如果page损坏，那么直接把记录块里面的内容覆盖到buffer数据。最后把double write文件删除，重新初始化buffer队列。

fullpagewrite_2_

总结

把full_page_write这个选项关闭会提高数据库执行速度以及减少xlog数量，但是可能导致系统崩溃或者掉电之后的数据库损坏。如果有减小部分页面写入风险的硬件支持（比如电池供电的磁盘控制器），或者文件系统支持(能够保证page写入原子性)，可以把风险降低到一个可以接受的范围，那么可以考虑关闭这个选项，其他情况下建议打开这个选择。

013、full-page-writes(全页写)
细致-专业-实操
05-26 1199
类似于Oracle表空间热备，当把表空间变成备份状态时，由于备份采用的是操作系统cp命令，在备份时数据块还允许修改，会导致备份的数据块前后状态不一致，为了解决整个问题，备份期间修改的数据块会整个块的写入redolog文件中，此时会导致redolog膨胀。块是数据库最小的I/O单位，当数据库写一个数据块时，操作系统需要I/O多次，可能在I/O过程中系统断电、磁盘故障等等原因导致一个数据块没有完整的写入，导致块不一致。操作系统进行I/O操作时，总是以块为单位，比如512字节、1KB等等。
【0019】 深入分析PostgreSQL中VACUUM 与 VACUUM FULL机制
Postgres 数据库内核开发工程师
09-27 1789
文章目录1. VACUUM概述2. VACUUM分类2.1 2.2 1. VACUUM概述 VACUUM是PostgreSQL中的一个辅助进程，它主要负责完成两个主要任务：删除死元组(Dead Tuples)和冻结事务ID(Freezing Tansaction Ids)。本文主要分享VACUUM删除死元组的具体过程以及底层实现；而对于另一个“冻结事务ID”任务则将单独用一篇文章来介绍，因为它需要结合PostgreSQL的 多版本并发控制 (Multi-Version Concurrency Contro
关于PostgreSQL的full_page_writes
weixin_34367257的博客
06-11 332
前言 full_page_writes用于防范宕机时数据的部分写入导致无法恢复的问题，还有一个好处是加速replay速度，可以避免随机读。但是，full_page_writes对性能的影响也非常大。 和关闭full_page_writes相比，打开full_page_writes可能会使TPS减少30%以上，产生的WAL...
postgresql参数full_page_writes详解
DB_su的博客
10-13 2306
full_page_writes作用:是否开启全页写入,此参数是为了防止块折断（块损坏）的一种策略。造成块折断的原因：linux操作系统文件系统一个块一般是4k,而数据库则一般是一个块8k,当数据库的脏块刷新到磁盘上时,由于底层是两个块组成的,比如刷第一个操作系统块到磁盘上了,而当刷第二个操作系统块的时候发生了停电等突然停机事故,则就发生了块折断（数据块是否折断是根据块的checksum值来检查的）
PG FULL_PAGE_WRITES MYSQL DOUBLE WRITE LOG
jnrjian的博客
09-19 449
执行begin backup之后，oracle会把将要备份的数据文件都标记为hot-backup-in-progress，锁定所要备份的datafile header的scn，例如此时scn=100，同时redolog中会记住这个scn，其他数据文件正常使用，scn会继续增长。之后在备份所要备份的数据文件过程中，数据文件是允许写入和checkpoint，而且可能不止一次checkpoint，而这个过程中的所有操作和checkpoint也会正常记录到redolog与archivelog中。oracle系统数据
PostgreSQL之FULL_PAGE_WRITES
深海微澜
04-24 1891
1、full_page_write是什么？ 官网中，对它的解释是： 当这个参数打开时，PG服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到wal中，这么做是因为在操作系统崩溃恢复期间正在处理的一次页写入可能只有部分完成，从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间，通常存储在wal中的行级改变数据不足以恢复这样一个页面。存储完整的页面映像可以保证页面被正确的存储，但是代价是增加了必须被写入wal的数据量。 可参考：https://postgresqlco.nf/...
PostgreSQL的full_page_writes
好儿郎~志在四方
01-24 1520
一个page默认为8kb，数据的写入是以page为单位的。而操作系统的一个page往往是4kb或者更小，这将导致PostgreSQL在写一个page到磁盘时，操作系统可能会将PG的一个page，分两次写入到磁盘。 如果系统出现故障，则会出现PG的一个page，操作系统只写了一半到磁盘上，这种现象称之为页折断。
【一文搞懂PGSQL】3.进程和关键文件介绍
hh的博客
08-29 1431
PGDATAlog运行日志（pg10之前为PGDATA/log 运行日志（pg10之前为PGDATAlog运行日志（pg10之前为PGDATA/pg_wal 重做日志（pg10之前为$PGDATA/pg_xlog）PGDATA/pg_xact 事务提交日志（pg10之前为$PGDATA/pg_clog）服务器日志，可以在启动的时候指定，比如pg_ctl start -l ./alert.log。
PostgreSQL源码分析——WAL日志（二）
内核思考
06-19 1014
也就是说，并不是当前事务已写入WAL Buffer就可以直接刷入磁盘了，因为是并发写入WAL Buffer，可能存在其他事务先于本事务预留了空间，也就是前面还有WAL日志没有完成刷入WAL Buffer，此时就不能刷入磁盘，否则会造成WAL日志不完整。日志的写入是并发写入，但是备机进行回放或故障恢复时，是串行回放。到这里，其实并没有真正完成日志的写入，因为只是写入了WAL Buffer中，并没有刷入磁盘中，当事务提交时，需要先调用。一旦事务所占用的空间被预留，则数据复制的过程是可以并发的，通过。
PostgreSQL源码分析——数据页校验
内核思考
06-19 1424
我们知道数据库是持久化存储到外存（磁盘）的，而存储介质可能损坏，数据通过IO传输时也有可能传输错误，虽然概率非常低，那么，数据库怎么应对这种情况呢？能否拥有一定的校验能力，检测出这些故障。对此有了数据库数据页校验的能力。
PostgreSQL full_page_write机制
weixin_34032779的博客
12-21 649
title: PgSQL · 特性分析· full_page_write机制 author: 康贤 PG默认每个page的大小为8K，PG数据页写入是以page为单位，但是在断电等情况下，操作系统往往不能保证单个page原子地写入磁盘，这样就极有可能导致部分数据块只写到4K(操作系统是一般以4K为单位)，这些“部分写”的页面包含新旧数据的混合。在崩溃后...
PostgreSQL（十二）全页写-full_page_writes
shmily_coco的博客
03-01 914
在PostgreSQL（十一）WAL日志管理中曾提到过，PG默认记录WAL日志的方式，是将原始SQL转换为特定格式后记录在文件中。但实际上，pg还支持另一种记录WLA日志的方式，那就是全页写-full-page Writes。全页写模式下，会将一整个数据块的内容写入 WAL文件中，而非只记录日志条目。解决块分离问题，保护数据完整性；全页写会导致WAL日志膨胀，增加额外I/O，影响数据库整体性能；使用full_page_writes参数控制on/off .
postgres 源码解析20 Full Page Write全页写机制
Serendipity_Shy
08-28 1081
full page write全页写机制
PostgresSQL关于大页内存
HighGO
12-25 1505
从PostgresSQL 9.4开始添加了服务器参数huge_pages。 使用HugePage会导致更小的page表，并减少CPU在内存管理上花费的时间，从而提高性能。 通常，虚拟页面的默认粒度是4k。对于使用1M虚拟内存的进程，即将虚拟地址映射到物理地址的256个页表项。对于使用1G字节的虚拟内存进行处理，即256000个虚拟页表条目。尽管现代cpus具有tlb来加速虚拟/物理内存映射，但对
fsync和 full_page_writes
HighGO
02-01 1240
先看一下PG官网关于这两个参数的介绍： fsync (boolean) If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various eq
必看!!! 2024 最新 PG 硬核干货大盘点（上）
IvorySQL的博客
06-19 1075
PGConf.dev（原名PGCon，从2007年至2023年）首次在风景如画的加拿大温哥华市举办。此次重新定位的会议带来了全新的视角和多项新的内容，参会体验再次升级。尽管 PGCon 历来更侧重于开发者，吸引来自世界各地的资深开发者、贡献者和研究人员来攻克“棘手难题”，但 PGConf.dev 扩大了其范围，在强调技术讨论的同时，也注重社区贡献。
pg 崩溃恢复篇（一）—— WAL的作用与全页写机制
Hehuyi_In的博客
11-12 5472
WAL（Write Ahead Log）机制最初在7.1版中实现，以减轻服务器崩溃的影响。它也是基于时间点恢复（PITR）和流复制（SR）实现的基础。WAL机制非常复杂，在第一篇中，我们只看看为什么需要WAL，它有什么作用，又会有什么不足。 一、没有WAL的插入操作 要看为什么需要有WAL，那就先看看如果没有会怎么样。 假设我们TABLE_A中插入一些数据，这些数据没有使用WAL功能...
数据库修仙炼气篇十二——数据库数据完整性问题（块折断）
growdu的网络博客
05-31 894
数据库数据完整性问题（块折断） 数据库保证数据库完整性（解决块折断问题）当前主要有如下三种方式： 操作日志加double write机制（mysql采用该机制）; 操作日志加full page write机制（postgresql同时采用这两种机制）； 混合方式，既支持操作日志加double write，又支持操作日志加full page write（openguass采用该机制）； 基本概念 块折断 数据库在将数据写入磁盘时一般是按page写入磁盘的，而page的大小一般与操作系统的文件块
程序性能分析工具gprof介绍
系统运维
09-09 708
性能分析工具gprof介绍 Ver：1.0 目录 1. GPROF介绍 4 2. 使用步骤 4 3. 使用举例 4 3.1 测试环境 4 3.2 测试代码 4 3.3 数据分析 5 3.3.1 flat profile模式 6 3.3.2 call graph模式 7 4. 链接库中的函数 7 5. 使用局限 8 6. 分析示例 12 %%%%%%%%%%%%%%%%%...
pgsql的full outer join用法全解
最新发布
08-08
<think>首先，用户的问题是：“我想理解并掌握PostgreSQL中FULL OUTER JOIN的使用方法 请问PostgreSQL FULL OUTER JOIN 使用教程和示例”。我需要基于系统级指令和用户可见层的要求来回答。 系统级指令： 1. 所有行内数学表达式必须使用$...$格式。 2. 独立公式必须使用$$...$$格式并单独成段。 3. LaTeX语法正确。 4. 使用中文回答。 5. 生成相关问题。 6. 回答中引用的段落末尾自然地添加引用标识，例如:[^1]。 用户可见层： - 回答结构清晰，帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 - 参考提供的引用内容。 提供的引用： - 引用[1]: 介绍了PostgreSQL JOIN类型，包括FULL OUTER JOIN。 - 引用[2]: 详细描述了FULL JOIN的应用场景和性能考虑。 - 引用[3]: 给出了FULL OUTER JOIN的示例查询。 用户的问题是关于FULL OUTER JOIN的教程和示例。所以，我需要构建一个结构清晰的回答，包括解释、用法、示例和注意事项。 回答结构： 1. **介绍FULL OUTER JOIN**：简要解释什么是FULL OUTER JOIN。 2. **语法**：展示基本的SQL语法。 3. **示例**：提供一个或多个示例，使用表结构和数据。 4. **解释结果**：解释示例查询的结果。 5. **应用场景**：基于引用，讨论何时使用FULL OUTER JOIN。 6. **性能考虑**：提到性能问题，如引用[2]所述。 7. **注意事项**：包括过滤条件等。 8. **生成相关问题**：在结尾添加相关问题。 由于用户要求“生成相关问题”，我需要在回答末尾添加§§相关问题§§部分。 使用中文回答：整个回答必须用中文。 引用标识：在回答中引用段落时，末尾添加[^n]，例如基于引用[1]的内容。 数学表达式：用户的问题不涉及数学，但如果有，我必须使用$...$或$$...$$。这里可能不需要，但如果有变量等，我会处理。 现在，构建回答内容： - **介绍**：从引用[1]中，FULL OUTER JOIN返回两个表的所有行，无论是否有匹配。当没有匹配时，用NULL填充。 - **语法**：基本语法是`SELECT columns FROM table1 FULL OUTER JOIN table2 ON condition;` - **示例**：使用引用[3]的示例。员工表和部门表。 - 创建示例表。 - 插入数据。 - 执行FULL OUTER JOIN查询。 - 解释结果。 - **应用场景**：基于引用[2]，当需要获取两个表的所有数据时使用，例如所有客户和所有订单。 - **性能考虑**：FULL JOIN通常性能较差，因为需要处理所有行。 - **注意事项**：添加WHERE条件过滤，如只显示不匹配的行。 生成相关问题： - 例如：1. 如何优化FULL OUTER JOIN的性能？2. FULL OUTER JOIN与INNER JOIN的区别？3. 在实际项目中何时避免使用FULL OUTER JOIN？ 确保回答真实可靠：基于提供的引用内容，并补充一般知识。 最终回答结构： 1. 标题或开头：PostgreSQL FULL OUTER JOIN 教程 2. 解释概念 3. 语法说明 4. 示例代码和解释 5. 应用场景和性能 6. 相关问题</think>### PostgreSQL FULL OUTER JOIN 使用教程和示例 FULL OUTER JOIN（全外连接）是 PostgreSQL 中一种重要的 JOIN 操作，用于合并两个表的所有行，无论它们是否有匹配的记录。当没有匹配时，缺失部分用 NULL 值填充。这在需要全面分析两个数据集时非常有用，例如查找所有员工及其部门（包括没有部门的员工和没有员工的部门）[^1]。下面我将逐步解释其用法，并提供详细示例。 #### 1. **FULL OUTER JOIN 基本概念** - **作用**：返回左表和右表的所有行。如果左表某行在右表无匹配，则右表字段显示 NULL；反之亦然。这确保了不丢失任何数据。 - **语法格式**： ```sql SELECT 列名 FROM 表1 FULL OUTER JOIN 表2 ON 表1.公共字段 = 表2.公共字段; ``` - **与其他 JOIN 的区别**： - `INNER JOIN`：只返回匹配的行。 - `LEFT JOIN`：返回左表所有行 + 匹配的右表行。 - `FULL OUTER JOIN`：覆盖所有情况，包括不匹配的行[^1]。 #### 2. **FULL OUTER JOIN 语法详解** - **核心元素**： - `ON` 子句：指定连接条件，通常基于公共字段（如外键）。 - `SELECT` 列表：选择需要显示的列，建议使用别名避免歧义（例如 `e.employee_name`）。 - **可选扩展**： - 添加 `WHERE` 条件过滤结果，例如只显示不匹配的行。 - 结合 `ORDER BY` 排序结果。 #### 3. **完整示例：员工与部门表** 假设我们有两个表： - **employees 表**：存储员工信息。 - **departments 表**：存储部门信息。 **步骤 1：创建示例表并插入数据** ```sql -- 创建 departments 表 CREATE TABLE departments ( department_id SERIAL PRIMARY KEY, department_name VARCHAR(50) ); -- 创建 employees 表 CREATE TABLE employees ( employee_id SERIAL PRIMARY KEY, employee_name VARCHAR(50), department_id INT REFERENCES departments(department_id) -- 外键关联 ); -- 插入部门数据 INSERT INTO departments (department_name) VALUES ('HR'), ('Engineering'), ('Production'); -- 插入员工数据 INSERT INTO employees (employee_name, department_id) VALUES ('Alice', 1), -- 属于 HR 部门 ('Bob', 2), -- 属于 Engineering 部门 ('Charlie', NULL); -- 无部门（department_id 为 NULL） -- 注意：Production 部门无员工 ``` **步骤 2：执行 FULL OUTER JOIN 查询** ```sql SELECT e.employee_name, d.department_name FROM employees e FULL OUTER JOIN departments d ON d.department_id = e.department_id; ``` **步骤 3：解释查询结果** 运行上述查询后，输出如下： | employee_name | department_name | |---------------|-----------------| | Alice | HR | | Bob | Engineering | | Charlie | NULL | | NULL | Production | - **Alice 和 Bob**：员工与部门匹配，正常显示。 - **Charlie**：员工无部门（`department_name` 为 NULL）。 - **Production**：部门无员工（`employee_name` 为 NULL）[^3]。 #### 4. **高级用法：过滤不匹配的行** 通过添加 `WHERE` 条件，可以只显示没有匹配的记录。例如，查找**所有无部门的员工**： ```sql SELECT e.employee_name, d.department_name FROM employees e FULL OUTER JOIN departments d ON d.department_id = e.department_id WHERE d.department_name IS NULL; -- 只显示无部门的员工 ``` 结果：`Charlie | NULL`。 类似地，查找**所有无员工的部门**： ```sql SELECT e.employee_name, d.department_name FROM employees e FULL OUTER JOIN departments d ON d.department_id = e.department_id WHERE e.employee_name IS NULL; -- 只显示无员工的部门 ``` 结果：`NULL | Production`[^3]。 #### 5. **应用场景与性能考虑** - **典型应用场景**： - 数据完整性检查：例如，确保所有客户都有订单记录，或所有订单都有客户信息。 - 数据报表：生成包含所有可能组合的报告，如员工-部门全视图。 - 数据清洗：识别缺失或孤立记录（如无部门的员工）[^2]。 - **性能注意事项**： - FULL OUTER JOIN 通常比 INNER JOIN 慢，因为它需要扫描两个表的所有行。 - 在大数据集上可能导致内存溢出或查询超时。优化方法包括： - 添加索引：在连接字段（如 `department_id`）上创建索引。 - 限制结果集：使用 `WHERE` 或 `LIMIT` 子句减少输出量。 - 避免在频繁更新的表上使用：考虑分批处理[^2]。 #### 6. **最佳实践** - **测试数据量**：先在小型数据集测试查询，再应用于生产环境。 - **结合其他 JOIN**：有时 `UNION` + `LEFT JOIN`/`RIGHT JOIN` 能替代 FULL OUTER JOIN，性能更好。 - **使用别名**：提高可读性（如 `e` 代表 `employees`）。 - **处理 NULL**：在应用层处理 NULL 值，确保业务逻辑正确。 通过以上教程，您应该能掌握 FULL OUTER JOIN 的核心用法。如需进一步优化或深入应用，可参考 PostgreSQL 官方文档。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值