PostgreSQL 复制解决方案全面对比

PostgreSQL 提供了多种复制和高可用性解决方案，每种都有其独特的优势和适用场景。本文将深入分析各种复制方案的技术特点、应用场景和最佳实践。

复制方案概览

在现代数据库架构中，高可用性和数据冗余是关键需求。PostgreSQL 提供了从简单的共享存储到复杂的多主复制等多种解决方案。

1. 共享磁盘故障转移

技术原理

共享磁盘故障转移通过使用单个共享存储设备来避免数据同步的复杂性。多个服务器共享同一个磁盘阵列，但在任何时刻只有一个服务器处于活动状态。

业务应用场景

适用场景：

• 金融交易系统：需要零数据丢失的核心交易处理
• ERP 系统：企业关键业务数据不能丢失
• 电商订单系统：订单数据的完整性至关重要

实际部署示例

存储配置

# 配置共享存储 (示例：使用 iSCSI)
sudo iscsiadm -m discovery -t st -p 192.168.1.100:3260

# 挂载共享存储
sudo mount /dev/sdb1 /var/lib/postgresql/data

# 确保文件系统权限正确
sudo chown -R postgres:postgres /var/lib/postgresql/data

故障转移脚本

#!/bin/bash
# 自动故障转移脚本

# 检查主服务器状态
if ! pg_isready -h primary-server -p 5432; then
    echo "主服务器不可用，开始故障转移..."

    # 挂载共享存储
    mount /dev/shared_disk /var/lib/postgresql/data

    # 启动 PostgreSQL
    systemctl start postgresql

    # 更新 DNS 或负载均衡器配置
    update_dns_to_standby_server
fi

优势与限制

TIP

优势

• 零数据丢失：由于使用单一数据源，不存在同步延迟
• 快速故障转移：通常在几秒到几分钟内完成
• 简单架构：无需复杂的同步机制

WARNING

限制

• 单点故障：共享存储本身成为单点故障
• 硬件依赖：需要专门的共享存储设备
• 地理限制：备用服务器必须能物理访问共享存储

2. 文件系统（块设备）复制

技术原理

文件系统复制在块设备级别进行数据镜像，确保远程服务器拥有主服务器文件系统的完整副本。DRBD（Distributed Replicated Block Device）是 Linux 环境下最流行的解决方案。

配置示例

DRBD 配置

# /etc/drbd.d/postgresql.res
resource postgresql {
    device /dev/drbd0;
    disk /dev/sdb1;
    meta-disk internal;

    on primary-server {
        address 192.168.1.10:7788;
    }

    on standby-server {
        address 192.168.1.11:7788;
    }
}

初始化和同步

# 在两台服务器上创建 DRBD 资源
sudo drbdadm create-md postgresql

# 在主服务器上启动同步
sudo drbdadm up postgresql
sudo drbdadm primary postgresql --force

# 创建文件系统
sudo mkfs.ext4 /dev/drbd0

# 挂载并配置 PostgreSQL
sudo mount /dev/drbd0 /var/lib/postgresql/data

业务场景分析

问题解决：

• 地理分布：解决了共享磁盘的地理限制问题
• 成本控制：无需昂贵的共享存储设备
• 网络复制：通过网络实现跨地域的数据保护

实际应用：

3. 预写日志（WAL）传输

技术架构

PostgreSQL 的内置流复制通过传输 WAL（Write-Ahead Log）记录来保持备用服务器同步。这是 PostgreSQL 最推荐的复制方案。

配置实战

主服务器配置

-- postgresql.conf
wal_level = replica                    -- 启用复制级别的 WAL
max_wal_senders = 3                   -- 最大 WAL 发送进程数
max_replication_slots = 3             -- 最大复制槽数
archive_mode = on                     -- 启用 WAL 归档
archive_command = 'cp %p /archive/%f' -- 归档命令

-- pg_hba.conf
# 允许复制连接
host replication replica 192.168.1.0/24 trust

备用服务器设置

# 创建基础备份
pg_basebackup -h primary-server -D /var/lib/postgresql/data \
              -U replica -v -P -W

# standby.signal 文件（PostgreSQL 12+）
touch /var/lib/postgresql/data/standby.signal

# postgresql.conf
primary_conninfo = 'host=primary-server port=5432 user=replica'
restore_command = 'cp /archive/%f %p'
recovery_target_timeline = 'latest'

创建复制用户

-- 在主服务器上创建复制用户
CREATE USER replica REPLICATION LOGIN ENCRYPTED PASSWORD 'password';

-- 查看复制状态
SELECT
    client_addr,
    state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

同步模式对比

模式	数据一致性	性能影响	故障转移	适用场景
异步复制	可能丢失少量数据	最小影响	快速	大多数应用场景
同步复制	零数据丢失	有延迟	稍慢	关键业务系统
远程写入	保证持久性	中等影响	中等	平衡方案

性能监控实例

-- 监控复制延迟
WITH replication_lag AS (
    SELECT
        client_addr,
        application_name,
        CASE
            WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()
            THEN 0
            ELSE EXTRACT(EPOCH FROM (
                now() - pg_last_xact_replay_timestamp()
            ))::INT
        END AS lag_seconds
    FROM pg_stat_replication
)
SELECT * FROM replication_lag WHERE lag_seconds > 5;

-- 输出示例：
--   client_addr   | application_name | lag_seconds
-- ----------------+------------------+-------------
--  192.168.1.11   | standby1        |          12

4. 逻辑复制

技术特点

逻辑复制基于数据更改而非物理文件，允许更灵活的复制策略，包括跨版本复制、选择性表复制等。

实战配置

发布端配置

-- 修改配置参数
ALTER SYSTEM SET wal_level = logical;
ALTER SYSTEM SET max_replication_slots = 4;
ALTER SYSTEM SET max_wal_senders = 4;

-- 重启后创建发布
CREATE PUBLICATION sales_pub FOR TABLE orders, customers;

-- 查看发布状态
SELECT pubname, puballtables, pubinsert, pubupdate, pubdelete
FROM pg_publication;

订阅端配置

-- 创建订阅（会自动创建复制槽）
CREATE SUBSCRIPTION sales_sub
CONNECTION 'host=publisher-server dbname=salesdb user=replica'
PUBLICATION sales_pub;

-- 监控订阅状态
SELECT
    subname,
    pid,
    received_lsn,
    latest_end_lsn,
    latest_end_time
FROM pg_subscription_stats;

高级应用场景

1. 数据仓库 ETL 场景

-- 业务问题：将 OLTP 数据实时同步到 OLAP 系统
-- 解决方案：选择性逻辑复制

-- 在 OLTP 服务器创建只读分析发布
CREATE PUBLICATION analytics_pub FOR TABLE
    sales_transactions (transaction_id, amount, timestamp),
    customer_profiles (customer_id, segment, region);

-- 在数据仓库服务器订阅
CREATE SUBSCRIPTION analytics_sub
CONNECTION 'host=oltp-server dbname=production user=analytics_replica'
PUBLICATION analytics_pub;

2. 微服务数据分离

-- 业务场景：将单体数据库按业务域拆分
-- 用户服务只需要用户相关表
CREATE PUBLICATION user_service_pub FOR TABLE users, user_profiles, user_settings;

-- 订单服务只需要订单相关表
CREATE PUBLICATION order_service_pub FOR TABLE orders, order_items, payments;

冲突处理机制

WARNING

数据冲突处理逻辑复制可能遇到数据冲突，特别是在双向复制场景下：

-- 查看冲突信息
SELECT * FROM pg_stat_subscription_stats WHERE subname = 'my_subscription';

-- 常见冲突类型：
-- 1. 主键冲突：INSERT 的行已存在
-- 2. 更新冲突：UPDATE 的行不存在
-- 3. 删除冲突：DELETE 的行不存在

5. 基于触发器的复制

应用场景

虽然现代 PostgreSQL 有了更好的选择，但基于触发器的复制在某些特殊场景下仍有价值，如需要复杂数据转换的跨版本迁移。

Slony-I 示例

-- 创建复制集
SELECT slonik_init_cluster(1, 'Master Node');

-- 添加表到复制集
SELECT slonik_create_set(1, 'Replication Set 1');
SELECT slonik_set_add_table(1, 1, 'public.orders', 'id');

-- 订阅复制集
SELECT slonik_subscribe_set(1, 2, 1, true);

6. SQL 复制中间件

Pgpool-II 架构

SQL 复制中间件在应用和数据库之间提供透明的负载均衡和复制功能。

配置示例

pgpool.conf配置

# 连接池设置
listen_addresses = '*'
port = 9999
pcp_listen_addresses = '*'
pcp_port = 9898

# 负载均衡
load_balance_mode = on
master_slave_mode = on

# 后端数据库配置
backend_hostname0 = '192.168.1.10'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/data'
backend_flag0 = 'ALLOW_TO_FAILOVER'

backend_hostname1 = '192.168.1.11'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/data'
backend_flag1 = 'ALLOW_TO_FAILOVER'

读写分离测试

-- 写操作会路由到主服务器
INSERT INTO orders (customer_id, amount) VALUES (1001, 299.99);

-- 读操作会分发到备用服务器
SELECT COUNT(*) FROM orders WHERE create_date >= CURRENT_DATE;

-- 查看连接分布
SHOW pool_nodes;
/*
node_id | hostname     | port | status | lb_weight | role    | backend_status
--------|--------------|------|--------|-----------|---------|---------------
0       | 192.168.1.10 | 5432 | up     | 0.500000  | primary | up
1       | 192.168.1.11 | 5432 | up     | 0.500000  | standby | up
*/

7. 多主复制方案

异步多主复制

Bucardo 示例配置

异步多主复制允许多个数据库同时接受写入，通过定期同步来保持一致性。

# 安装和配置 Bucardo
bucardo install --piddir=/var/run/bucardo

# 添加数据库
bucardo add db master1 dbname=salesdb host=server1
bucardo add db master2 dbname=salesdb host=server2

# 创建同步规则
bucardo add table orders db=master1
bucardo add sync orders_sync dbs=master1,master2 tables=orders

同步多主复制

同步多主复制确保所有写入在提交前都同步到所有节点，提供强一致性但牺牲性能。

-- 使用两阶段提交实现同步多主
-- 阶段1：准备事务
PREPARE TRANSACTION 'tx_12345';

-- 在所有节点确认准备成功后
-- 阶段2：提交事务
COMMIT PREPARED 'tx_12345';

复制方案选择决策矩阵

功能对比表

功能特性	共享磁盘	文件系统复制	WAL 传输	逻辑复制	触发器复制	SQL 中间件	异步多主	同步多主
流行实现	NAS/SAN	DRBD	内置流复制	内置逻辑复制	Slony-I	Pgpool-II	Bucardo	自定义
通信方式	共享存储	块设备	WAL 流	逻辑解码	表行级	SQL 语句	表行级	行锁定
硬件要求	专用存储	✅ 标准硬件	✅ 标准硬件	✅ 标准硬件	✅ 标准硬件	✅ 标准硬件	✅ 标准硬件	✅ 标准硬件
多主支持	❌	❌	❌	✅ 有限	❌	✅	✅	✅
主服务器开销	✅ 无	⚠️ 有	✅ 最小	✅ 最小	⚠️ 有	✅ 最小	⚠️ 有	⚠️ 高
数据丢失风险	✅ 无	✅ 无	⚠️ 异步模式有	⚠️ 异步模式有	⚠️ 可能	✅ 无	⚠️ 可能	✅ 无
只读查询支持	❌	❌	✅ 热备用	✅	✅	✅	✅	✅
表级粒度	❌	❌	❌	✅	✅	❌	✅	✅
配置复杂度	🟢 简单	🟡 中等	🟡 中等	🟡 中等	🔴 复杂	🟡 中等	🔴 复杂	🔴 复杂

场景选择指南

TIP

选择建议

高可用性 + 零数据丢失

• 首选：WAL 流复制（同步模式）
• 备选：共享磁盘故障转移

读负载分担 + 可接受少量延迟

• 首选：WAL 流复制（异步模式）
• 备选：逻辑复制

跨版本升级 + 选择性复制

• 首选：逻辑复制
• 备选：基于触发器复制

多点写入 + 高可用性

• 首选：异步多主复制
• 备选：SQL 复制中间件

金融级一致性 + 多主写入

• 首选：同步多主复制
• 备选：应用层分布式事务

性能优化与监控

关键监控指标

-- WAL 复制延迟监控
SELECT
    application_name,
    client_addr,
    state,
    CASE
        WHEN pg_is_in_recovery() THEN
            pg_last_wal_receive_lsn() - pg_last_wal_replay_lsn()
        ELSE
            sent_lsn - flush_lsn
    END AS lag_bytes,
    EXTRACT(EPOCH FROM (now() - backend_start))::INT AS connection_age
FROM pg_stat_replication;

-- 逻辑复制槽监控
SELECT
    slot_name,
    plugin,
    slot_type,
    database,
    active,
    restart_lsn,
    confirmed_flush_lsn,
    pg_size_pretty(
        pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
    ) AS lag_size
FROM pg_replication_slots;

性能调优参数

主服务器优化

# 提高 WAL 写入性能
wal_buffers = 32MB                    # WAL 缓冲区大小
wal_writer_delay = 10ms               # WAL 写入延迟
checkpoint_completion_target = 0.9    # 检查点完成目标

# 复制性能优化
max_wal_size = 4GB                   # 最大 WAL 大小
wal_keep_size = 1GB                  # 保留的 WAL 大小

备用服务器优化

# 恢复性能优化
recovery_min_apply_delay = 0         # 最小应用延迟
hot_standby_feedback = on            # 热备用反馈
max_standby_streaming_delay = 30s    # 最大流式备用延迟

# 查询性能优化
hot_standby = on                     # 启用热备用查询
max_connections = 200                # 最大连接数

故障处理和最佳实践

常见故障场景

1. 复制中断处理

#!/bin/bash
# 复制故障恢复脚本

# 检查复制状态
if ! psql -h standby-server -c "SELECT pg_is_in_recovery();" | grep -q "t"; then
    echo "备用服务器未处于恢复模式，开始重建..."

    # 停止备用服务器
    systemctl stop postgresql

    # 清除旧数据
    rm -rf /var/lib/postgresql/data/*

    # 重新创建基础备份
    pg_basebackup -h primary-server -D /var/lib/postgresql/data \
                  -U replica -v -P -W

    # 重启服务
    systemctl start postgresql
fi

2. 主备切换操作

-- 计划内主备切换
-- 在主服务器上停止写入并等待同步完成
SELECT pg_promote();  -- 在备用服务器上执行

-- 紧急故障转移
-- 直接在备用服务器执行
SELECT pg_promote();

-- 验证切换结果
SELECT pg_is_in_recovery();  -- 应返回 false

运维最佳实践

总结

PostgreSQL 的复制解决方案提供了从简单到复杂的完整选择范围。在选择复制方案时，需要综合考虑：

1. 业务需求：数据一致性要求、可接受的恢复时间目标（RTO）和恢复点目标（RPO）
2. 技术环境：现有基础设施、网络条件、运维能力
3. 成本因素：硬件成本、复杂性成本、运维成本
4. 扩展性：未来业务增长和技术演进的考虑

对于大多数应用场景，PostgreSQL 内置的流复制提供了最佳的性能、可靠性和易用性平衡。随着业务的发展，可以根据需要逐步演进到更复杂的复制架构。

选择合适的复制方案并正确实施，能够为业务系统提供强大的高可用性保障，确保数据安全和业务连续性。