数据库内核月报 - 2015 / 10-PgSQL · 特性分析 · pg_receivexlog工具解析

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介:

最近遇到这样一个需求:在做时间点恢复时,需要从主库获取最近生成的那些xlog文件(需要获取的xlog文件名是已知的)。怎么办?一个想法是,利用scp等工具,直接从主库下载,这要求我们处理整个下载过程,比较麻烦。其实PG已经为我们准备了一个xlog传输工具——pg_receivexlog。这个工具可能很多人都没注意到,而且官方文档中介绍的很少。在这里我们为大家解析一下这个工具。

能做什么

pg_receivexlog能为我们做什么呢?它能够从一个PG服务器,获取你想要的那些xlog日志文件。初步研究后,我们可以得到以下信息:

  1. 它以类似流式复制(streaming replication)的方式,获取主库的xlog文件。这意味着你要以超级用户或有replication权限的用户,连接PG进行日志传输,且要在pg_hba.conf里面,对其做权限配置。在连接建立后,PG服务器会有一个独立的WAL sender进程,负责xlog的传输,所以max_wal_senders要至少为1,使我们能获得一个WAL sender。
  2. 它不会等待一个xlog文件写完后才开始传输。也就是说,正在被写的xlog文件,也会进行传输,因此可以通过这个工具实时获取最新的xlog内容。
  3. 可以使用replication slot,通过同步replication slot的方式进行日志传输。这样做的好处是,主库在xlog传输完成前不会删除xlog文件。不过可能的风险是,如果日志没有利用slot成功传输,可能导致日志堆积在PG里面,最终把磁盘占满。

如何启动

PG安装后的bin目录里面,一般包含了pg_receivexlog这个工具。可以使用下面的方式启动它:

pg_receivexlog -h <host name> -p <port> -U <user> -W <password> -D <local dir to store xlog files>

其中,-h -p -U -W 选项指定要连接的PG的主机名、端口、用户、密码,-D 选项指定本地的一个目录,用于存储下载的xlog文件。另外缺省情况下,如果连接无法建立,或传输过程中连接意外断开,pg_receivexlog会进行重试,如果不想重试,可以指定-n选项。

有个问题是,如何指定要传输哪些xlog文件?先来看看pg_receivexlog如何确定从哪个xlog文件开始传输的。从src/bin/pg_basebackup/pg_receivexlog.c 的FindStreamingStart函数可以看出,pg_receivexlog会扫描整个-D选项指定的目录,将扫描到的每个文件名,去掉其timeline部分,转换为64为整数。选取其中对应整数最大的文件,按如下方式选择开始下载的文件:如果这个文件是以.partial为后缀的,则重新下载此文件和后续文件;如果该文件不带.partial后缀,是一个完整的日志文件,则从此文件的下一个文件(文件名加1)开始下载。如果我们需要从00000001000000000000001B到00000001000000000000001D的几个文件,则只需要在-D指定的目录里面执行:

touch 00000001000000000000001B.partial

保证此目录没有其他文件,然后按上面列出的方式启动pg_receivexlog即可,pg_receivexlog会重新下载00000001000000000000001B和后续文件。

如何停止

如何停止pg_receivexlog的执行呢?pg_receivexlog已经下载了我们需要的文件后,并不会自动停止,我们也没有办法指定它下载到哪个文件结束。唯一的办法是通过Ctl-C命令向它发送SIGINT信号来结束它。类似的,可以直接向它的进程发生kill命令:

kill -SIGINT <pg_receivexlog pid>

注意,pg_receivexlog只在成功传输完一个xlog文件后,才检查是否收到了SIGINT信号,因此你只可能在一个文件接收完成后正常结束pg_receivexlog运行。其实更暴力的办法是直接kill -9 也是可以的。

从上面的分析可以看出,pg_receivexlog这个工具还是比较简单易用的。除了传输xlog日志,可以利用它做一个日志服务器,用来存储归档的日志;还可以做为一主多备方案。由此可见,pg_receivexlog既是一个很实用的工具,也是一个可以用于更多场景的让人充满想象的利器。

目录
相关文章
|
7月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
483 158
|
7月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
493 156
|
7月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
593 161
|
SQL 数据挖掘 测试技术
南大通用GBase8s数据库:LISTAGG函数的解析
南大通用GBase8s数据库:LISTAGG函数的解析
|
存储 数据挖掘 数据处理
2600 万表流计算分析如何做到? 时序数据库 TDengine 助力数百家超市智能化转型
在生鲜超市的高效运营中,实时数据分析至关重要。万象云鼎的“云鲜生”通过智能秤+网关+软件系统的组合,实现了销售数据的精准管理与优化。而在数据处理方面,TDengine 的流计算能力成为了这一方案的核心支撑。本文详细分享了“云鲜生”如何利用 TDengine 高效存储和分析海量销售数据,在优化超市运营、提升用户体验的同时,解决高基数分组、高并发查询等技术挑战。
336 1
|
存储 监控 数据挖掘
消防行业如何借助时序数据库 TDengine 打造高效的数据监控与分析系统
本篇文章来自“2024,我想和 TDengine 谈谈”征文活动的优秀投稿,深入探讨了如何在消防行业中运用 TDengine 进行业务建模。文章重点介绍了如何通过 TDengine 的超级表、标签设计和高效查询功能,有效管理消防监控系统中的时序数据。作者详细阐述了实时监控、报警系统以及历史数据分析在消防行业中的应用,展示了 TDengine 在数据压缩、保留策略和分布式架构下的强大优势。
365 0
|
关系型数据库 分布式数据库 数据库
瑶池数据库大讲堂|PolarDB HTAP:为在线业务插上实时分析的翅膀
瑶池数据库大讲堂介绍PolarDB HTAP,为在线业务提供实时分析能力。内容涵盖MySQL在线业务的分析需求与现有解决方案、PolarDB HTAP架构优化、针对分析型负载的优化(如向量化执行、多核并行处理)及近期性能改进和用户体验提升。通过这些优化,PolarDB HTAP实现了高效的数据处理和查询加速,帮助用户更好地应对复杂业务场景。
428 4
|
缓存 并行计算 Linux
深入解析Linux操作系统的内核优化策略
本文旨在探讨Linux操作系统内核的优化策略,包括内核参数调整、内存管理、CPU调度以及文件系统性能提升等方面。通过对这些关键领域的分析,我们可以理解如何有效地提高Linux系统的性能和稳定性,从而为用户提供更加流畅和高效的计算体验。
625 24
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。

推荐镜像

更多
  • DNS