PostgreSQL 10.1 手册_部分 III. 服务器管理_第 26 章 高可用、负载均衡和复制_26.4. 日志传送的替代方法

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
日志服务 SLS,月写入数据量 50GB 1个月
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: 26.4. 日志传送的替代方法 26.4.1. 实现 26.4.2. 基于记录的日志传送 前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的 restore_command。这是版本 8.4 及以下版本中唯一可用的选项。

26.4. 日志传送的替代方法

前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的 restore_command。这是版本 8.4 及以下版本中唯一可用的选项。 在这种设置中,设置standby_mode为关闭, 因为你要自行实现后备操作所需的轮询。关于这种实现的一个参考请见 pg_standby模块。

注意在这种模式中,服务器将一次应用一整个文件的 WAL, 因此如果你使用后备服务器来查询(见热备), 那么主服务器上的一个动作和后备服务器上该动作变得可见之间会有一个延迟, 该延迟对应着填满 WAL 文件的时间。archive_timeout 可以被用来缩短该延迟。还要注意你不能把流复制和这种方法组合起来使用。

在主服务器和后备服务器上都会发生的操作是通常的连续归档和恢复任务。 两个数据库服务器之间唯一的接触点是两者共享的 WAL 文件归档: 主服务器写这个归档,后备服务器读取这个归档。 必须要小心地保证来自独立主服务器的 WAL 归档不会混合在一起或者混淆。 如果归档只被后备操作需要,它不必很大。

使得两台松耦合的服务器一起工作的诀窍是在后备服务器上使用的 restore_command,当要求下一个 WAL 文件时, 会等待它在主服务器上变得可用。restore_command在后备服务器的recovery.conf文件中指定。正常的恢复处理将从 WAL 归档请求一个文件, 如果该文件不可用则会报告失败。对于后备处理来说下一个 WAL 文件不可用很正常, 因此后备服务器必须等待它出现。对于以.backup.history 结尾的文件没有必要等待,并且必须返回一个非零的返回码。一个等待的 restore_command可以用一种自定义的脚本编写, 在其中轮询下一个 WAL 文件的存在之后进行循环。也必须有某种方式来触发故障转移, 那将打断restore_command:打破循环并返回一个文件未找到错误给后备服务器。 这会结束恢复并且后备服务器将接下来变成一个正常的服务器。

一个合适的restore_command的伪代码是:

triggered = false;
while (!NextWALFileReady() && !triggered)
{
    sleep(100000L);         /* wait for ~0.1 sec */
    if (CheckForExternalTrigger())
        triggered = true;
}
if (!triggered)
        CopyWALFileForRecovery();

pg_standby模块中提供了一个等待的restore_command 的工作例子。它也可被用作如何正确实现上述逻辑的参考。 它也可以根据需要被扩展来支持指定的配置和环境。

触发故障转移的方法是规划和设计中的一个重要部分。一种潜在的选项是 restore_command命令。它对每一个 WAL 文件执行一次, 但是运行restore_command的进程会为每一个文件创建和死亡, 因此没有守护进程或服务器进程,并且也不能使用信号或信号句柄。因此, restore_command不适合于触发故障转移。可以使用一种简单的超时功能, 特别是和主服务器上已知的archive_timeout设置一起。但是, 由于一个网络问题或者繁忙的主服务器可能足以发起故障转移,这有点容易产生错误。 如果可以安排,一种提醒机制(例如显式创建一个触发器文件)是最理想的。

26.4.1. 实现

使用这种替代方案配置一个后备服务器的简短过程如下所示。对于每一步的细节, 可以参考之前的小节。

  1. 尽可能将主系统和后背系统设置成近乎一致, 包括在同一发行级别上的两个相同的PostgreSQL拷贝。

  2. 在后备服务器上建立从主系统到一个 WAL 归档目录的连续归档。 确保在主服务器上archive_mode、 archive_command和 archive_timeout被恰当地设置 (见第 25.3.1 节)。

  3. 建立主服务器的一个基础备份(见第 25.3.2 节), 并且把该数据载入到后备服务器。

  4. 在后备服务器上开始从本地 WAL 归档的恢复,在recovery.conf 中指定一个按之前所述进行等待的restore_command (见第 25.3.4 节)。

恢复将 WAL 归档当作只读的来处理,因此一旦一个 WAL 文件已经被复制到后备系统, 在它正在被后备数据库服务器读取时可以被同时复制到磁带。因此, 可以在为了长期灾难恢复目的存储文件的同时运行一个用于高可用性的后备服务器。

为了测试的目的,可以在一个相同的系统上运行主服务器和后备服务器。 这对于服务器鲁棒性并不会提供任何有意义的改进,对 HA 也一样。

26.4.2. 基于记录的日志传送

也可以使用这种替代方法来实现基于记录的日志传送,不过这需要定制开发, 并且只有在一整个 WAL 文件被传送之后改变才会对热后备查询可见。

一个外部程序可以调用pg_walfile_name_offset()函数(见第 9.26 节) 来找出 WAL 的当前末端的文件名和其中准确的字节偏移。 它接着可以直接访问 WAL 文件并且将从上一个已知的 WAL 末尾到当前末尾之间的数据拷贝到后备服务器。 通过这种方法,数据丢失的窗口是复制程序的轮询周期时间,这可以为非常小, 并且不会有强制部分使用的段文件被归档所浪费的带宽。注意后备服务器的 restore_command脚本只能处理整个 WAL 文件, 因此增量复制的数据通常不会对后备服务器可用。只有当主服务器死掉时它才有用 — 那时最后一个部分 WAL 文件会在允许它发生之前被送给后备服务器。 这个处理的正确实现要求restore_command脚本和数据复制程序的合作。

PostgreSQL 版本 9.0 开始,你可以使用流复制 (见第 26.2.5 节)来实现事半功倍的效果。

本文转自PostgreSQL中文社区,原文链接:26.4. 日志传送的替代方法

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
5月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL的服务器日志文件
本文介绍了PostgreSQL数据库的物理存储结构,重点讨论了服务器日志文件。通过`pg_ctl`命令启动PostgreSQL实例时,使用`-l`参数指定日志文件位置,记录数据库启动、运行及关闭过程中的关键信息。附有相关视频讲解和日志文件示例。
206 0
|
2月前
|
关系型数据库 测试技术 Linux
PostgreSQL配置文件修改及启用方法
总的来说,修改和启用PostgreSQL的配置文件是一个直接而简单的过程。只需要找到配置文件,修改你想要改变的选项,然后重启服务器即可。但是,你需要注意的是,不正确的配置可能会导致服务器性能下降,甚至导致服务器无法启动。因此,在修改配置文件之前,你应该充分理解每个选项的含义和影响,如果可能的话,你应该在测试环境中先进行试验。
216 72
|
1月前
|
存储 Windows
【Azure Cloud Service】微软云服务上的日志收集方法
本文介绍了在使用微软云服务(Cloud Service Extended Support)时,如何收集日志以分析未记录在应用日志中的服务异常。由于云服务基于传统虚拟机模式,需通过远程桌面登录实例,查看IIS、Windows Event及云服务组件日志(如WindowsAzureGuestAgent)。此外,可使用CollectGuestLogs.exe工具打包日志,或通过“File Server Resource Manager”检查日志存储配额是否不足。附参考文档链接供深入学习。
96 30
|
1月前
|
存储 监控 API
【Azure App Service】分享使用Python Code获取App Service的服务器日志记录管理配置信息
本文介绍了如何通过Python代码获取App Service中“Web服务器日志记录”的配置状态。借助`azure-mgmt-web` SDK,可通过初始化`WebSiteManagementClient`对象、调用`get_configuration`方法来查看`http_logging_enabled`的值,从而判断日志记录是否启用及存储方式(关闭、存储或文件系统)。示例代码详细展示了实现步骤,并附有执行结果与官方文档参考链接,帮助开发者快速定位和解决问题。
88 23
|
1月前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。
|
9月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
201 3
|
5月前
|
存储 Prometheus 监控
Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行
本文深入探讨了在Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行。
227 5
|
7月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
118 1
|
7月前
|
分布式计算 资源调度 数据可视化
Hadoop-06-Hadoop集群 历史服务器配置 超详细 执行任务记录 JobHistoryServer MapReduce执行记录 日志聚合结果可视化查看
Hadoop-06-Hadoop集群 历史服务器配置 超详细 执行任务记录 JobHistoryServer MapReduce执行记录 日志聚合结果可视化查看
115 1
|
9月前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。