PostgreSQL 维护任务进度报告概述
PostgreSQL 提供了一系列的工具和视图来帮助数据库管理员监控各种维护任务的进度。
1. ANALYZE 进度报告
ANALYZE 是一个用于收集统计信息的命令,以便优化器可以更好地决定查询计划。在 PostgreSQL 中,可以通过使用 pg_stat_progress_analyze 视图来监控 ANALYZE 进程的进度。
2. CLUSTER 和 VACUUM FULL 进度报告
CLUSTER 命令重新组织表中的行,以物理上按照索引排序的方式存储它们。VACUUM FULL 则重新排序表中的行并回收已删除行的空间。这两种命令都会重写整个表,并且可以使用 pg_stat_progress_cluster 视图来查看它们的进度。
3. COPY 进度报告
COPY 命令用于从标准输入或文件中读取数据并将其插入到表中,或者从表中读取数据并将其输出到标准输出或文件中。COPY 的进度报告可通过 pg_stat_progress_copy 视图获取。
4. CREATE INDEX 进度报告
创建索引 (CREATE INDEX) 的进度可以通过 pg_stat_progress_create_index 视图来查看。这有助于了解创建索引操作的进展情况。
5. VACUUM 进度报告
VACUUM 命令用于清理表中的废弃行并更新统计信息。VACUUM 的进度报告可以通过 pg_stat_progress_vacuum 视图获取。
6. 基础备份进度报告
基础备份是创建数据库完整副本的过程,通常用于灾难恢复。pg_basebackup 命令用于创建基础备份,其进度可以通过 pg_stat_progress_basebackup 视图来监控。
ANALYZE 进度报告
每当 ANALYZE 命令运行时,视图 pg_stat_progress_analyze 将包含一条记录,表示正在执行 ANALYZE 命令的每个后端(进程)。以下表格描述了 pg_stat_progress_analyze 视图中报告的信息及其解释。
pg_stat_progress_analyze 视图
列名 | 类型 | 描述 |
pid | integer | 后端(进程)的 ID。 |
datid | oid | 后端所连接数据库的 OID。 |
datname | name | 后端所连接数据库的名称。 |
relid | oid | 正在分析的表的 OID。 |
phase | text | 当前处理阶段。参见下表。 |
sample_blks_total | bigint | 将要采样的堆块总数。 |
sample_blks_scanned | bigint | 已扫描的堆块数。 |
ext_stats_total | bigint | 扩展统计信息的数量。 |
ext_stats_computed | bigint | 已计算的扩展统计信息的数量。此计数器仅在 phase 为 computing extended statistics 时递增。 |
child_tables_total | bigint | 子表的数量。 |
child_tables_done | bigint | 已扫描的子表数量。此计数器仅在 phase 为 acquiring inherited sample rows 时递增。 |
current_child_table_relid | oid | 当前正在扫描的子表的 OID。此字段仅在 phase 为 acquiring inherited sample rows 时有效。 |
ANALYZE 阶段
阶段 | 描述 |
initializing | 命令正在准备开始扫描堆。这一阶段预计很短暂。 |
acquiring sample rows | 命令正在扫描由 relid 指定的表以获取样本行。 |
acquiring inherited sample rows | 命令正在扫描子表以获取样本行。child_tables_total, child_tables_done, 和 current_child_table_relid 列包含此阶段的进度信息。 |
computing statistics | 命令正在根据表扫描期间获取的样本行计算统计信息。 |
computing extended statistics | 命令正在根据表扫描期间获取的样本行计算扩展统计信息。 |
finalizing analyze | 命令正在更新 pg_class 表。当这一阶段完成时,ANALYZE 命令将结束。 |
注意
当 ANALYZE 命令运行在分区表上时,其所有的子分区也会被递归分析。在这种情况下,进度首先为父表报告,其中收集继承的统计信息,然后为每个子分区报告。
通过监视 pg_stat_progress_analyze 视图,你可以了解 ANALYZE 命令的执行进度,包括扫描了多少堆块、计算了多少统计信息等。这对于理解 ANALYZE 命令的执行过程和性能影响非常有用。
CLUSTER 和 VACUUM FULL 进度报告
每当 CLUSTER 或 VACUUM FULL 命令运行时,视图 pg_stat_progress_cluster 将包含一条记录,表示正在执行这些命令的每个后端(进程)。以下表格描述了 pg_stat_progress_cluster 视图中报告的信息及其解释。
pg_stat_progress_cluster 视图
列名 | 类型 | 描述 |
pid | integer | 后端(进程)的 ID。 |
datid | oid | 后端所连接数据库的 OID。 |
datname | name | 后端所连接数据库的名称。 |
relid | oid | 正在聚簇或完全清理的表的 OID。 |
command | text | 正在运行的命令:CLUSTER 或 VACUUM FULL。 |
phase | text | 当前处理阶段。参见下表。 |
cluster_index_relid | oid | 如果表使用索引进行扫描,则为使用的索引的 OID;否则为零。 |
heap_tuples_scanned | bigint | 已扫描的堆元组数。此计数器仅在 phase 为 seq scanning heap, index scanning heap, 或 writing new heap 时递增。 |
heap_tuples_written | bigint | 已写入的堆元组数。此计数器仅在 phase 为 seq scanning heap, index scanning heap, 或 writing new heap 时递增。 |
heap_blks_total | bigint | 表中的堆块总数。此数字在 seq scanning heap 阶段开始时报告。 |
heap_blks_scanned | bigint | 已扫描的堆块数。此计数器仅在 phase 为 seq scanning heap 时递增。 |
index_rebuild_count | bigint | 重建的索引数。此计数器仅在 phase 为 rebuilding index 时递增。 |
CLUSTER 和 VACUUM FULL 阶段
阶段 | 描述 |
initializing | 命令正在准备开始扫描堆。这一阶段预计很短暂。 |
seq scanning heap | 命令正在使用顺序扫描扫描表。 |
index scanning heap | CLUSTER 命令正在使用索引扫描表。 |
sorting tuples | CLUSTER 命令正在排序元组。 |
writing new heap | CLUSTER 命令正在写入新的堆。 |
swapping relation files | 命令正在将新构建的文件交换到位。 |
rebuilding index | 命令正在重建索引。 |
performing final cleanup | 命令正在进行最终清理。当这一阶段完成时,CLUSTER 或 VACUUM FULL 命令将结束。 |
COPY 进度报告
每当 COPY 命令运行时,视图 pg_stat_progress_copy 将包含一条记录,表示正在执行 COPY 命令的每个后端(进程)。以下表格描述了 pg_stat_progress_copy 视图中报告的信息及其解释。
pg_stat_progress_copy 视图
列名 | 类型 | 描述 |
pid | integer | 后端(进程)的 ID。 |
datid | oid | 后端所连接数据库的 OID。 |
datname | name | 后端所连接数据库的名称。 |
relid | oid | COPY 命令执行的表的 OID。如果是从查询复制,则设置为零。 |
command | text | 正在运行的命令:COPY FROM, COPY TO。 |
type | text | 数据读取或写入的 IO 类型:FILE, PROGRAM, PIPE, 或 CALLBACK。 |
bytes_processed | bigint | 命令已处理的字节数。 |
bytes_total | bigint | 对于 COPY FROM 命令,源文件的字节数。如果不可用,则设置为零。 |
tuples_processed | bigint | 命令已处理的元组数。 |
tuples_excluded | bigint | 因为 WHERE 子句排除而未处理的元组数。 |
通过监视 pg_stat_progress_cluster 和 pg_stat_progress_copy 视图,你可以了解 CLUSTER, VACUUM FULL, 和 COPY 命令的执行进度,包括扫描了多少堆块、写入了多少堆元组、处理了多少字节和元组等。这对于理解这些命令的执行过程和性能影响非常有用。
CREATE INDEX 进度报告
PostgreSQL 支持在执行 CREATE INDEX 和 REINDEX 命令时报告进度,这有助于数据库管理员监控长时间运行的索引创建和重建操作。以下是针对 CREATE INDEX 和 REINDEX 命令进度报告的详细说明。
每当 CREATE INDEX 或 REINDEX 命令运行时,视图 pg_stat_progress_create_index 将包含一条记录,表示正在创建索引的每个后端(进程)。以下表格描述了 pg_stat_progress_create_index 视图中报告的信息及其解释。
pg_stat_progress_create_index 视图
列名 | 类型 | 描述 |
pid | integer | 创建索引的后端(进程)的 ID。 |
datid | oid | 后端所连接数据库的 OID。 |
datname | name | 后端所连接数据库的名称。 |
relid | oid | 正在创建索引的表的 OID。 |
index_relid | oid | 正在创建或重建的索引的 OID。在非并发 CREATE INDEX 时,此值为 0。 |
command | text | 具体命令类型:CREATE INDEX, CREATE INDEX CONCURRENTLY, REINDEX, 或 REINDEX CONCURRENTLY。 |
phase | text | 当前索引创建的处理阶段。参见下表。 |
lockers_total | bigint | 在适用的情况下,需要等待的锁持有者的总数。 |
lockers_done | bigint | 已经等待过的锁持有者的数量。 |
current_locker_pid | bigint | 当前正在等待的锁持有者的进程 ID。 |
blocks_total | bigint | 在当前阶段需要处理的块总数。 |
blocks_done | bigint | 在当前阶段已经处理的块数。 |
tuples_total | bigint | 在当前阶段需要处理的元组总数。 |
tuples_done | bigint | 在当前阶段已经处理的元组数。 |
partitions_total | bigint | 需要创建或附加索引的分区总数,包括直接和间接分区。在 REINDEX 期间,或当索引不是分区索引时,此值为 0。 |
partitions_done | bigint | 已经创建或附加索引的分区数量,包括直接和间接分区。在 REINDEX 期间,或当索引不是分区索引时,此值为 0。 |
CREATE INDEX 阶段
阶段 | 描述 |
initializing | CREATE INDEX 或 REINDEX 正在准备创建索引。这一阶段预计很短暂。 |
waiting for writers before build | CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 正在等待具有写锁的事务完成,这些事务可能看到表。此阶段在非并发模式下会被跳过。lockers_total, lockers_done, 和 current_locker_pid 列包含此阶段的进度信息。 |
building index | 索引正在由特定访问方法的代码构建。在此阶段,支持进度报告的访问方法会填写自己的进度数据,子阶段将在这一列中指示。通常 blocks_total, blocks_done, tuples_total, 和 tuples_done 将包含进度数据。 |
waiting for writers before validation | CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 正在等待具有写锁的事务完成,这些事务可能写入表。此阶段在非并发模式下会被跳过。lockers_total, lockers_done, 和 current_locker_pid 列包含此阶段的进度信息。 |
index validation: scanning index | CREATE INDEX CONCURRENTLY 正在扫描索引,寻找需要验证的元组。此阶段在非并发模式下会被跳过。blocks_total(设置为索引的总大小)和 blocks_done 包含此阶段的进度信息。 |
index validation: sorting tuples | CREATE INDEX CONCURRENTLY 正在对索引扫描阶段的输出进行排序。 |
index validation: scanning table | CREATE INDEX CONCURRENTLY 正在扫描表以验证之前两阶段收集的索引元组。此阶段在非并发模式下会被跳过。blocks_total(设置为表的总大小)和 blocks_done 包含此阶段的进度信息。 |
waiting for old snapshots | CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 正在等待可以看到表的事务释放它们的快照。此阶段在非并发模式下会被跳过。lockers_total, lockers_done, 和 current_locker_pid 列包含此阶段的进度信息。 |
waiting for readers before marking dead | REINDEX CONCURRENTLY 正在等待对表具有读锁的事务完成,在标记旧索引为死亡之前。此阶段在非并发模式下会被跳过。lockers_total, lockers_done, 和 current_locker_pid 列包含此阶段的进度信息。 |
waiting for readers before dropping | REINDEX CONCURRENTLY 正在等待对表具有读锁的事务完成,在删除旧索引之前。此阶段在非并发模式下会被跳过。lockers_total, lockers_done, 和 current_locker_pid 列包含此阶段的进度信息。 |
通过监视 pg_stat_progress_create_index 视图,你可以了解 CREATE INDEX 和 REINDEX 命令的执行进度,包括扫描了多少块、处理了多少元组等。这对于理解这些命令的执行过程和性能影响非常有用。
VACUUM 进度报告
PostgreSQL 支持在执行 VACUUM 命令时报告进度,这有助于数据库管理员监控长时间运行的表清理操作。以下是针对 VACUUM 命令进度报告的详细说明。
每当 VACUUM 命令运行时,视图 pg_stat_progress_vacuum 将包含一条记录,表示正在执行 VACUUM 命令的每个后端(包括自动清理工作进程)。以下表格描述了 pg_stat_progress_vacuum 视图中报告的信息及其解释。
pg_stat_progress_vacuum 视图
列名 | 类型 | 描述 |
pid | integer | 后端(进程)的 ID。 |
datid | oid | 后端所连接数据库的 OID。 |
datname | name | 后端所连接数据库的名称。 |
relid | oid | 正在清理的表的 OID。 |
phase | text | 当前 VACUUM 的处理阶段。参见下表。 |
heap_blks_total | bigint | 表中的堆块总数。此数字在扫描开始时报告;之后添加的块不会被访问。 |
heap_blks_scanned | bigint | 已扫描的堆块数。由于使用可见性映射来优化扫描,一些块会在未经检查的情况下被跳过;跳过的块也计入总数,因此此数字最终会等于 heap_blks_total 当 VACUUM 完成时。此计数器仅在 phase 为 scanning heap 时递增。 |
heap_blks_vacuumed | bigint | 已清理的堆块数。除非表没有索引,否则此计数器仅在 phase 为 vacuuming heap 时递增。含有无死亡元组的块会被跳过,因此计数器有时会大幅度跳跃前进。 |
index_vacuum_count | bigint | 完成的索引清理周期数。 |
max_dead_tuples | bigint | 可以存储的死亡元组数量,在需要执行索引清理周期之前,基于 maintenance_work_mem。 |
num_dead_tuples | bigint | 自上次索引清理周期以来收集的死亡元组数量。 |
VACUUM 阶段
阶段 | 描述 |
initializing | VACUUM 正在准备开始扫描堆。这一阶段预计很短暂。 |
scanning heap | VACUUM 正在扫描堆。它将根据需要修剪和解碎片化每一页,并可能执行冻结操作。heap_blks_scanned 列可用于监控扫描的进度。 |
vacuuming indexes | VACUUM 正在清理索引。如果表有任何索引,这将在堆被完全扫描后至少发生一次。它可能在每次 VACUUM 期间多次发生,如果 maintenance_work_mem(或对于自动清理,如果设置了 autovacuum_work_mem)不足以存储找到的死亡元组数量。 |
vacuuming heap | VACUUM 正在清理堆。清理堆与扫描堆不同,并且发生在每次清理索引之后。如果 heap_blks_scanned 小于 heap_blks_total,系统将在该阶段完成后返回扫描堆;否则,它将在该阶段完成后开始清理索引。 |
cleaning up indexes | VACUUM 正在清理索引。这发生在堆被完全扫描并且所有的索引和堆的清理都已完成之后。 |
truncating heap | VACUUM 正在截断堆,以便将关系末尾的空页返回给操作系统。这发生在清理索引之后。 |
performing final cleanup | VACUUM 正在执行最终清理。在此阶段,VACUUM 将清理空闲空间映射,更新 pg_class 中的统计信息,并向累积统计系统报告统计信息。当这一阶段完成时,VACUUM 命令将结束。 |
注意
对于 VACUUM FULL 和 CLUSTER 命令,进度报告是通过 pg_stat_progress_cluster 视图提供的,因为这些命令重写整个表,而常规 VACUUM 命令只在原地修改表。
通过监视 pg_stat_progress_vacuum 视图,你可以了解 VACUUM 命令的执行进度,包括扫描了多少堆块、清理了多少堆块等。这对于理解 VACUUM 命令的执行过程和性能影响非常有用。
基础备份进度报告
PostgreSQL 支持在执行基础备份(base backup)时报告进度,这有助于数据库管理员监控长时间运行的基础备份操作。以下是针对基础备份进度报告的详细说明。
每当像 pg_basebackup 这样的应用程序正在执行基础备份时,视图 pg_stat_progress_basebackup 将包含一条记录,表示正在执行复制命令并流式传输备份的每个 WAL 发送进程。以下表格描述了 pg_stat_progress_basebackup 视图中报告的信息及其解释。
pg_stat_progress_basebackup 视图
列名 | 类型 | 描述 |
pid | integer | WAL 发送进程的 ID。 |
phase | text | 当前处理阶段。参见下表。 |
backup_total | bigint | 将要流式传输的总数据量。这是估计值,并在 phase 开始时报告。请注意,这只是近似值,因为数据库可能会在 phase 执行过程中发生变化,WAL 日志可能稍后被包含在备份中。一旦流式传输的数据量超过估计的总量,这个值就始终与 backup_streamed 相同。如果在 pg_basebackup 中禁用了估计(即指定了 --no-estimate-size 选项),则此值为 NULL。 |
backup_streamed | bigint | 已流式传输的数据量。此计数器仅在 phase 为 streaming database files 或 transferring wal files 时递增。 |
tablespaces_total | bigint | 将要流式传输的表空间总数。 |
tablespaces_streamed | bigint | 已流式传输的表空间数量。此计数器仅在 phase 为 streaming database files 时递增。 |
基础备份阶段
阶段 | 描述 |
initializing | WAL 发送进程正在准备开始备份。这一阶段预计很短暂。 |
waiting for checkpoint to finish | WAL 发送进程正在进行 pg_backup_start 操作以准备进行基础备份,并等待开始备份检查点完成。 |
estimating backup size | WAL 发送进程正在估计将作为基础备份流式传输的数据库文件总量。 |
streaming database files | WAL 发送进程正在流式传输数据库文件作为基础备份。 |
waiting for wal archiving to finish | WAL 发送进程正在进行 pg_backup_stop 操作以完成备份,并等待所有基础备份所需的 WAL 文件成功归档。如果 pg_basebackup 中指定了 --wal-method=none 或 --wal-method=stream,当此阶段完成时备份将结束。 |
transferring wal files | WAL 发送进程正在转移在备份过程中生成的所有 WAL 日志。如果 pg_basebackup 中指定了 --wal-method=fetch,此阶段发生在 waiting for wal archiving to finish 阶段之后。当此阶段完成时备份将结束。 |
通过监视 pg_stat_progress_basebackup 视图,你可以了解 pg_basebackup 命令的执行进度,包括传输了多少数据、流式传输了多少表空间等。这对于理解基础备份命令的执行过程和性能影响非常有用。
注意事项
- 性能影响:执行这些维护操作时,需要考虑对生产系统的性能影响。特别是在高负载系统上,应该尽量安排在低峰时段进行这些操作。
- 资源限制:维护操作可能需要大量的磁盘空间和 CPU 资源。确保有足够的资源可用,以避免操作失败。
- 备份验证:基础备份完成后,建议验证备份的有效性,以确保在需要时能够正确恢复。
- 并发控制:某些维护操作可能会锁定表或行,因此需要注意与其他并发操作之间的冲突。
- 进度报告的刷新频率:进度报告视图可能需要一定的时间间隔来更新,因此显示的进度可能不是实时的。
总结
PostgreSQL 提供了一套强大的工具集,允许数据库管理员监控多种维护操作的进度。通过这些视图,管理员可以更好地管理数据库维护活动,从而提高数据库的整体性能和可靠性。然而,在执行这些操作时,需要仔细规划以减少对生产环境的影响,并确保有足够的资源来完成任务。此外,定期检查和验证这些操作的结果是非常重要的,以保证数据的一致性和完整性。