在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文件的大小，但必须确保保留足够的文件以供备份和恢复使用。
配置示例
代码语言：javascript复制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，并在备用服务器上将其设置为主服务器连接信息的一部分，如：
代码语言：javascript复制-- 创建复制插槽
SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
-- 查看复制插槽
SELECT slot_name, slot_type, active FROM pg_replication_slots;备用服务器的postgresql.conf中配置如下：
代码语言：javascript复制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应用完毕）。
多个同步备用
- 同步备用数量：可以指定一个或多个同步备用服务器，事务提交将等待所有同步备用服务器的确认。
- 备用服务器选择：通过FIRST或ANY方法选择同步备用服务器，前者基于优先级，后者基于仲裁。
视图监控
- pg_stat_replication：可以使用这个视图来监控备用服务器的同步状态，了解哪些服务器正在同步以及同步的状态。
性能规划
- 事务等待时间：同步复制增加了事务的响应时间，因为主服务器必须等待备用服务器的确认。
- 工作负载区分：应用程序可以区分关键和非关键数据，仅对关键数据使用同步复制，以优化整体性能。
- 网络考量：网络带宽应足够支持WAL数据的传输速率，避免成为瓶颈。
高可用性规划
- synchronous_standby_names：用于指定同步备用服务器的数量和优先级，确保至少有设定数量的同步备用服务器正常运行。
- 备用数据库状态：备用数据库必须达到“流式”状态才能参与同步复制，这一状态可通过pg_stat_replication视图检查。
- 故障转移：当主服务器与备用服务器隔离时，应立即故障转移到剩余备用服务器中的最佳候选者。
- 重新配置：如果无法维持所需数量的同步备用服务器，可能需要调整synchronous_standby_names配置，减少同步等待的服务器数量。
连续WAL存档
- 独立存档：备用服务器可以有自己的WAL存档，这样它会归档接收到的每个WAL分段，无论通过还原还是流式复制。
- 共享存档：主服务器和备用服务器可以共享WAL存档，但这需要更复杂的逻辑来避免覆盖同名但内容不同的文件。
- 档案模式：archive_mode设置为always时，即使在恢复或待机模式下也会启用归档功能，确保WAL文件完整无缺。
应用程序级控制
- synchronous_commit：可以按应用程序、用户或事务级别控制同步复制的使用，允许对关键操作提供更高水平的数据保护，而不影响非关键操作的性能。
这些策略和设置帮助PostgreSQL用户在数据安全性和系统性能之间找到合适的平衡点。
待机状态下的连续存档
在PostgreSQL中，当备用数据库（standby server）处于待机状态下，连续写前日志（WAL）存档的处理有以下两种主要方案：
1、独立存档：
- 当archive_mode设置为always时，备用数据库将为每个接收到的WAL分段调用归档命令，无论这些分段是通过归档文件还原还是通过流式复制获得。
- 这意味着备用服务器会维护自己的WAL存档，即使这些WAL分段最初是由主服务器产生的。
2、共享存档：
- 主服务器和备用服务器可以共享一个WAL存档区域。
- 在这种情况下，archive_command和archive_library必须检测是否已经有一个同名的WAL文件存在，以及该文件是否具有相同的内容。
- 需要特别小心，防止覆盖已有但内容不同的文件，除非两个文件完全一致，此时重复存档将被视为成功。
在共享存档中，为了避免竞态条件（race condition），即两台或多台服务器试图同时存档同一个文件的情况，系统必须确保存档操作能够原子性地完成。
如果archive_mode设置为on，那么在恢复或待机模式下，存档器会被启用。但是，如果备用服务器进行了升级，它只会在升级后开始存档由它自己产生的WAL分段，而不会存档那些在升级前由主服务器产生的WAL分段。为了在归档文件中获取完整的WAL序列，所有WAL分段在到达备用服务器之前必须已经被存档。
在基于文件的日志传送场景中，备用数据库只能还原那些在归档文件中找到的WAL分段。然而，如果启用了流式复制，那么备用数据库将不会从归档中还原WAL分段，而是直接从主服务器流式接收。
当服务器不在恢复模式下时，on和always模式之间没有区别，即服务器都会存档自己生成的WAL分段。
总的来说，这些机制确保了数据的冗余和一致性，同时也为灾难恢复提供了必要的基础。
注意事项
- 网络延迟：确保主服务器和备用服务器之间的网络延迟尽可能低，以减少复制延迟。
- 资源分配：为备用服务器分配足够的资源，以保证数据复制的速度和可靠性。
- 监控和报警：设置监控机制来检测复制状态的变化，并在出现问题时发出警报。
- 测试和验证：定期测试备用服务器的切换能力，并验证数据一致性。
- 安全性和权限：确保复制过程中的数据安全，合理设置用户权限。
总结
PostgreSQL 提供了丰富的工具和配置选项来支持日志传送备用服务器的设置。通过选择合适的复制方案并仔细规划，可以有效地实现高可用性和灾难恢复。然而，实施这些方案时需要注意网络配置、资源分配、监控和测试等方面的问题，以确保系统的稳定性和可靠性。
