文件服务器 热备份,PostgreSQL 高可用性热备份服务器

连续归档可以配合随时准备取代失效主服务器的一个或多个备份服务器,用于创建一个高可用性(HA)集群。这个能力通常被称为热备份或日志传送(Log Shipping)。虽然主服务器和备份服务器只是松散的耦合在一起,但它们必须同时运行。主服务器以连续归档模式运行,备份服务器以连续恢复模式运行并从主服务器不停的读取 WAL 文件。因为数据库的表无需为此进行任何改变,所以与其它复制方法相比,额外的管理开销很小...
摘要由CSDN通过智能技术生成

连续归档可以配合随时准备取代失效主服务器的一个或多个备份服务器,用于创建一个高可用性(HA)集群。这个能力通常被称为热备份或日志传送(Log Shipping)。

虽然主服务器和备份服务器只是松散的耦合在一起,但它们必须同时运行。主服务器以连续归档模式运行,备份服务器以连续恢复模式运行并从主服务器不停的读取 WAL 文件。因为数据库的表无需为此进行任何改变,所以与其它复制方法相比,额外的管理开销很小。并且这种方法对主服务器的性能影响也很小。

直接移动 WAL 或在数据库服务器之间"传送"日志记录通常被称为日志传送(Log Shipping)。PostgreSQL 实现了基于文件的日志传送,意思是 WAL 记录每次移动一个完整的文件(WAL 段)。WAL 文件可以被轻易的在任意两个地点之间传送,不管是与邻近的系统还是地球另一面的系统。所需带宽取决于主服务器的事务发生速度。基于记录的日志传送也可以通过节23.4.4中讨论的自定义过程实现。

日志传送是异步的,也就是 WAL 记录在事务提交之后才被传送。也就是说主服务器遭遇致命故障后尚未传送的事务数据将会丢失。数据丢失的长度可以使用 archive_timeout 加以限制,比如限制为几秒钟。当然这么小的设置也导致了传送带宽的大幅增长。如果你期望将丢失的数据限制在一分钟之内,可能更好的办法是使用基于记录的日志传送。

因为不停的执行恢复过程,备份服务器在通常情况下是不能被访问的。由于恢复速度非常快,备份服务器通常在启用后只有很短的时间不能使用。因此,我们认为这个方案可以作为热备份来提供高可用性。将服务器从一个已归档的基础备份中恢复将可能耗费大量时间,所以这个方案只能用于灾难恢复而不能用于提供高可用性。

至少从数据库服务器的角度看,创建主服务器和备份服务器并令两者尽可能完全相同是非常明智的。特别是表空间的路径名必须保持完全一致,这样主

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值