PostgreSQL 10.1中文手册实践：分区、逻辑复制与部署要点-代码聚汇网

PostgreSQL 10.1中文手册实践：分区、逻辑复制与部署要点

大雄行为锻炼·2026-09-01·阅读 105 GEO检测（免费）

PostgreSQL数据库中文手册

|难度：普通|阅读约 36 分钟

拿到“PostgreSQL10.1-CN-v1.0.pdf”这个标题时，我第一反应是想起自己电脑里还躺着一份同样的文件——那是我刚入行时从某个技术社区下载的，当时数据库选型正卡在MySQL和PostgreSQL之间，这份中文手册几乎是夜晚值班时的救命稻草。一晃几年过去，PostgreSQL已经出到16、17，10.1这个版本号在官方支持矩阵里早就归档了，但把它当作一本“入门+进阶”的中文参考资料，它依然能打。这篇文章就基于这份文档，结合我在实际环境里踩过的坑和验证过的操作，聊聊10.1时代PostgreSQL的关键知识点，以及放到今天环境里，哪些经验还能直接用，哪些必须打个折扣再看。

1. 文件名里的门道：这份中文PDF到底覆盖了版本树的哪一段

1.1 10.1是一个分水岭版本

先别急着把这份PDF当成“过气资料”丢进收藏夹吃灰。PostgreSQL 10.1在版本史上有一个特殊位置：它是PostgreSQL项目把Major Version从9.x跳到10.x的第一个正式版本，也是第一个用“10.x”命名的大版本系列。这次版本号跳变不只是数字游戏，它意味着PostgreSQL官方明确形成了“每年一个大版本、每个大版本持续维护五年”的节奏，Feature Freeze、Beta、RC的发布流程也从此固定下来。

10.1作为10.0之后的第一个小版本，主要工作是修Bug和安全加固，所以它的功能清单基本等于10.0。而10.0正好引入了两个至今都在用的重量级能力：

声明式表分区（Declarative Partitioning）：创建分区表不再需要手动写一堆继承和触发器，直接PARTITION BY RANGE、PARTITION BY LIST就能搞定。
逻辑复制（Logical Replication）：基于发布/订阅模型，可以跨大版本、跨平台做表级复制，这是后来很多数据同步工具的地基。

这两点在我实际使用中感知非常强烈。以前用9.6做分区表，要先建父表、子表、继承关系、触发器，维护成本高到怀疑人生；10.1之后，SQL写法直白了很多。而逻辑复制更是直接改变了我处理“从生产库抽数到报表库”的方式，不再需要纠结trigger和外部程序。

1.2 这份“CN-v1.0”中文文档是怎么来的

文件名里的“CN”代表中文，“v1.0”代表翻译排版的第一版。PostgreSQL官方文档是英文的，社区爱好者会基于官方某次快照翻译整理成PDF。所以这份文档本质上不是简单的在线网页打印，而是经过人工校对、章节整理、排版优化过的版本。它覆盖的内容基本对齐官方10.1 Manual：从教程、SQL语法、服务器管理、客户端接口到内部机制，范围非常全。

不过我建议下载后先去“文档说明”或“前言”里看一个信息：它对应的英文原版快照日期。因为PDF是静态的，如果快照日期早于10.1正式发布，个别章节可能存在细微出入。我手上这份对照下来，主体内容与官方10.1手册一致，没有发现明显错译，只是部分图表在文字版里被省略了。

1.3 适合谁看，不适合谁看

我的建议是分人群：

刚接触PostgreSQL的DBA/后端开发：这份文档能帮你建立完整的认知地图，比零散刷博客强太多。
已经在用新版PostgreSQL（12+）的人：阅读时要注意版本差异，我会在第五章专门讲哪些内容需要更新。
纯粹想考证或者面试突击SQL语法：效率不如直接刷官方在线文档和题库，PDF更适合系统阅读和离线查阅。

这个文件最大的价值，是它把一个庞大数据库系统的知识组织成了“可以一口气读完”的纸质书形态。你不需要先搜“什么是WAL”，再搜“什么是checkpoint”，再搜“什么是MVCC”，它按章节把底层逻辑串起来了。这也是我后来推荐新人看的第一份资料。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 翻旧文档的正确姿势：10.1官方手册里真正值得反复读的部分

2.1 官方文档的三层结构

PostgreSQL官方手册的整体结构，从10.1到现在没有本质变化，都是三层递进：

第一层：教程（Tutorial）。用最简单的例子带你在数据库里建表、插入数据、查询、建立视图和索引。这一部分适合第一次接触关系型数据库的人，花一个下午就能跑通。
第二层：SQL语言参考（The SQL Language）。从SQL语法、数据类型、函数、索引到性能调优建议，这是日常开发和高频运维的核心战场。
第三层：服务器管理（Server Administration）。包括安装、配置、安全性、备份恢复、高可用复制、监控等，DBA或运维必须啃完的部分。

PDF的好处是目录结构保留完整，你可以在侧边栏直接跳章节。我强烈建议不要按页码顺序硬读，而是按“教程→SQL语言→服务器管理→接口”这个主线，再结合自己手头的任务反查目录。比如你突然发现索引变慢，直接跳到Chapter 11“Indexes”，里面有B-tree、Hash、GiST、GIN等各类索引的原理和适用场景。

2.2 10.1版本手册中最具有“长期阅读价值”的章节

我把通读三遍以上、至今仍觉得价值很高的章节列成表格，方便你按图索骥：

章节	核心内容	为什么值得反复读
Chapter 5 数据定义	表、约束、索引、分区、视图、外键	DDL是很多线上故障的根源，理解默认行为和约束逻辑比背SQL更重要
Chapter 9 函数和操作符	内置函数、字符串处理、日期时间、聚合函数	写复杂SQL和报表统计时，能少写很多业务层代码
Chapter 11 索引	B-tree、Hash、GiST、SP-GiST、GIN、BRIN	索引选错，查询性能差距能到几百倍，这个章节能帮你建立选型直觉
Chapter 20 客户端认证	pg_hba.conf、认证方式、SSL配置	任何一次连接失败最终都会查到这里，提前读能省大量排查时间
Chapter 21 数据库角色和权限	角色、权限、成员关系	多环境多人协作时，权限管理混乱会直接导致事故
Chapter 24 备份恢复	pg_dump、pg_basebackup、归档日志、PITR	没做过备份演练，等于没学过数据库管理
Chapter 26 高可用、负载均衡和复制	流复制、热备、逻辑复制、故障转移	生产环境单点是不可接受的，这一章是所有高可用方案的理论基础

2.3 如何用PDF高效检索

PDF文档虽然方便阅读，但它的弱点是检索体验不如在线文档。我摸索出一套比较顺手的组合方法：

用PDF阅读器的全文搜索配合目录跳转：比如想查“deadlock”，先看目录Chapter 13“并发控制”，再在Chapter 13内部用Ctrl+F搜“deadlock”，定位准确率极高。
把PDF同步到手机或平板的笔记软件里：通勤时读“教程”和“SQL语言”两部分，效率比纯碎片刷手机高很多。
读到某个参数但不确定当前版本是否还有效时，去官方在线文档快速核验：记住一个原则，官方文档始终是最终权威，PDF只做系统学习素材。

3. 安装到启动的完整过关流程：从仓库配置到.s.pgsql.5432.lock权限问题

3.1 环境准备与国内镜像源配置

在RHEL/CentOS 7上装PostgreSQL 10.1，官方推荐方式是用PostgreSQL官方YUM仓库，但在国内直连官方源经常慢到怀疑人生。我就是被这个“慢”字折磨过的人，后来换成了国内镜像源，速度立竿见影。

以阿里云镜像为例，配置方式如下（RHEL 7/CentOS 7环境）：

bash复制# 先安装EPEL（如果还没有）
sudo yum install -y epel-release

# 添加PostgreSQL 10的官方仓库地址（rpm文件）
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# 修改仓库镜像源：编辑 /etc/yum.repos.d/pgdg-redhat-all.repo
# 把 baseurl 里的 download.postgresql.org 替换为国内镜像地址
# 例如：https://mirrors.aliyun.com/postgresql/repos/yum/reporpms/

如果嫌配置麻烦，也可以直接把官方rpm包下载后手动安装，再用yum install postgresql10-server postgresql10-contrib，实测速度和稳定性都很好。

提示：CentOS 7自带的源里没有PostgreSQL 10.1，必须额外加源。不要用源码编译硬扛，除非你需要二次开发定制内核，否则YUM方式维护成本最低。

3.2 初始化数据库实例：initdb是必经之路

很多人装完包后直接执行systemctl start postgresql-10，结果报错“数据目录未初始化”。这是因为PostgreSQL不会自动初始化/var/lib/pgsql/10/data目录。

初始化命令：

bash复制# 切换成postgres用户执行
sudo -u postgres /usr/pgsql-10/bin/initdb -D /var/lib/pgsql/10/data

这里有几个容易被忽略的点：

initdb执行时不能用root用户，必须切换到postgres用户或指定-U参数。
数据目录不能已存在非空内容。
initdb默认生成本地超级用户为当前系统用户，所以通常sudo -u postgres，数据库超级用户就是postgres。
如果想设置数据库超级用户密码，可以在initdb之后启动服务，再用ALTER USER postgres PASSWORD 'xxx';修改。

3.3 启动失败排查：“无法创建锁文件 /var/run/postgresql/.s.pgsql.5432.lock: 权限不够”

我相信很多人在热搜词里看到过这条报错。它出现的原因非常典型：postgres用户对/var/run/postgresql目录没有写权限。/var/run在系统启动后会由tmpfs重新挂载，默认属主是root，而PostgreSQL启动时要把Unix Socket文件写到这个目录下。

我在CentOS 7上遇到这个问题时，第一反应是检查权限：

bash复制ls -ld /var/run/postgresql

输出是drwxr-xr-x 2 root root 40 ...，确实没有写权限。解决办法有两种：

第一种，把目录属主改成postgres：

bash复制sudo chown postgres:postgres /var/run/postgresql

第二种，修改PostgreSQL配置，把socket目录指到别处。在/var/lib/pgsql/10/data/postgresql.conf里：

conf复制unix_socket_directories = '/var/run/postgresql'

改成/tmp或者其他postgres有权限的目录。这种方式适合多实例共存的时候，避免socket目录冲突。

但我要提醒一句：改unix_socket_directories治标不治本。如果重启机器后tmpfs重新挂载，目录权限又变回root，你还是得改配置或手动chown。所以我后来干脆在系统服务启动前加一条chown postgres:postgres /var/run/postgresql的exec命令，或者直接用chown方案并保持目录属主持久化。如果你用systemd管理服务，在service文件里加ExecStartPre也是一个标准做法。

3.4 正确启动和关闭：别再随手kill进程

PostgreSQL 10的启动和关闭方式，本质上有两套：一套通过pg_ctl，另一套通过systemd service。生产环境我更推荐systemd，因为它能统一管理开机启动、崩溃重启和日志收集。

启动：

bash复制sudo systemctl start postgresql-10
sudo systemctl enable postgresql-10

关闭：

bash复制sudo systemctl stop postgresql-10

用pg_ctl手动操作时需要指定数据目录：

bash复制sudo -u postgres /usr/pgsql-10/bin/pg_ctl -D /var/lib/pgsql/10/data -l /tmp/pg.log start

关闭：

bash复制sudo -u postgres /usr/pgsql-10/bin/pg_ctl -D /var/lib/pgsql/10/data stop -m fast

-m fast表示快速关闭，会执行检查点并中断活动事务。如果只是测试环境，-m immediate能更快停库，但下次启动时必须走恢复流程——所以生产环境不要用。

3.5 防火墙连接被拒的坑

本机连接成功不代表远程能连上，我踩过一次印象深刻的坑：服务都起来了，端口5432也在监听，但客户端连不上。查了一圈发现是防火墙没放行，CentOS 7默认firewalld阻挡了外部访问。

bash复制sudo firewall-cmd --permanent --add-service=postgresql
sudo firewall-cmd --reload

同时检查/var/lib/pgsql/10/data/pg_hba.conf，确保客户端来源IP有对应的认证规则，比如：

conf复制host    all             all             192.168.1.0/24         md5

这一步不做，哪怕防火墙放行了，连接也会被拒。

4. 这个老版本在今天能干什么：高可用、异构同步、扩展与容器化

4.1 10.1的流复制与高可用部署

当年10.1发布时，流复制和热备已经是比较成熟的高可用基础。部署思路是用主库开启归档和wal_level，配置一个或多个备库做持续归档和流复制。10.1支持基于流复制的同步和异步模式，还引入了pg_rewind，这大大提高了故障转移后把旧主库拉回新主库的效率。

在实际环境中我部署过一个简单双节点方案：

主库配置：打开wal_level = replica（10.x里逻辑复制要求wal_level = logical）、max_wal_senders、archive_mode、archive_command等。
备库配置：用pg_basebackup拉取主库数据，然后在备库的recovery.conf里配置primary_conninfo和trigger_file。注意10.x版本还是在用recovery.conf这种方式，不能像12之后那样在postgresql.conf里直接配primary_conninfo。

一个经典操作流程：

bash复制# 在主库执行备份
sudo -u postgres /usr/pgsql-10/bin/pg_basebackup -h 192.168.1.10 -p 5432 -U replicator -D /var/lib/pgsql/10/data -X stream -P

# 在备库创建 recovery.conf
# recovery.conf 内容示例：
# standby_mode = 'on'
# primary_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=xxx'
# trigger_file = '/tmp/pg_failover.trigger'

# 启动备库
sudo systemctl start postgresql-10

这套方案的成熟度很高，10.1在生产环境跑个三五年没问题。但要明白它的能力边界：默认是异步复制，主库故障时可能丢失少量事务；即使开启同步复制，也只能保证一个备库的持久化顺序，不保证跨地域机房级别的零丢失，后者需要更复杂的方案。

4.2 MySQL/SQLServer/PostgreSQL同步的现实选择

热搜词里多次出现“mysql/sqlserver/postgresql数据库同步软件”。这个问题在10.1时代就有比较成熟的答案，但选择完全取决于你的业务形态：

同步场景	10.1时代的主流方案	注意事项
PostgreSQL主备同步	流复制/逻辑复制	10.1逻辑复制要求wal_level=logical，只支持表级复制，不支持DDL复制
MySQL→PostgreSQL全量迁移	pgloader、mysqldump加转换脚本	类型映射和字符集处理是最大坑
MySQL→PostgreSQL增量同步	Debezium+Canal中间层，或商业ETL工具	10.1不是消息队列原生客户端，需要中间层
SQLServer→PostgreSQL	商业ETL工具、ODBC桥接	数据类型兼容性差，优先做转换验证

我当时在一个项目里需要把MySQL的业务库同步到PostgreSQL做分析，最终用的是“全量pgloader+增量Debezium”的组合。一开始想直接让Debezium连PostgreSQL，但解耦后更稳定：Debezium监听MySQL binlog，把变更写到Kafka，下游消费者再写进PostgreSQL。这套模式对版本依赖不高，10.1也能用，但你需要自己处理数据类型映射。比如MySQL的tinyint(1)和datetime，在PostgreSQL里最好分别映射为boolean和timestamp with time zone，否则查询语义会对不上。

4.3 Docker化部署10.1的注意点

用Docker部署PostgreSQL是这几年最流行的方式，10.1的官方镜像存在于Docker Hub，但在容器里跑老版本时有几个坑需要注意。

首先是数据卷权限。官方镜像通常声明VOLUME /var/lib/postgresql/data，但如果你把宿主机目录挂载进去，目录属主和SELinux上下文都要确认。我在CentOS 7上用docker compose部署时曾遇到“Permission denied”错误，最后用chown -R 999:999解决，因为容器内postgres用户的UID是999。

其次是参数调整。容器镜像默认的配置偏向开箱即用，但如果要跑高并发，需要挂载自定义postgresql.conf并映射到容器内/etc/postgresql/或直接使用command: postgres -c shared_buffers=512MB这样的方式覆盖参数。

一个简单的docker compose示例：

yaml复制version: '3'
services:
  postgres:
    image: postgres:10.1
    container_name: pg10
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test123
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./postgresql.conf:/etc/postgresql/postgresql.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf

volumes:
  pgdata:

注意，PostgreSQL 10的官方Docker镜像默认使用/var/lib/postgresql/data，但10.x镜像是兼容旧版路径的，如果你用的是14或更新的版本路径一样，所以一般不用改。

4.4 10.1能跑pgvector吗？老版本与新扩展的兼容性

搜索热词里能看到“postgresql pgvector”和“pgvector windows dll download postgresql 16”。这里必须明确一个结论：pgvector项目本身要求较新版本的PostgreSQL。根据官方README，pgvector 0.5.0支持PostgreSQL 10+，但0.6.0之后最低要求升到了11，再往后的版本要求13甚至更高。所以如果你手上只有10.1，想用pgvector做向量检索，大概率装不上最新版，只能找早期版本碰运气，而且老版本对新类型和索引的支持十分有限。

这不是说10.1“完全不能碰AI场景”，而是你要做一个务实的判断：如果核心业务要用向量检索，建议直接把PostgreSQL升到14以上。如果只是临时试验，可以在10.1上用cube扩展模拟低维向量相似度计算，CREATE EXTENSION cube;就能用欧氏距离、切比雪夫距离做简单匹配，但性能和功能都远不如pgvector。

4.5 通过ODBC连接PostgreSQL的落地细节

热搜词里有“excel通过odbc连接postgresql”，这个需求在10.1时代很常见，很多人用Excel拉PostgreSQL数据做报表。实现方式就是装PostgreSQL ODBC驱动。

以Windows环境为例：

下载并安装psqlODBC，版本要和PostgreSQL版本匹配或向下兼容，我用10.1时装的psqlODBC 11.x也能正常连。
打开ODBC数据源管理器，添加系统DSN，选“PostgreSQL Unicode”驱动。
配置Server、Port、Database、User Name、Password。
连接测试通过后，Excel里用“数据→获取数据→来自其他源→从ODBC”选择对应DSN即可。

这个过程中最容易出错的是字符集：如果数据库是UTF8，而驱动没选Unicode，中文会出现乱码。所以一定要选“PostgreSQL Unicode（x64）”而不是非Unicode版本。

5. 从10.1文档出发的进阶路线：哪些知识能沉淀，哪些必须重新学

5.1 十年不变的知识沉淀

翻完10.1的中文PDF，你会发现有些知识放到今天依然毫不过时，因为它们是关系型数据库的内功心法：

SQL标准语法：SELECT、JOIN、GROUP BY、窗口函数的写法、事务的ACID等，这些属于通用SQL能力，任何版本都得会。
MVCC与隔离级别的底层逻辑：PostgreSQL的多版本并发控制机制、READ COMMITTED和REPEATABLE READ的行为差异，这部分从9.x到17基本稳定。
WAL机制与崩溃恢复：wal_level、checkpoint、archive_command这些概念是理解备份恢复和高可用的钥匙，不管升到哪个版本都要懂。
流复制架构原理：虽然10.1的配置方式和14+差别很大，但主备复制、时间线、WAL的推拉模型没变。

5.2 必须被更新的部分

所谓“文档是静态的，技术是活的”。10.1 PDF里有几个知识点在接触新版本时一定要主动更新：

配置方式：从recovery.conf变成了standby.signal和primary_conninfo直接放postgresql.conf。
输出格式和默认行为：工具链的输出细节变了。比如psql的连接参数、pg_ctl的选项，虽然大体兼容，但版本升级后建议重新读一遍新版Documentation的Change Log。
版本支持状态：PostgreSQL 10.1早已结束官方生命周期，不再有安全更新。如果是在公网环境跑生产业务，只因为这个版本“够用”就不升级，风险非常大。我个人建议至少迁移到12或14及以上。
新功能与技术趋势：声明式分区在10.1只是初版，到了11有哈希分区，到了12分区裁剪大幅强化，触发器和约束行为也更完善。如果你在10.1文档里学到某个功能“不支持”，不一定代表新版还不支持。

5.3 带着旧文档学新知识的具体方法

我自己的习惯是“新旧对照法”：

选定一个专题（比如“分区表”或“逻辑复制”）。
先读10.1 PDF对应章节，把原理和初步用法搞清楚。
打开最新版官方文档同一章节，看“What’s New”和参数变化。
在测试环境把新语法跑一遍，刻意对比新旧行为差异。
把差异记录下来，形成自己的笔记。

这个方法比直接看新版文档更快，因为旧版手册往往解释得更细致，而新版手册会默认你已经懂了很多背景。所以这份PostgreSQL10.1-CN-v1.0.pdf虽然老了，依然可以作为学习体系里的一张“地图”，帮你在庞大知识库里找到正确答案的路径。

5.4 最后的实操建议

如果你现在正准备在一台CentOS/RHEL 7服务器上部署PostgreSQL 10.1，我的最终建议是：先用这份PDF把整体概念读完，然后立刻在测试环境把“初始化、启动、建表、备份恢复、流复制”完整走一遍。网上很多人配置失败，就是因为忽略了一个最简单的事实——PostgreSQL的配置项和术语一旦理解错了，后面每一步都是连环坑。PDF文档的作用，就是让你先看懂“为什么”，再动手“怎么做”。

时间充裕的话，建议把官方手册里的Chapter 5、11、20、24、26这五章反复看两遍。这五章覆盖了日常运维和架构设计的绝大部分核心问题。等你在新版数据库上遇到问题时，大概率会发现：“哦，这个问题的原理，10.1文档里早就讲过了。”