数据库的平安性和高可用性简直就是我们的命根子。想象一下 如果你辛辛苦苦运营了几年的网站，主要原因是一次硬盘故障或者手滑误操作导致数据瞬间蒸发，那种感觉恐怕比失恋还要难受吧？别担心， 今天我们要聊的这个话题——Debian下的PostgreSQL复制就是专门为了解决这种焦虑而生的，来日方长。。

很多朋友一听到“复制”或者“集群”这种词， 脑海里就会浮现出复杂的网络拓扑图，或者是一堆看不懂的代码，觉得这一定是资深DBA的专属领域。其实不然 只要你有一台装好Debian的服务器，还有一点点动手的勇气，搭建一套PostgreSQL的主从复制并没有你想象中那么难。这不仅能让你在数据备份时睡个安稳觉，还能在需要迁移数据时从容不迫。来搬好小板凳，我们这就开始深入探讨，何不...。

为什么要折腾PostgreSQL复制？

在正式敲代码之前，我们得先明白“为什么”。毕竟多学一个技能就是为了少踩一个坑嘛。PostgreSQL作为世界上最先进的开源关系型数据库， 我血槽空了。 它的功能强大到令人发指，但默认安装后它只是一个单节点的实例。这意味着什么？意味着这台服务器就是你的“单点故障”。

说真的... 一旦这台机器挂了你的服务就停了。而且， 如果你只有每天凌晨三点的一次全量备份，一旦在下午两点发生故障，你从凌晨到下午两点这段时间的数据就全部丢失了。这种代价，对于大多数业务都是不可接受的。

这时候，复制就闪亮登场了。简单复制就是把主数据库上的所有操作，实时地同步到另一台从数据库上。这样，主库负责读写，从库负责只读或者作为热备。 闹乌龙。 一旦主库挂了从库可以立马顶上去，数据几乎零丢失。这就是我们常说的“高可用”和“灾难恢复”。

准备工作：工欲善其事， 必先利其器

我们要动手实操，先说说得有两台机器。为了演示方便， 假设我们有两台安装了Debian的服务器：，你猜怎么着？

• 主节点IP地址为 192.168.1.10
• 从节点IP地址为 192.168.1.11

当然你可以用虚拟机，也可以用云服务器，甚至可以是两台放在角落里吃灰的旧电脑。确保两台机器已经安装了PostgreSQL。如果没有安装，一句简单的 sudo apt update && sudo apt install postgresql 就能搞定。这里我们假设PostgreSQL的版本是主流的12或更高版本， 主要原因是不同版本在配置文件路径上可能会有细微差别，但大体逻辑是一致的。

方式一：流复制——最稳健的物理同步

流复制是PostgreSQL中最常用、也是最推荐的一种复制方式。它基于WAL协议。你可以把它想象成主库在写日记，从库在实时抄写这篇日记。主要原因是它是物理层面的字节级复制，所以同步效率极高，延迟极低，非常适合做高可用架构。

第一步：配置主节点

先说说我们要在主节点上进行一些“手术”。我们需要告诉PostgreSQL：“嘿，老兄，你要允许别人连接你，还要把你的日志发给别人。”，站在你的角度想...

至于吗？ 打开主节点的配置文件 /etc/postgresql//main/postgresql.conf。找到或修改以下参数：

listen_addresses = '*'  # 监听所有IP地址， 别只盯着localhost看了
wal_level = replica     # 这一步很关键，必须设置为replica才能开启流复制
max_wal_senders = 10    # 最多允许多少个并发发送进程，给个宽裕点的数字
wal_keep_size = 1GB     # 保留多少WAL日志不回收，防止从节点跟不上时日志被删了
hot_standby = on        # 允许从节点在恢复期间进行只读查询

改完配置，还没完。我们还得给从节点发一张“通行证”。编辑 /etc/postgresql//main/pg_hba.conf 文件，这是PostgreSQL的访问控制列表。在文件末尾添加如下内容：，我emo了。

# 允许从节点通过replicator用户进行复制连接
host    replication     replicator      192.168.1.11/32      md5

这里我们指定了一个专门用于复制的用户叫 replicator。当然这个名字你可以随便起，只要你自己记得住就行。接下来我们需要在数据库里创建这个用户，并给它赋予复制的权限。

切换到postgres用户并进入命令行：

sudo -u postgres psql

然后施行SQL：

CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD '你的强密码';
\q

好了 主节点的准备工作差不多了记得重启一下PostgreSQL服务让配置生效：，琢磨琢磨。

sudo systemctl restart postgresql

第二步：初始化从节点

现在轮到从节点上场了。从节点本质上就是主节点的一个“克隆体”。我们不需要手动去安装表结构， PostgreSQL提供了一个非常强大的工具叫 pg_basebackup它可以把主节点的数据整个拉过来。

先说说停止从节点上的PostgreSQL服务。主要原因是我们要把它的数据目录清空， 用主库的数据覆盖掉：，说起来...

sudo systemctl stop postgresql

你没事吧？ 为了平安起见，建议先备份一下从节点原有的数据目录，然后清空它：

sudo mv /var/lib/postgresql//main /var/lib/postgresql//main_old_backup
sudo mkdir /var/lib/postgresql//main
sudo chown postgres:postgres /var/lib/postgresql//main

现在施行 pg_basebackup 命令。这一步就像是把主库的灵魂拷贝过来：

sudo -u postgres pg_basebackup -h 192.168.1.10 -D /var/lib/postgresql//main -U replicator -P -v -R -X stream

累并充实着。 这里解释一下参数的含义：-h 指定主库IP， -D 指定数据目录，-U 指定刚才创建的用户，-P 显示进度，-v 显示详细信息，-R 自动创建 standby.signal 文件并写入连接信息，-X stream 表示流式传输WAL日志。

输入密码后看着进度条跑完，你的从节点就已经拥有了主库的所有数据。

第三步：启动从节点并验证

主要原因是我们在 pg_basebackup 时加了 -R 参数，PostgreSQL已经帮我们自动配置好了 postgresql.auto.conf 并创建了 standby.signal 文件。 我无法认同... 这意味着从节点知道它自己是个“备胎”，启动后会自动去连主库。

直接启动从节点服务：

sudo systemctl start postgresql

如果一切顺利， 没有报错，那么恭喜你！你已经成功搭建了流复制。怎么验证呢？回到主节点， 查询一下：，心情复杂。

sudo -u postgres psql -c "SELECT * FROM pg_stat_replication;"

如果你看到一行记录，其中的 state 是 streaming那就说明数据正在像流水一样源源不断地从主库流向从库。是不是很有成就感，也是没谁了。？

方式二：逻辑复制——更灵活的数据选择

流复制虽然好，但它有个特点：它是“全有或全无”的。它复制的是整个物理存储。如果你只想同步某几张表，或者你的主从数据库版本跨度比较大，这时候流复制可能就有点力不从心了，尊嘟假嘟？。

这是可以说的吗？ 这时候，逻辑复制 就派上用场了。逻辑复制是基于“发布”和“订阅”模型的。你可以把它想象成订阅公众号：主库发布文章，从库订阅了这些文章，就能收到推送。你可以选择只订阅某些表的数据。

第一步：调整主节点配置

逻辑复制对WAL日志的要求更高，所以我们需要把 wal_level 设置为 logical。同样是在主节点的 postgresql.conf 中：

wal_level = logical
max_replication_slots = 4   # 需要足够的复制槽来支持订阅
max_wal_senders = 10

别忘了重启主库：

sudo systemctl restart postgresql

第二步：创建发布

在主库上，我们需要指定哪些表的数据需要被发布。假设我们有一个叫 test_db 的数据库，里面有一张表 users，我CPU干烧了。。

连接到主库：

sudo -u postgres psql

创建发布：

CREATE PUBLICATION my_publication FOR TABLE users;

不妨... 当然 你也可以把 FOR TABLE users 换成 FOR ALL TABLES那就跟流复制差不多了只不过是基于逻辑的。

第三步：从节点订阅

在从节点上，我们不需要像流复制那样停机拷贝整个数据目录。我们只需要在从库上创建好对应的表结构，换言之...。

假设从库上已经有了 test_db 和 users 表。现在 我们创建订阅：，栓Q！

CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=192.168.1.10 dbname=test_db user=replicator password=你的密码'
PUBLICATION my_publication;

施行完这条命令，从节点就会立刻连接主节点，开始拉取 users 表的增量数据。你可以试着在主库插入一条数据，然后在从库查询，应该马上就能看到了，没耳听。。

流复制 vs 逻辑复制：到底选哪个？

看到这里你可能会犯嘀咕：“这两种方法我都学会了但我实际工作中该用哪一个呢？” 这确实是个好问题。为了让你更直观地做决定， 我特意整理了一个对比表格：

特性	流复制	逻辑复制
复制粒度	整个实例	指定表或数据库
主从版本要求	主从版本必须一致，大版本升级通常需要停机	允许主从版本存在差异，适合滚动升级
性能开销	较低，直接传输WAL日志	相对较高，需要解码逻辑日志
从库可写性	默认只读，但可以配置临时表	默认只读，但可以配置冲突检测
典型场景	高可用、读写分离、灾难恢复	数据迁移、报表分析、跨版本升级、部分数据同步

维护与排错：别慌，有我在

搭建好了并不代表万事大吉，运维的工作才刚刚开始。在实际使用中，你可能会遇到各种奇奇怪怪的问题。 无语了... 比如网络抖动导致复制中断了怎么办？

深得我心。 对于流复制PostgreSQL非常智能。只要网络恢复，从节点会自动尝试重新连接主节点，并继续同步WAL日志。只要你的 wal_keep_size 设置得足够大， 或者你配置了归档槽，数据就不会丢失。

如果你发现从节点一直报错 FATAL: could not connect to primary server: No route to host那多半是防火墙在作祟。记得检查一下两台机器的防火墙规则，确保5432端口是开放的。在Debian上， 通常使用UFW：

sudo ufw allow 5432/tcp

也是没谁了... 再说一个，监控也是必不可少的。你可以写个简单的脚本， 定期查询 pg_stat_replication 视图，检查 lag是否在可接受范围内。如果延迟越来越大，那就要警惕了可能是从节点的硬件性能跟不上，或者是网络带宽被打满了。

数据平安， 永无止境

好了说了这么多，相信你对Debian下的PostgreSQL复制已经有了一个比较全面的认识了。从流复制的物理同步， 到逻辑复制的灵活订阅，PostgreSQL为我们提供了强大的工具来守护数据的平安，稳了！。

技术这东西，光看不练假把式。我强烈建议你找个空闲的周末，按照上面的步骤亲手敲一遍命令。当你看到屏幕上显示 streaming 状态的那一刻，那种掌控数据的快感是无法言喻的。而且， 一旦你掌握了这些技能，无论是面对老板要求的“数据零丢失”SLA，还是面对半夜三点的故障报警，你都能淡定地喝一口茶，从容应对，YYDS！。

未来可期。 记住没有“后悔药”，只有“备份”和“复制”。希望这篇文章能成为你技术进阶路上的垫脚石。如果你在实践过程中遇到了什么坑， 或者有什么独家的排错技巧，也欢迎在评论区分享出来大家一起避坑，一起进步！

---