pg_resetxlog - 重置一个 PostgreSQL 数据库集群的预写日志以及其它控制内容

SYNOPSIS

pg_resetxlog [ -f ] [ -n ] [ -o oid] [ -x xid] [ -l fileid,seg] datadir

DESCRIPTION 描述

pg_resetxlog 清理预写日志(WAL)并且可以选择地重置其它一些控制信息(存储在 pg_control 文件中)。 有时候,如果这些文件崩溃了,我们需要这个功能。 我们一定只把它用作最后的方法,就是说只有因为这样的崩溃导致服务器无法启动的时候才使用。

在运行这个命令之后,我们可能可以启动服务器了,但是,一定要记住数据库可能因为部分提交的事务而含有不完整的数据。 你应该马上转储你的数据,运行 initdb,然后重新装载。 在重新装载之后,检查不完整的部分然后根据需要进行修复。

这个命令只能由安装服务器的用户运行,因为它需要对数据目录的读写权限。 出于安全考虑,你必须在命令行上声明数据目录。 pg_resetxlog 不使用环境变量 PGDATA

如果 pg_resetxlog 抱怨说它无法判断用于 pg_control 的有效数据,那么你可以强制它继续处理, 方法是声明 -f
(强制)开关。在这种情况下,那些丢失了的数据的值将用模糊的近似数值代替。 大多数字段都可以匹配上,但是下一个 OID,下一个事务 ID,WAL
开始地址以及数据库区域字段可能需要手工帮助, 前面三个可以用下面讨论的开关设置。pg_resetxlog 自己的环境是猜测区域字段的来源;看看 LANG
等等东西,它们应该和 initdb 运行的环境相匹配。 如果你不能判断所有这些字段的正确数值,那么还是可以使用 -f,
但是这样恢复过来的数据库更要怀疑有问题:立即转储和重置是必须的。 在转储之前不要执行任何修改数据的操作,因为任何这样的动作都可能把事情搞得更糟糕。

-o, -x, 和 -l 开关允许我们手工设置下一个 OID,下一个事务 ID,以及 WAL 起始位置的数值。 只有在 pg_resetxlog 无法通过读取 pg_control 判断合适的数值的时候才需要它。对于下一个事务 ID 而言,一个安全的数值是看看数据目录里的 /pg_clog 里数值最大的文件名, 然后加一,然后再乘上 1048576。请注意那些文件名是十六进制的。通常我们也以十六进制的形式声明开关值是最简单得。 比如,如果 0011 是 pg_clog 里 最大的记录,-x 0x1200000 就可以了(后面的五个零提供了合适的乘积)。 WAL 的起始位置应该比目前存在于数据目录里得 /pg_xlog 里面的任何文件号都大。它也是十六进制的,并且有两部分。比如,如果 000000FF0000003A 是 pg_xlog 里最大的条目, 那么-l 0xFF,0x3B 就可以了。我们没有很容易的办法来判断比数据库中最大的 OID 大一号的下一个 OID, 不过很走运的是获取正确的下一个 OID 并非非常关键。

开关 -n (无操作)指示 pg_resetxlog 打印从 pg_control 重新构造的数值然后不修改任何值就退出。 这主要是一个调试工具,但是在 pg_resetxlog 真正处理前进行的整洁性检查的时候可能会有用。

NOTES 注意

在 postmaster 服务器运行的时候一定不要运行这个命令。 如果发现在数据文件目录里有锁文件,那么 pg_resetxlog 将拒绝启动。如果 postmaster 崩溃,那么可能会剩下一个锁文件; 如果这样,你可以删除该锁文件以便允许 pg_resetxlog 运行。但是在你这么做之前,一定要确信没有任何postmaster或者后端服务器仍在运行。

原文地址:https://www.cnblogs.com/fanweisheng/p/11097497.html

时间: 2024-10-19 11:34:11

pg_resetxlog - 重置一个 PostgreSQL 数据库集群的预写日志以及其它控制内容的相关文章

pg_dumpall - 抽出一个 PostgreSQL 数据库集群到脚本文件中

SYNOPSIS pg_dumpall [ option...] DESCRIPTION 描述 pg_dumpall 是一个用于写出("转储")一个数据库集群里的所有 PostgreSQL 数据库到一个脚本文件的工具. 该脚本文件包含可以用于作为 psql(1) 的输入恢复数据库的SQL命令. 它通过对数据库集群里的每个数据库调用 pg_dump(1) 实现这个功能. pg_dumpall 还转储出所有数据库公用的全局对象. (pg_dump(1) 并不保存这些对象.) 这些信息目前包

分布式数据库集群中间件

我是一个分布式数据库集群中间件的开发人员,已经一年多一点的开发时间了,今天总结点我所知道的一些事情,给有新近来到这个领域的研发人员一点借鉴. 生活不易,赚钱不易,离开仅仅是为多赚点钱. ----学渣 我仅仅是说我所开发过的系统: 后面文章会有具体的分析.这里仅仅做简单的梳理.也就是你要研发分布式数据库集群中间件.须要向着哪些方面去思考. 首先我们从名字去分析我们正在从事的工作内容: 1. 分布式 须要考虑它的方向(后面具体说明) a)  分布式中的概念 b)  分布式的模型 c)  分布式系统特

?Postgres-XL:基于PostgreSQL的开源可扩展数据库集群

?Postgres-XL:基于PostgreSQL的开源可扩展数据库集群 最近这一年业界去"IOE"越叫越响,很多传统企业也把去"IOE"计划摆上了桌面.我老是想不明白这些非互联网企业(比如:银行)做这种事的动力何在? 高大上的"自主可控"."振兴民族科技"等空洞口号先不去管,真正的动力在哪里? "安全"."成本"."互联网架构".......等等.等等, 唯一看起来

PostgreSQL复制集群概总

转自http://blog.csdn.net/beiigang/article/details/39099575 pg的复制.高可用.负载均衡相关集群,这儿写个概要备查. pg有以下各种基于复制的集群方案,多数配过,有的当时没有整理.现在网上也有很多这些集群配置的文档,在这篇文档后找完备点的集中一下备档,不用每次用时到处查. 基于流复制的功能内置.触发器主从复制slony,基于sql复制的pgpool-II,其它如同步多主复制EDB MMR(这个也支持异步复制,玩过的时间有点长了,后面要找到当年

postgresql分布式集群之citus

今天,利用大家的休息时间分享postgresql分布式集群,利用Citus实现分库分表. 一.Citus是什么 citus是PG的一个sharding插件,可以把PG变成一个分布式数据库.目前在苏宁有大量的生产应用跑在citus+pg的环境中.大家可以看it大咖视频. citus是一款基于PostgreSQL的开源分布式数据库,自动继承了PostgreSQL强大的SQL支持能力和应用生态(不仅仅是客户端协议的兼容还包括服务端扩展和管理工具的完全兼容). 和其他类似的基于PostgreSQL的分布

分布式数据库集群节点数据一致性校验

某500强客户要上线一个功能,其后台所有数据库是我司设计开发的NoSQL数据库. 为了避免数据库集群中,数据节点不一致而导致问题,需要对数据库节点间的数据进行校验. 理论上说,数据库节点之间的数据,应当保持最终一致性.而我司的数据库,是在对主节点对数据进行操作时,coord节点会(立即)通知备节点拉取数据,从而保持数据的一致性.所以,对于正常运行的数据库来说,一个集群内每个节点上的数据,是完全一致的. 客户是上帝,我们所作的就是要让客户放心.虽然我们强调我们的数据库集群内的节点中数据是一致的,让

PhxSQL兼容MySQL的关系型数据库集群

PhxSQL是一个兼容MySQL.服务高可用.数据强一致的关系型数据库集群.PhxSQL以单Master多Slave方式部署,在集群内超过一半机器存活的情况下,可自身实现自动Master切换,且保证数据一致性. PhxSQL 架构: PhxSQL基于Percona 5.6开发.Percona是MySQL的一个分支,功能和实现与MySQL基本一致(基础教程qkxue.net).因此本文后续直接把MySQL作为讨论对象. 总览: PhxSQL具有服务高可用.数据强一致.高性能.运维简单.和MySQL

CentOS6.5安装DRBD+MariaDB+Heartbeat实现数据库集群高可用

本实验使用两台服务器搭建: 系统                  CentOS6.5 tese02              IP:192.168.1.244 test03               IP:192.168.1.245 DRBD               版本:8.4.6 DRBD-UTIL       版本:8.9.2 MariaDB           版本:10.0.17 Heartbeat         版本:3.0.4 VIP                  

数据库集群技术漫谈

转自:http://www.51testing.com/html/69/n-867469-2.html 简介 当今世界是一个信息化的世界,我们的生活中无论是生活.工作.学习都离不开信息系统的支撑.而信息系统的背后用于保存和处理最终结果的地方就是数据库.因此数据库系统就变得尤为重要,这意味着如果数据库如果面临问题,则意味着整个应用系统也会面临挑战,从而带来严重的损失和后果. 如今“大数据”这个词已经变得非常流行,虽然这个概念如何落地不得而知.但可以确定的是,随着物联网.移动应用的兴起,数据量相比过