第六章 清理过程
- 1. 概念
- 2. 并发清理
- 2.1 清理过程
- 2.1.1 第一部分:冻结处理
- 2.1.2 第二部分:移除死元组
- 2.2 可见性映射
- 2.3 冻结过程
- 3. 完整清理(FULL VACUUM)
1. 概念
清理(VACUUM)是一种维护过程,有助于PostgreSQL的持久运行。
两个主要任务:
1.删除死元组
为了删除死元组,清理过程有两种模式:并发清理(Concurrent Vacuum) 与完整清理(Full Vacuum)
并发清理:会删除表文件每个页面中的死元组,而其他事务可以在其运行时继续读取该表。
完整清理:不仅会移除整个文件中所有的死元组,还会对整个文件中所有的活元组进行碎片整理。而其他事务在完整清理运行时无法访问该表。
2.冻结事务标识
2. 并发清理
清理过程为指定的表,或数据库中的所有表执行以下任务。
1.移除死元组
- 移除每一页中的死元组,并对每一页内的活元组进行碎片整理。
- 移除指向死元组的索引元组。
2.冻结旧的事务标识(txid)
- 如有必要,冻结旧元组的事务标识(txid)。
- 更新与冻结事务标识相关的系统视图(pg_database与pg_class)。
- 如果可能,移除非必需的提交日志(clog)。
3.其他
- 更新已处理表的空闲空间映射(FSM)和可见性映射(VM)。
- 更新一些统计信息(pg_stat_all_tables等)。
2.1 清理过程
2.1.1 第一部分:冻结处理
- 扫描所有页面,定位死元组;如有必要,冻结过老的元组。
- 如果存在,移除指向死元组的索引元组。
2.1.2 第二部分:移除死元组
这一部分会移除死元组,并逐页更新FSM(空闲空间映射)和VM(可见性映射)
假设该表包含三个页面,这里先关注0号页面(即第一个页面)。该页面包含三条元组, 其中Tuple_2是一条死元组,如图6.1(1)所示。在这里PostgreSQL移除了Tuple_2,并重排剩余元组来整理碎片空间,然后更新该页面的FSM和VM,如图6.1(2)所示。 PostgreSQL不断重复该过程直至最后一页。
2.2 可见性映射
清理过程的代价高昂,因此PostgreSQL在8.4版中引入了VM,用于减小清理的开销。
VM的基本概念很简单。 每个表都拥有各自的可见性映射,用于保存表文件中每个页面的可见性。 页面的可见性确定了每个页面是否包含死元组。清理过程可以跳过没有死元组的页面。
图6.2展示了VM的使用方式。 假设该表包含三个页面,第0页和第2页包含死元组,而第1页不包含死元组。 表的可见性映射中保存着哪些页面包含死元组的信息。 在这种情况下,清理过程可以参考VM中的信息,跳过第一个页面。
2.3 冻结过程
冻结过程通常以惰性模式运行;但当满足特定条件时,也会以迫切模式运行。
- 在惰性模式下,冻结处理仅使用目标表对应的VM扫描包含死元组的页面。
- 迫切模式相则反,它会扫描所有的页面,无论其是否包含死元组,它还会更新与冻结处理相关的系统视图,并在可能的情况下删除不必要的clog。
3. 完整清理(FULL VACUUM)
虽然并发清理对于运维至关重要,但光有它还不够。比如,即使删除了许多死元组,也无法压缩表大小的情况。
图6.8给出了一个极端的例子。假设一个表由三个页面组成,每个页面包含六条元组。执行以下DELETE命令以删除元组,并执行VACUUM命令以移除死元组:
死元组虽然都被移除了,但表的尺寸没有减小。 这种情况既浪费了磁盘空间,又会对数据库性能产生负面影响。 例如在上面的例子中,当读取表中的三条元组时,必须从磁盘加载三个页面。
为了解决这种情况,PostgreSQL提供了完整清理模式。 图6.9概述了该模式。
1.创建新的表文件:见图6.9(1)
当对表执行VACUUM FULL命令时,PostgreSQL首先获取表上的AccessExclusiveLock锁,并创建一个大小为8 KB的新的表文件。 AccessExclusiveLock锁不允许任何其他访问。
2.将活元组复制到新表:见图6.9(2)
PostgreSQL只将旧表文件中的活元组复制到新表中。
删除旧文件,重建索引,并更新统计信息,FSM和VM,见图6.9(3)
复制完所有活元组后,PostgreSQL将删除旧文件,重建所有相关的表索引,更新表的FSM和VM,并更新相关的统计信息和系统视图。