pg_controldata

原创 已于 2023-07-26 19:38:07 修改 · 551 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库

于 2023-06-28 09:05:02 首次发布
文章详细解析了pg_controldata命令的输出结果，包括数据库版本、系统标识符、检查点位置、WAL信息、最大连接数和数据库块大小等关键参数，展示了数据库集群的运行状态和配置详情，对于数据库管理和维护具有指导意义。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

pg_controldata /pgdata/data/vastbase-55d7a76f

根据提供的信息，这是关于一个 PostgreSQL 数据库集群中 /pgdata/data/vastbase-55d7a76f 目录下的 pg_controldata 命令的输出结果。

以下是输出中的一些重要信息的解释：

  • pg_control version number: 923：这是 pg_control 文件的版本号，它对应于 PostgreSQL 9.2.3 版本。
  • Catalog version number: 201611171：这是数据库目录的目录版本号，指明数据库使用的系统目录的格式。
  • Database system identifier: 4246795137288642501：这是数据库系统的唯一标识符（Database System Identifier，简称为 “DBOID”），用于识别一个特定的数据库集群。
  • Database cluster state: in production：这表示数据库集群处于 “in production”（生产中）状态，即正在运行并提供服务。
  • pg_control last modified: Tue 27 Jun 2023 05:48:08 PM CST：这是 pg_control 文件最后修改的时间。
  • Latest checkpoint location: 2/4931F2D0：这是最新检查点（checkpoint）的位置，用于恢复和故障恢复操作。
  • Latest checkpoint's REDO location: 2/4931F250：这是最新检查点的 REDO（重做）位置，用于数据恢复。
  • Latest checkpoint's TimeLineID: 1：这是最新检查点的时间线标识符（Timeline ID），指明数据库的时间线。
  • Latest checkpoint's full_page_writes: off：这表示最新检查点的全页写（full_page_writes）选项为关闭状态，这意味着在检查点期间只写入修改的数据页，而不是全部数据页。
  • Latest checkpoint's NextXID: 19427：这是下一个事务ID（XID）的值，用于标识将要执行的下一个事务。
  • Latest checkpoint's oldestXID: 9792：这是最旧活动事务的XID值，用于确定最早还未完成的事务。
  • Current wal_level setting: hot_standby：这是当前的WAL级别设置，指明WAL（Write-Ahead Log）的详细记录级别。在这种情况下，设置为 “hot_standby”，表示启用了热备用服务器功能。
  • Current max_connections setting: 250：这是当前的最大连接数设置，表示同时允许的最大客户端连接数。
  • Database block size: 8192：这是数据库块的大小，以字节为单位，用于存储数据库中的数据。
  • WAL block size: 8192：这是WAL（Write-Ahead Log）块的大小，以字节为单位，用于记录数据库的变更。
  • Bytes per WAL segment: 16777216：这是每个WAL段的字节数，指定了WAL文件的大小限制。
  • Database system TimeLine: 6：这是数据库系统的时间线（Timeline）标识符。

这些信息可以提供有关数据库集群的各种配置和状态的详细信息，供管理员和开发人员使用。

pg_xlogfile_name

pg_xlogfile_name 是一个 PostgreSQL 内置函数，用于生成指定 WAL (Write-Ahead Log) 文件的文件名。

该函数接受两个参数：

  • lsn：表示 WAL 日志位置的参数，通常以 x/y 的格式表示，其中 x 是一个十六进制数，表示段（segment）号，y 也是一个十六进制数，表示段内偏移量（segment offset）。
  • timeline：表示时间线标识符（Timeline ID）的参数。

函数将根据提供的 LSN 和时间线信息生成对应 WAL 文件的文件名。

例如，如果调用 pg_xlogfile_name('2/4931F2D0', 1)，它将返回与 2/4931F2D0 位置和时间线 1 相关联的 WAL 文件的文件名。

请注意，pg_xlogfile_name 是一个内部函数，主要用于 PostgreSQL 内部和系统管理目的。在大多数情况下，通常不需要手动调用此函数。

删除3天前的wal

cd path/pg_xlog
find . -name “00000*” -type f -mtime +3 -exec rm -f {} ;

解释

pg_controldata is a utility in PostgreSQL that provides information about the current state of the database cluster. Based on the provided output, here is an explanation of each field:

  • pg_control version number (1300): The version number of the pg_control file format. This indicates the format used to store control information about the database cluster.

  • Catalog version number (202107181): The version number of the system catalog, which stores metadata about databases, tables, indexes, etc. This number represents the timestamp when the catalog was last updated.

  • Database system identifier (7259624880255705248): A unique identifier for the database cluster. This value is used to ensure that different clusters do not accidentally connect to each other.

  • Database cluster state (in production): Indicates the current state of the database cluster. In this case, it shows that the cluster is in production.

  • pg_control last modified (Tue Jul 25 13:40:54 2023): The timestamp when the pg_control file was last modified.

  • Latest checkpoint location (0/4000220): The location of the most recent checkpoint in the Write-Ahead Log (WAL). Checkpoints are used to mark a point where all data files have been flushed to disk, ensuring durability.

  • Latest checkpoint’s REDO location (0/40001E8): The location in the WAL from which recovery would start after a crash or shutdown. REDO records contain changes that need to be replayed during recovery.

  • Latest checkpoint’s REDO WAL file (000000020000000000000004): The name of the WAL file associated with the latest checkpoint’s REDO location.

  • Latest checkpoint’s TimeLineID (2): The identifier of the timeline in which the checkpoint occurred. Timelines help keep track of changes in database history.

  • Latest checkpoint’s PrevTimeLineID (2): The identifier of the timeline that precedes the current timeline.

  • Latest checkpoint’s full_page_writes (on): Indicates whether full-page writes are enabled for the cluster. Full-page writes ensure that modifications to a page are written in their entirety during checkpoints, even if only a portion has changed.

  • Latest checkpoint’s NextXID (0:743): The ID of the next transaction to be assigned. Each transaction in PostgreSQL is identified by a unique transaction ID.

  • Latest checkpoint’s NextOID (16417): The next Object ID to be assigned. Object IDs are used to identify system objects like tables and indexes.

  • Latest checkpoint’s NextMultiXactId (1): The next MultiXact ID to be assigned. MultiXact IDs are used to identify transactions involving multiple concurrent operations.

  • Latest checkpoint’s NextMultiOffset (0): The next offset within the MultiXact ID to be assigned.

  • Latest checkpoint’s oldestXID (727): The oldest transaction ID still active in the database cluster.

  • Latest checkpoint’s oldestXID’s DB (1): The database ID of the database to which the oldest transaction ID belongs.

  • Latest checkpoint’s oldestActiveXID (743): The oldest active transaction ID in the database cluster.

  • Latest checkpoint’s oldestMultiXid (1): The oldest MultiXact ID still active in the database cluster.

  • Latest checkpoint’s oldestMulti’s DB (1): The database ID of the database to which the oldest MultiXact ID belongs.

  • Latest checkpoint’s oldestCommitTsXid (0): The oldest transaction ID with a committed timestamp. This field is related to commit timestamp tracking, which allows associating a timestamp with each committed transaction.

  • Latest checkpoint’s newestCommitTsXid (0): The newest transaction ID with a committed timestamp.

  • Time of latest checkpoint (Tue Jul 25 13:40:54 2023): The timestamp when the latest checkpoint occurred.

  • Fake LSN counter for unlogged rels (0/3E8): A fake Log Sequence Number (LSN) counter used for unlogged relations, which are not part of the WAL and do not provide crash recovery.

  • Minimum recovery ending location (0/0): The minimum location in the WAL required for recovery to finish.

  • Min recovery ending loc’s timeline (0): The timeline associated with the minimum recovery ending location.

  • Backup start location (0/0): The starting location of the backup. This indicates where the backup process began.

  • Backup end location (0/0): The ending location of the backup. This indicates where the backup process finished.

  • End-of-backup record required (no): Indicates whether an end-of-backup record is required for crash recovery.

  • wal_level setting (logical): The current value of the wal_level configuration parameter. It determines the amount of information written to the WAL.

  • wal_log_hints setting (on): The current value of the wal_log_hints configuration parameter. When enabled, it provides hints to optimize logging for full-page writes.

  • max_connections setting (200): The maximum number of concurrent connections allowed to the database cluster.

  • max_worker_processes setting (8): The maximum number of background processes that can be started by PostgreSQL.

  • max_wal_senders setting (10): The maximum number of WAL sender processes that can send changes to remote replicas.

  • max_prepared_xacts setting (0): The maximum number of prepared transactions that can be active at the same time.

  • max_locks_per_xact setting (64): The maximum number of locks that a single transaction can hold simultaneously.

  • track_commit_timestamp setting (off): The current value of the track_commit_timestamp configuration parameter. When enabled, it tracks the commit timestamp of each transaction.

  • Maximum data alignment (8): The maximum byte alignment required for data storage.

  • Database block size (8192): The size of a database block in bytes. It is the basic unit of data storage within PostgreSQL.

  • Blocks per segment of large relation (131072): The number of blocks allocated per segment for large relations.

  • WAL block size (8192): The size of a WAL block in bytes. The WAL stores changes made to the database for durability and crash recovery.

  • Bytes per WAL segment (16777216): The number of bytes allocated per WAL segment.

  • Maximum length of identifiers (64): The maximum length of identifiers like table names and column names.

  • Maximum columns in an index (32): The maximum number of columns that can be included in an index.

  • Maximum size of a TOAST chunk (1996): The maximum size of a compressed TOAST (The Oversized-Attribute Storage Technique) chunk.

  • Size of a large-object chunk (2048): The size of a chunk used for large objects.

  • Date/time type storage (64-bit integers): The method used to store date/time types, which in this case is using 64-bit integers.

  • Float8 argument passing (by value): The way floating-point arguments are passed, which in this case is “by value.”

  • Data page checksum version (0): The version number of the data page checksum algorithm.

  • Mock authentication nonce (0a12314f4c8492ae60df53b46f16f77b1e6c99ca571e81e6291e74a1cf058e4a): A random value used for mocking authentication nonces.

【0010】 从源码级分析pg_control文件的作用
Postgres 数据库内核开发工程师
03-17 979
文章目录1. pg_control文件1.1 pg_control文件位于何处？1.2 pg_control文件数据内容1.2.1 借助工具查看pg_control中的数据1.3 pg_control文件生成时机1.3.1 pg_control文件创建原理剖析 1. pg_control文件      pg_control是一个8KB大小的二进制文件，该文件中记录了PostgreSQL服务器内部信息状态的各方面信息，比如最新检查点（checkpoint）、系统状态、当前运行的postgres服务版本、CRC
postgresql 如何手动清理归档文件（pg_wal）
qq_23986087的博客
04-18 5976
背景 发现数据库宕机，排查原因发现数据磁盘爆满，经排查发现是数据库数据目录下，pg_wal目录占用过大导致。 pg_wal（Write-AHead Logging） 说明 wal日志位置： $PGDATA/pg_wal(pg10之前叫pg_xlog) # #wal日志文件命名规则： #我们看到的wal日志是这样的：000000010000000100000092 #其中前8位:00000001表示timeline； #中间8位：00000001表示logid； #最后8位：00000092表示log
pg_controldata命令
msdnchina的专栏@JiNan,ShanDong
02-25 2646
[postgres@pgserver ~]$ /usr/local/pgsql/bin/pg_controldata pg_control version number: 1002 Catalog version number: 201706241 Database system identifier: 645152775718...
pg_controldata (1)
晨风
03-17 4036
那么和xlog相关的还有个查看数据库状态的命令：pg_controldata, 执行结果如下图： 源文件：https://github.com/linwanggm/postxc/blob/master/pg_controldata_modify.c [wln@localhost data]$ pg_controldata pg_control version number:    
pg_controldata 内容解释
长期深耕于云计算、大数据、数据库领域！
10-14 1897
作者：崔鹏 内容解释 pg_control version number: 是控制文件版本号。 Catalog version number: 是系统表版本号，格式是yyyymmddN。 Database system identifier: 数据库系统号 这个标识串是一个64bit的整数。 Database cluster state: 记录实例的状态。源码文件中看到数据库的几种状态： starting up：表示数据库正在启动状态。 shut down： 数据库实例（非Standby）
PostgreSQL自带的命令行工具22- pg_controldata
文牧之的博客
05-13 1391
是 PostgreSQL 提供的一个实用工具，用于显示 PostgreSQL 数据库集群的控制信息。这个实用程序可以让你查看一些关键的系统信息，而不必启动数据库服务器。这些信息对于故障排除、监控和理解 PostgreSQL 数据库的内部运行机制非常有价值。
PostgreSQL源码分析——pg_control
内核思考
06-19 997
pg_control是PostgreSQL中一个很重要的文件，我们之前讲到过PostgreSQL的启动过程，启动过程中很重要的一项工作就是故障恢复，启动startup进程，回放WAL日志进行故障恢复，而从哪里开始进行回放呢？这个位置的保存一定是在磁盘中，而不是在内存中，假设数据库因故障崩溃，内存中的数据会丢失，所以，只有checkpointer进程在做checkpoint操作时不断的更新pg_control文件，使之持久化保存，数据库启动进行故障恢复时，读取该文件，获得故障恢复的起始位置。
Greenplum(GP)数据库启动报错-cannot access pg_controldata for dbid 6 on host xxxx
程序人生
04-30 954
1、错误问题 首先看看服务器报错界面 gpadmin-[WARNING]:-cannot access pg_controldata for dbid 6 on host node04xxxx 2、查找原因 1、开始以为是服务器开通了防火墙，然后关闭主节点和从节点防火墙后还是报错； 2、查询服务器5433端口 一直未开启； 3、重启所有服务器在执行gpstart,最终还是提示gpstart:node主节点:gpadmin-[INFO]:-Process results... 2021042.
openGauss 系统内部使用的工具：pg_controldata
weixin_53596073的博客
10-11 533
pg_controldata工具用来显示数据库目录下control文件的信息。
pg_controldata - 显示一个 PostgreSQL 集群的控制信息
weixin_30861459的博客
06-27 392
SYNOPSIS pg_controldata [ datadir] DESCRIPTION 描述 pg_controldata 打印那些在 initdb 过程中初始化的信息，比如表版本和服务器的区域等。它还显示有关预写日志和检查点处理相关的信息。 这些信息是集群范围内有效的，并不和某个数据库相关。 这个命令只应该有安装服务器的用户运行，因为它要求对数据目录的读访问权限。 你可以在命令行...
【转帖】pg_control file recover
msdnchina的专栏@JiNan,ShanDong
05-25 1011
今天一位朋友在问pg_control文件丢失或损坏是否可以启动PostgreSQL的问题，于是在测试系统尝试了一下。首先记录下正常情况下的pg_controldata信息如下:这个信息非常有用，需要用于恢复.pg_control version number:            903Catalog version number:               201008051Databa...
pg_controldata (2)
晨风
03-17 1551
#include #include #include #include #include /* this file has the same effect as the binary file 'pg_contrldata' in postgres, haha,the file's content comes from Postgres. * gcc -o aim sourcefil
PostgreSQL主从切换-手动
骑猪喝咖啡
05-18 4499
主备切换需确保备库状态为“in archive recovery”，然后执行切换命令pg_ctl promote
pg 崩溃恢复篇（四）—— 检查点进程与崩溃恢复
Hehuyi_In的博客
11-13 3969
一、 检查点进程 在pg中，当下列情形之一发生时，checkpointer进程会启动执行检查点： 自上次检查点执行时间已超过checkpoint_timeout设置（默认300秒）。 在9.5之前，自上一次检查点以来使用的WAL文件数量，超过了checkpoint_segments设置（默认为3）。 9.5开始为pg_xlog中WAL文件总大小超过max_wal_size设置（默认1GB，......
PostgreSQL流复制热备
weixin_34106122的博客
12-11 542
关于pg热备与主备切换网上很多内容都有了，本文仅为自己测试使用，特意记录过程，或对其他人提供参考。本文作者选择pg9.6.1版本作为测试。 一 主备机器规划 主机名 | IP | 角色 | 端口 :----:|:----:|:----:|:----:|:----:|:----: master| 192.168...
postgresql双机热备（流复制）及主备切换
热门推荐
Silence Ray的博客
01-23 2万+
一、环境 系统：redhat6.5 64位 ip：192.168.11.68（主） 192.168.11.70（备） 数据库版本：postgresql9.4.4 二、双机热备的过程 两台系统之中安装postgresql （过程这里就不写了） 1.配置主节点 [root@node1 ~]# su - postgres [postgres@node1 ~]#cd /opt/p
[PGSQL]PostgreSQL的控制文件内幕分析
arcticJian的博客
04-24 1320
引用自： https://mp.weixin.qq.com/s/kL9ZvbzoylAW55NJu-8RPA2018-04-24 osdba@乘数科技 乘数科技 控制文件的作用PostgreSQL的控制文件与Oracle类似，都是记录数据库的一些重要信息。使用pg_controldata命令就可以显示出控制文件中的内容：[postgres@pg01 ~]$ pg_controldata pg_
gitlab "global/pg_control": Permission denied
最新发布
03-23
<think>好的，我现在需要解决用户在GitLab中遇到的“global/pg_control: Permission denied”权限问题。首先，我得理解这个错误通常出现在什么情况下。根据经验，PostgreSQL相关的权限问题可能涉及到数据目录的所有权或访问权限不正确。用户可能是在安装或升级GitLab后遇到这个问题，特别是当PostgreSQL的数据目录权限被错误地更改时。 接下来，我应该检查数据目录的权限设置。通常，PostgreSQL的数据目录位于/var/opt/gitlab/postgresql/data，而pg_control文件可能在这个目录下。正确的所有权应该是gitlab用户和gitlab组，比如gitlab-psql。用户可能需要使用chown和chmod命令来调整权限。比如，运行sudo chown -R gitlab-psql:gitlab /var/opt/gitlab/postgresql/data和sudo chmod -R 0700 /var/opt/gitlab/postgresql/data。 然后，可能需要重新配置GitLab，使用gitlab-ctl reconfigure命令，这会重新应用正确的配置和权限。另外，如果用户最近升级了GitLab，可能需要检查升级过程中是否有步骤遗漏，或者是否有残留的旧文件导致权限冲突。 另外，SELinux或AppArmor这样的安全模块有时会限制进程的访问权限。用户可能需要检查这些安全策略是否阻止了PostgreSQL访问相关文件。可以通过暂时禁用SELinux来测试是否是这个问题，或者使用audit2why工具分析日志，调整策略。 还有，需要确认PostgreSQL服务是否正常运行。使用gitlab-ctl status postgresql查看服务状态，如果服务没有启动，可能需要查看日志文件/var/log/gitlab/postgresql/current中的错误信息，进一步诊断问题。 最后，如果以上步骤都无效，可能需要考虑备份数据并重新初始化PostgreSQL，或者联系GitLab支持获取帮助。同时，用户需要确保在操作前备份重要数据，避免数据丢失。 总结一下，解决步骤应该是检查并修复数据目录权限，重新配置GitLab，检查安全模块设置，验证服务状态，查看日志，最后考虑重新初始化或寻求支持。此外，生成相关问题可以帮助用户进一步了解如何预防类似问题，比如如何设置正确的文件权限，或如何配置SELinux以兼容GitLab服务。</think>### GitLab中“global/pg_control: Permission denied”权限问题解决方案 #### 1. 检查文件所有权与权限 PostgreSQL的`pg_control`文件通常位于数据目录中（如`/var/opt/gitlab/postgresql/data`）。权限问题可能因文件所有权错误或访问权限不足导致： - **修复所有权**： ```bash sudo chown -R gitlab-psql:gitlab /var/opt/gitlab/postgresql/data ``` 其中`gitlab-psql`是GitLab默认的PostgreSQL运行用户[^1]。 - **设置严格权限**： ```bash sudo chmod -R 0700 /var/opt/gitlab/postgresql/data ``` 此命令确保仅所有者有读写执行权限，符合PostgreSQL安全要求。 #### 2. 重新配置GitLab 运行以下命令重新生成配置并应用权限： ```bash sudo gitlab-ctl reconfigure ``` 此操作会重置服务配置，包括文件权限和依赖项。 #### 3. 检查SELinux/AppArmor限制 若系统启用了SELinux或AppArmor，可能拦截PostgreSQL访问： - **临时禁用SELinux**（仅用于测试）： ```bash sudo setenforce 0 ``` - **调整策略**： 查看审计日志`/var/log/audit/audit.log`，使用`audit2allow`生成新策略模块： ```bash grep pg_control /var/log/audit/audit.log | audit2allow -M mypolicy sudo semodule -i mypolicy.pp ``` #### 4. 验证PostgreSQL服务状态 确保服务正常运行： ```bash sudo gitlab-ctl status postgresql ``` 若服务未启动，检查日志： ```bash sudo journalctl -u gitlab-postgresql ``` #### 5. 处理残留文件或升级问题 若问题出现在升级后，尝试清理旧文件： ```bash sudo gitlab-ctl cleanup ``` #### 6. 备份与重新初始化（最后手段） 备份数据后，重新初始化PostgreSQL： ```bash sudo gitlab-ctl stop postgresql sudo rm -rf /var/opt/gitlab/postgresql/data/* sudo gitlab-ctl reconfigure sudo gitlab-ctl start postgresql ``` ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值