从零开始学PostgreSQL (七)：高可用性、负载平衡和复制-CSDN博客

从零开始学PostgreSQL (七)：高可用性、负载平衡和复制_PostgreSQL

1. 不同解决方案的比较

2. 备用服务器

3. 流复制

4. 复制插槽

5. 级联复制

6. 同步复制

7. 待机状态下的连续存档

8. 注意事项

9.总结

在PostgreSQL中实现高可用性（HA）有多种方法，每种方法都有其特定的应用场景和优势。以下是针对不同解决方案的比较，以及对日志传送备用服务器和相关配置的总结：

不同解决方案的比较

特征	共享磁盘	文件系统备份	预写日志传送	逻辑复制	基于触发器的 Repl	SQL Repl. 中间件	异步。MM Repl	同步。MM Repl
热门示例	网络存储	DRBD	built-in streaming repl.	内置逻辑 repl.， pglogical	Londiste, Slony	pgpool-II型	Bucardo
通信方式	共享磁盘	磁盘块	WAL	逻辑解码	表行	SQL的	表行	表行和行锁
无需特殊硬件		•	•	•	•	•	•	•
允许多个主服务器				•		•	•	•
主数据库无开销	•		•	•		•
无需等待多台服务器	•		关闭同步	关闭同步	•		•
主故障永远不会丢失数据	•	•	同步开启	同步开启		•		•
副本接受只读查询			带热备用	•	•	•	•	•
每表粒度				•	•		•	•
无需解决冲突	•	•	•		•	•		•

PostgreSQL 提供了多种不同的解决方案来实现数据的高可用性和灾难恢复。这些解决方案包括热备用、流复制、级联复制、同步复制等。每种解决方案都有其特点和应用场景：

热备用：热备服务器可以接收主服务器的日志文件（归档日志），并在需要时恢复数据。这种方式适用于不需要实时数据同步的场景。
流复制：流复制提供了实时数据同步的功能，使备用服务器能够立即接替主服务器的角色。这种方式适用于需要快速故障转移的应用场景。
级联复制：级联复制允许将一个备用服务器配置为另一个备用服务器的上游，这样可以构建多层复制结构，降低网络带宽需求。
同步复制：同步复制确保数据在多个节点上同时提交，提高了数据安全性，但可能会增加写操作的延迟。
连续存档：连续存档是一种将归档日志持续写入到备用服务器的技术，即使主服务器没有崩溃也可以进行数据恢复测试。

备用服务器

如何为主服务器和备用服务器进行准备和配置？

待机模式和WAL应用

当备用服务器启动时，如果检测到standby.signal文件存在，它会进入待机模式。
在待机模式下，备用服务器会应用从主服务器接收到的WAL（Write-Ahead Log）记录，这些记录可以来自于WAL归档或通过流式复制直接从主服务器获取。
备用服务器优先从本地归档中恢复WAL，然后尝试从主服务器流式复制WAL，如果流式复制不可用或连接失败，它会继续尝试从归档中恢复。
这种机制确保了备用服务器可以持续更新，以备主服务器故障时迅速接管。

准备主服务器

主服务器应设置连续存档，确保WAL文件可被备用服务器访问，通常这意味着WAL文件应存储在备用服务器可及的位置，而非主服务器自身。
如果启用流式复制，主服务器需要设置适当的身份验证和连接参数，包括在pg_hba.conf中添加复制连接的条目，以及在postgresql.conf中设置max_wal_senders和max_replication_slots的值。
主服务器还需进行基础备份，以作为引导备用服务器的起点。

设置备用服务器

备用服务器的设置始于从主服务器的基础备份恢复。
必须在备用服务器的数据目录中创建standby.signal文件，指示它进入待机模式。
restore_command参数被设置为从WAL归档中恢复文件的命令。
如果计划使用流式复制，应在primary_conninfo中提供连接到主服务器的详细信息，包括认证凭据。
为了实现高可用性，备用服务器应配备与主服务器相同的WAL存档、连接和身份验证设置，因为故障转移后它将成为新的主服务器。
使用archive_cleanup_command参数和pg_archivecleanup工具可以帮助管理WAL文件的大小，但必须确保保留足够的文件以供备份和恢复使用。

配置示例

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000'''
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
提供的配置示例展示了如何设置primary_conninfo、restore_command和archive_cleanup_command参数，以确保流式复制的顺畅进行和WAL文件的有效管理

流式复制

流式复制的特点

实时性：备用服务器能够近乎实时地接收主服务器的WAL记录，减少了数据的延迟和潜在的数据丢失窗口。
异步性：默认情况下，流式复制是异步的，这意味着在主服务器提交事务与备用服务器可见之间会有短暂的延迟，但通常这个延迟小于基于文件的日志传送。

配置流式复制

主服务器配置：
设置listen_addresses以允许外部连接。
在pg_hba.conf中设置身份验证规则，允许备用服务器的复制连接。
配置max_wal_senders以允许多个备用服务器的连接。
备用服务器配置：
将primary_conninfo设置为主服务器的连接信息，包括主机名、端口、用户名和密码。
可能需要在.pgpass文件中存储密码，以自动完成身份验证过程。

# The standby connects to the primary that is running on host 192.168.1.50
# and port 5432 as the user "foo" whose password is "foopass".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

身份验证

安全考虑：复制连接应限制在受信任的用户中，建议使用具有REPLICATION权限的专用用户账户。
配置示例：在pg_hba.conf中添加MD5加密方法的行，允许特定IP地址的用户进行复制连接。

# Allow the user "foo" from host 192.168.1.100 to connect to the primary
# as a replication standby if the user's password is correctly supplied.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

监控流式复制

WAL延迟：监控主服务器与备用服务器之间的WAL记录延迟，通过对比pg_current_wal_lsn和pg_last_wal_receive_lsn来评估。
pg_stat_replication：使用这个视图来查看WAL发送进程的状态，帮助识别网络延迟或备用服务器负载问题。
pg_stat_wal_receiver：这个视图提供了WAL接收器的状态，帮助确定接收和重放之间的速度差异。

流式复制的配置和维护对于确保PostgreSQL高可用性和灾难恢复策略的成功至关重要。正确的配置可以大幅提高备用服务器的响应能力和数据一致性，同时有效的监控机制能够及时发现和解决复制过程中可能出现的问题。

复制插槽

复制插槽（Replication Slots）是PostgreSQL中用于增强流式复制稳定性和效率的重要功能。它们主要用于防止WAL（Write-Ahead Log）段提前被清理，直到备用服务器确认已经接收并处理了这些段。下面是关于复制插槽的几个关键点：

复制插槽的作用

WAL段保护：复制插槽确保主服务器不会过早地清理WAL段，直到所有连接的备用服务器都接收并应用了这些段。
热备保护：插槽可以防止因备用服务器断开连接而导致的数据恢复冲突，特别是在使用热备模式时。

替代方法

wal_keep_size：可以用来保存一定数量的WAL段，但这种方法可能导致不必要的WAL段保留。
归档命令：通过将WAL段归档到文件系统，可以避免过早清理，但这增加了管理负担。

复制插槽的优势

精确保留：复制插槽只保留实际需要的WAL段，避免了过度的磁盘空间占用。
热备反馈：结合hot_standby_feedback特性，复制插槽在备用服务器断开连接时仍能提供保护，防止数据行被错误地清理。

配置与操作

创建插槽：通过SQL函数pg_create_physical_replication_slot创建物理复制插槽。
查询插槽：使用pg_replication_slots视图查看插槽的状态和类型。
使用插槽：在备用服务器的配置中设置primary_slot_name参数，指明要使用的复制插槽名称。

示例

在PostgreSQL中创建复制插槽node_a_slot，并在备用服务器上将其设置为主服务器连接信息的一部分，如：

-- 创建复制插槽
SELECT * FROM pg_create_physical_replication_slot('node_a_slot');


-- 查看复制插槽
SELECT slot_name, slot_type, active FROM pg_replication_slots;

备用服务器的postgresql.conf中配置如下：

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
2primary_slot_name = 'node_a_slot'

复制插槽的使用极大地简化了PostgreSQL的流式复制管理，确保了数据的一致性和可靠性，同时也提高了资源利用的效率。

级联复制

级联复制是PostgreSQL中用于优化流式复制架构的一项功能，特别适用于大型或分布式部署，它可以减少主服务器的直接连接负载，同时最小化跨站点的网络带宽消耗。以下是关于级联复制的核心要点：

级联复制的结构

上游与下游服务器：在级联复制中，备用服务器分为上游和下游。上游服务器直接或间接连接到主服务器，而下游服务器连接到上游服务器。
级联备用数据库：这些备用服务器同时作为接收方和发送方，接收来自上游的WAL记录，然后将其转发给下游服务器。

功能与优势

带宽优化：通过减少直接连接到主服务器的备用服务器数量，级联复制可以显著降低跨站点的带宽需求。
灵活性：级联复制不限制下游服务器的数量或拓扑结构，尽管每个备用服务器仅连接到一个上游服务器。
连续性保障：即使上游连接中断，只要新的WAL记录可用，级联复制仍能保证数据流向下游服务器。

异步复制

异步性质：级联复制当前采用异步模式，意味着数据在主服务器和最终到达下游服务器之间可能存在延迟。

配置与操作

上游服务器设置：上游备用服务器需配置为接受复制连接，包括设置max_wal_senders、hot_standby以及基于主机的身份验证。
下游服务器配置：下游备用服务器应设置primary_conninfo，指向其上游服务器，以便接收WAL记录。

热备用反馈

反馈传播：热备用反馈会沿着级联复制的链路向上游服务器传播，无论复制拓扑如何安排。

故障转移

无缝过渡：如果上游备用服务器被提升为主服务器，下游服务器将自动从新的主服务器接收数据，前提是recovery_target_timeline被设置为'latest'（默认设置）。

级联复制是一种高度可扩展且经济的复制解决方案，尤其适用于地理分布广泛的数据库环境，它通过智能的数据流管理，显著提升了PostgreSQL高可用性和灾难恢复策略的效能。

同步复制

同步复制是PostgreSQL中一种增强的复制机制，旨在提供比异步复制更高级别的数据持久性和一致性，尤其是在主服务器崩溃的情况下。以下是关于同步复制的关键点：

同步复制原理

数据持久性：同步复制确保主服务器提交的事务变更在备用服务器上持久化前不会完成，这防止了因主服务器崩溃导致的数据丢失。
2-safe 复制：同步复制提供了2-safe级别的数据保护，意味着至少有两个副本存在于不同的物理位置上，增强了数据的安全性。

操作机制

等待确认：在同步复制模式下，主服务器的事务提交需要等待备用服务器的确认，即WAL记录已被写入备用服务器的预写日志。
响应时间影响：虽然增加了数据安全性，同步复制也增加了事务的响应时间，因为必须等待备用服务器的确认。

配置选项

synchronous_standby_names：必须设置此参数来指定哪些备用服务器被视为同步备用。可以通过优先级（FIRST）或仲裁（ANY）方式来确定同步备用的数目。
synchronous_commit：控制同步复制的行为，如remote_write（等待WAL写入备用服务器的磁盘缓存）或remote_apply（等待WAL应用完毕）。

多个同步备用