PostgreSQL03-客户端与服务端命令/进程

1、客户端命令

psql

最核心的交互式 SQL 客户端，支持连接数据库、执行 SQL 语句、运行脚本、查看元数据等。

pg_dump/pg_dumpall

数据备份工具
pg_dump用于备份单个数据库（支持多种格式，如 SQL 脚本、自定义格式）
pg_dumpall则备份整个实例的所有数据库、角色、表空间等全局对象。

pg_restore

配合pg_dump使用的恢复工具，可恢复非 SQL 格式的备份（如自定义格式、tar 包），支持选择性恢复表、索引等对象。

createdb/dropdb

命令行创建 / 删除数据库的工具，本质是封装了CREATE DATABASE和DROP DATABASE SQL 命令，通过参数指定主机、用户、所有者等信息。

createuser/dropuser

创建 / 删除用户（角色）的命令行工具，对应CREATE USER和DROP ROLE SQL 命令，可通过参数控制用户权限（如是否为超级用户、能否创建数据库等）。

2、服务端命令

pg_ctl

数据库服务控制工具，是管理 PostgreSQL 实例生命周期的核心命令。支持start、stop（停止服务，可指定-m fast快速关闭）、restart、status、reload（重新加载配置文件，如postgresql.conf）等操作，需指定数据目录（-D参数）。

initdb

初始化数据库集群的工具，在首次安装 PostgreSQL 后执行，用于创建数据目录、初始化系统表、生成默认配置文件（postgresql.conf、pg_hba.conf等）

pg_upgrade

主版本升级工具，无需通过备份恢复重建数据，通过迁移数据目录和转换元数据实现高效升级。

pg_checksums

用于管理数据页校验和的工具，用于检测数据文件是否损坏。可检查当前数据目录的校验和状态（-c）、启用（-e）或禁用（-d）校验和（需在服务停止时执行）

pg_resetwal

重置事务日志（WAL）的工具，仅在 WAL 损坏导致数据库无法启动时使用（需谨慎，可能丢失未提交事务），通过重建 WAL 日志使数据库恢复启动能力。

postmaster

PostgreSQL 服务的主进程启动命令（pg_ctl start本质是调用postmaster），可直接执行（如postmaster -D 数据目录），但通常推荐通过pg_ctl间接管理，便于统一控制。

3、客户端进程

• 客户端进程是用户发起的、用于与服务端通信的进程，运行在客户端主机（可能与服务端同机，也可能远程），负责将用户操作转换为请求发送给服务端，并接收返回结果。
• 客户端进程与服务端的通信基于 TCP/IP 协议（默认端口 5432），每个客户端进程会与服务端的一个后端进程建立一对一的连接，直至客户端主动断开（如\q退出psql）或连接超时。
• 常见的客户端进程类型包括：

psql 进程

当用户执行psql命令连接数据库时，操作系统会创建一个psql进程，该进程持续运行直至用户退出psql，负责处理用户输入的 SQL 命令、解析元命令、展示服务端返回的结果。

应用程序进程

通过 JDBC、ODBC、libpq 等驱动连接 PostgreSQL 的应用程序（如 Java 程序、Python 脚本），每个连接会对应一个客户端进程（或线程），负责与服务端建立 TCP 连接、发送 SQL 请求、处理结果集。

备份工具进程

执行pg_dump、pg_restore等命令时生成的进程，这些进程通过数据库协议连接服务端，读取数据（备份）或写入数据（恢复），完成后自动退出。

4、服务端进程

• 服务端进程运行在数据库服务所在主机，由postmaster主进程管理，负责处理客户端请求、管理数据存储、保证事务一致性等核心功能，是 PostgreSQL 服务的 “执行主体”。
• 主要的服务端进程包括：

postmaster（主进程）

服务端的总控进程，负责监听客户端连接请求（默认 5432 端口）、启动后端进程处理连接、管理其他辅助进程、监控进程状态（如重启崩溃的后端进程）、处理服务关闭等。postmaster是服务启动时第一个运行的进程，其 PID 通常记录在数据目录的postmaster.pid文件中。

backend（后端进程，又称 postgres 进程）

当客户端发起连接时，postmaster会 fork 一个backend进程（每个连接对应一个），专门处理该客户端的所有请求（如解析 SQL、执行查询、返回结果）。backend进程拥有访问数据文件的权限，直接与存储交互，完成数据读写，其生命周期与客户端连接一致（连接断开则进程退出）。
辅助进程：PostgreSQL 启动时会由postmaster自动启动一系列辅助进程，协同处理核心功能：

bgwriter（后台写入器）

定期将共享内存中的脏数据页（被修改过的数据）写入磁盘，减少backend进程的 I/O 压力，提高查询效率。

walwriter（WAL 写入器）

将事务日志（WAL，Write-Ahead Log）从内存缓冲区写入磁盘，所有数据修改必须先写入 WAL 日志，再写入数据文件。walwriter 进程会定期将内存中的 WAL 日志刷到磁盘（默认每 600ms，可通过wal_writer_delay配置），即使数据库崩溃，也能通过 WAL 日志恢复未持久化的数据。

checkpointer（检查点进程）

定期执行 “检查点” 操作，将内存中所有脏数据页写入磁盘，并更新控制文件和 WAL 日志中的检查点记录。加快数据库崩溃后的恢复速度。
检查点的触发时机包括：达到配置的时间间隔（checkpoint_timeout，默认 5 分钟）、WAL 日志量达到阈值（max_wal_size）、手动执行CHECKPOINT命令等。执行时，checkpointer 会强制将所有脏页刷到磁盘，并记录当前的 WAL 位置，作为后续崩溃恢复的起点。

autovacuum launcher（自动清理启动器）

管理autovacuum worker进程，定期自动启动 worker 进程执行 VACUUM（清理删除 / 更新产生的死元组）和 ANALYZE（更新统计信息，优化查询计划），避免表膨胀和性能下降。
PostgreSQL 中，删除或更新记录时，旧数据不会立即从磁盘删除（仅标记为 “死元组”），长期积累会导致表膨胀；

pgarchiver（归档进程）

当启用 WAL 归档（archive_mode = on）时，负责将已写满的 WAL 段文件复制到指定的归档目录（由archive_command配置），用于长期备份或时间点恢复（PITR）。
WAL 文件会循环覆盖，pgarchiver 在 WAL 段文件关闭（写满）后，触发archive_command定义的操作（如复制到远程存储、备份服务器），将其永久保存。

stats collector（统计信息收集器）

收集数据库活动的统计信息（如表访问次数、索引使用情况），供查询优化器生成最优执行计划。
收集的信息包括：表的行数、索引使用频率、数据分布（如列的最大值 / 最小值 / 平均值）、查询执行时间等。这些数据存储在系统视图（如pg_stat_user_tables、pg_stat_user_indexes）中，查询优化器会基于这些统计信息选择最高效的执行路径（如是否使用索引、连接顺序等）。

Logger（系统日志进程）

负责收集和写入 PostgreSQL 的系统日志（如错误信息、警告、运行状态等），统一管理数据库的日志输出。
PostgreSQL 的日志可配置为输出到文件或系统日志（如 Linux 的 syslog）等，Logger 进程会监听其他进程产生的日志事件，按照postgresql.conf中的日志配置（如log_destination、log_directory）将日志信息写入目标位置。