在探讨PostgreSQL多主复制是否可行之前，我们需要先理清一个核心概念：PostgreSQL的原生架构设计初衷是基于单节点写入的。原生流复制主要是为了实现高可用和读写分离，它通过传输WAL（预写式日志）来保持备库的数据同步。如果强行在多个节点上同时进行写操作，就会面临严重的锁竞争、数据回滚以及事务一致性被破坏的问题。因此，直接在原生PostgreSQL上开启多主复制不仅不可行，还会导致数据损坏。
PostgreSQL原生架构与多主复制的理论冲突
PostgreSQL的并发控制依赖于多版本并发控制（MVCC）机制。在单机环境下，MVCC能够很好地处理并发读写，保证事务的隔离性。然而，在多主复制场景下，多个节点同时接收写请求，如果两个节点在同一时刻修改了同一行数据，就会产生经典的写写冲突。原生流复制是物理复制，它直接在数据块层面进行同步，无法识别逻辑层面的冲突，一旦备库尝试写入自己的数据，整个复制链路就会断裂。
此外，主键冲突是多主环境中最棘手的问题之一。如果两个节点同时插入相同主键的记录，原生机制无法自动解决这种冲突。为了实现多写，必须引入全局时钟或分布式锁，但这会极大增加写操作的延迟，违背了多主复制为了提升写性能的初衷。因此，原生PostgreSQL不具备直接支持多主复制的基因。
从架构设计的角度来看，原生流复制要求备库严格处于只读状态。虽然可以通过设置参数让备库接收写请求，但这些修改不会被记录到WAL日志中，也不会同步给主库，更会在后续主库数据同步时被覆盖或导致复制中断。这种物理层面的强一致性约束，决定了我们需要寻找逻辑层面的解决方案来实现多写。
基于触发器与逻辑复制的轻量级多写方案
既然物理复制行不通，开发者们转向了逻辑复制和触发器机制。PostgreSQL从版本10开始原生支持逻辑复制，它通过解析WAL日志将其转化为逻辑变更事件，再发布给订阅节点。基于这种机制，可以构建双向逻辑复制：节点A订阅节点B的变更，节点B同时订阅节点A的变更，从而实现多写。
然而，原生的逻辑复制并不支持冲突解决。如果发生冲突，订阅端会直接报错并停止复制。为了解决这个问题，通常需要借助第三方工具，如Bucardo或SymmetricDS。这些工具通常依赖数据库触发器来捕获数据变更，并在节点间同步。以下是一个简单的触发器记录变更日志的伪代码示例：
CREATE TABLE sync_log (
id SERIAL PRIMARY KEY,
table_name TEXT,
record_id INT,
operation CHAR(1),
sync_status BOOLEAN DEFAULT FALSE
);
CREATE OR REPLACE FUNCTION log_changes()
RETURNS TRIGGER AS $$
BEGIN
IF TG_OP = 'INSERT' THEN
INSERT INTO sync_log (table_name, record_id, operation)
VALUES (TG_TABLE_NAME, NEW.id, 'I');
RETURN NEW;
ELSIF TG_OP = 'UPDATE' THEN
INSERT INTO sync_log (table_name, record_id, operation)
VALUES (TG_TABLE_NAME, NEW.id, 'U');
RETURN NEW;
ELSIF TG_OP = 'DELETE' THEN
INSERT INTO sync_log (table_name, record_id, operation)
VALUES (TG_TABLE_NAME, OLD.id, 'D');
RETURN OLD;
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
这种基于触发器的方案虽然能够实现双向数据同步，但缺点非常明显。首先，触发器会带来显著的性能损耗，每次写操作都要额外执行触发器逻辑并写入日志表，导致写延迟大幅增加。其次，冲突解决逻辑复杂，通常只能依靠最后写入获胜策略，这在要求强一致性的金融级业务中是不可接受的。最后，这种方案对数据模型有诸多限制，例如必须保证主键在所有节点间唯一，通常需要配合序列步长或使用UUID。
BDR扩展与分布式架构的深度实践
为了在PostgreSQL上实现真正的多主复制，业界最成熟的方案是BDR（Bi-Directional Replication）。BDR是由2ndQuadrant公司开发的一个PostgreSQL异步多主复制扩展插件。它基于逻辑复制机制，但在底层进行了深度改造，内置了完善的冲突检测和解决机制。BDR不使用触发器，而是直接从WAL日志中提取逻辑变更，因此性能远高于传统的触发器方案。
BDR的核心优势在于其内置的冲突解决策略。当多个节点同时修改同一行数据时，BDR会根据节点的时钟戳或者应用层提供的冲突解决函数来自动处理。例如，使用最后更新时间戳策略时，BDR会保留时间戳最新的那条记录。此外，BDR还支持全局序列，确保不同节点插入的数据不会发生主键冲突。以下是一个配置BDR节点的概念性示例：
-- 在节点A上创建BDR组
SELECT bdr.create_group(
group_name := 'my_bdr_group',
node_name := 'node_a',
local_dsn := 'host=127.0.0.1 port=5432 dbname=mydb'
);
-- 在节点B上加入BDR组
SELECT bdr.join_group(
node_name := 'node_b',
local_dsn := 'host=127.0.0.1 port=5432 dbname=mydb',
join_dsn := 'host=127.0.0.1 port=5432 dbname=mydb'
);
尽管BDR提供了相对完善的多主复制能力，但它并非银弹。由于采用异步复制机制，BDR无法保证数据的强一致性，只能达到最终一致性。这意味着在发生网络分区时，节点间可能出现数据不一致的情况，需要依赖冲突解决机制来收敛。此外，BDR对数据库的DDL操作支持有限，执行表结构变更时需要特殊的锁机制，容易造成长时间的阻塞。因此，BDR更适合地理分布的多活数据中心、离线数据同步等对一致性要求相对宽松的场景，而不适合作为核心交易系统的强一致多写方案。
综上所述，PostgreSQL多主复制在技术上是可行的，但必须依赖逻辑复制或第三方扩展如BDR，而非原生物理流复制。在选择多写方案时，架构师必须权衡性能损耗、一致性要求和运维复杂度。对于大多数业务而言，采用单主多从配合读写分离仍然是性价比最高的架构；只有在明确的多活需求下，才应考虑引入BDR等复杂的多主复制方案。
PostgreSQL多主复制多写高可用BDR修改时间：2026-08-26 19:15:08