PostgreSQL 服务器应用

这一部分包含PostgreSQL服务器应用和支持工具的参考信息。这些命令只在数据库服务器所在的主机上运行才有用。其他工具程序在PostgreSQL 客户端应用中列出。

目录

• initdb — 创建一个新的PostgreSQL数据库集簇
• pg_archivecleanup — 清理PostgreSQL WAL 归档文件
• pg_checksums — 在PostgreSQL数据库集簇中启用、禁用或检查数据校验和
• pg_controldata — 显示一个PostgreSQL数据库集簇的控制信息
• pg_ctl — 初始化、启动、停止或控制一个PostgreSQL服务器
• pg_resetwal — 重置一个PostgreSQL数据库集簇的预写式日志以及其他控制信息
• pg_rewind — 把一个PostgreSQL数据目录与另一个从该目录中复制出来的数据目录同步
• pg_test_fsync — 为PostgreSQL判断最快的 wal_sync_method
• pg_test_timing — 度量计时开销
• pg_upgrade — 升级PostgreSQL服务器实例
• pg_waldump — 以人类可读的形式显示一个PostgreSQL 数据库集簇的预写式日志
• postgres — PostgreSQL数据库服务器
• postmaster — postmaster是postgres的一个废弃的别名。

initdb

创建一个新的PostgreSQL数据库集簇

initdb -D ${要初始化的数据库集蔟所在的目录}

pg_archivecleanup

这个命令主要是用于开启了 归档日志(archive log) 功能的 postgresql, 开启了这个功能后, 会把切换出来的预写式日志复制到指定的目录, 这个目录下的文件如果一直不清理, 可能会挤爆硬盘, 所以需要定期清理下。但是清理前需要注意:

没有包含在最后一次的备份中的WAL_LOG 不要删除，这样才能保证数据库能根据备份+WAL_LOG恢复

pg_archivecleanup用于在作为后备服务器运行（第 26.2 节）时配置 archive_cleanup_command来清理 WAL 文件归档。 pg_archivecleanup也可以被用作一个单独的程序来清理 WAL 文件归档。

要配置一个后备服务器以使用pg_archivecleanup，把下面 的内容放在postgresql.conf配置文件中：

archive_cleanup_command = 'pg_archivecleanup ${归档日志所在的目录} %r'

扩展阅读:

1. PostgreSQL pg_archivecleanup 与怎么清理 archivelog

pg_rewind

功能: 把一个PostgreSQL数据目录与另一个从该目录中复制出来的数据目录同步, 可以理解为物理级别的 wal log的搬运工。

提到pg_rewind就必然会提到时间线, 如果对时间线还没有了解, 请先阅读链接的内容。

典型场景:

1. 主备切换
   基于streaming replication搭建的PostgreSQL HA环境,Old Standby节点升级为New Master节点后,时间线会切换为新的时间线,比如从n变为n + 1.而Old Master节点的时间线仍然为原来的时间线,比如仍为n,通过使用pg_rewind工具,可使原来其实”完好”的Old Master成为New Standby节点.

image

2. 基于同一集群复制的任意两个副本（集群）进行同步

这种情况其实用rsync也可以做, 无非就是覆盖掉所有物理文件,
和rsync的区别是，pg_rewind 不需要去读那些未变化的文件块，当数据量比较大而变化较小的时候，pg_rewind会更快。

扩展阅读:

1. PgSQL · 特性分析 · 神奇的pg_rewind

pg_checksums

打开checksum会很大程度上影响性能, 还是不要打开了, 不打开的话, 这个命令就没啥用了。

pg_controldata

# pg_controldata -D /var/lib/postgresql/data
pg_control version number:            1201
Catalog version number:               201909212
Database system identifier:           6911772934471983141
Database cluster state:               in production
pg_control last modified:             Fri 05 Mar 2021 06:39:35 AM UTC
Latest checkpoint location:           0/27BD200
Latest checkpoint's REDO location:    0/27BD200
Latest checkpoint's REDO WAL file:    000000010000000000000002
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:2654
Latest checkpoint's NextOID:          40960
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        480
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Fri 05 Mar 2021 06:39:35 AM UTC
Fake LSN counter for unlogged rels:   0/3E8
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
wal_level setting:                    replica
wal_log_hints setting:                off
max_connections setting:              100
max_worker_processes setting:         8
max_wal_senders setting:              10
max_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0
Mock authentication nonce:            3d812ed3af4cf1fdad2642c097b88200bb41fc62d141891543cb85d388d6fa0a

pg_ctl

初始化、启动、停止或控制一个PostgreSQL服务器

pg_ctl --help

pg_resetwal

pg_resetwal就是之前的pg_resetxlog

pg_resetwal 用来重置WAL日志和一些控制信息，常用于数据库恢复场景，不到万不得已不轻易使用，生产环境慎用。
这个命令不能在服务器正在运行时被使用。

1. 将WAL日志文件改为每个64MB, 默认是16MB: pg_resetwal --wal-segsize=64 -D ${数据目录}

注意: pg_resetwal 会清除pg_wal目录的WAL文件

min_wal_size = 128MB # 需要大于等于WAL文件大小的两倍

2. PostgreSQL恢复pg_control文件
3. 利用pg_resetwal回到过去(重置事务ID来访问被修改的数据)
   pg_resetwal的一项特技是篡改当前事务ID，使得可以访问到这些死元组，只要这些死元组还未被vacuum掉。例子详见这里

pg_upgrade

用于跨主版本的升级, 小版本升级不需要这个工具。因为小版本之间的数据文件格式是一样的, 所以不需要升级数据文件, 只需要直接更新程序代码即可。

pg_waldump

这个是调试和教学用的命令。

postgres

单用户模式: postgres --single -D ${数据目录} ${其他配置选项} ${数据库名}