PostgreSQL pg_archivecleanup与清理archivelog的操作

pg_archivecleanup 和 pg_rewind 是PG 中两个重要的功能,一个是为了清理过期的 archive log 使用的命令,另一个是你可以理解为物理级别的 wal log的搬运工。

我们先说第一个 pg_archivecleanup 命令,这个命令主要是用于使用了archive log 功能的 postgresql 但在 archive log 堆积如山的情况下,你怎么来根据某些规则,清理这些日志呢?

这里面就要使用 pg_archivecleanup 这个命令了,可以定时的来运行它,将已经移动到archivecleanup 的目录的archivelog 根据要求开始清理。

当然我们先的说说如果不定期清理会出什么问题

1 如果不定期清理archive 如果存放archivelog 的位置无法在接受新的日志,则大量WAL日志会滞留在 wal_log 目录中,则整体数据库系统都会受到影响。

2 占用大量的存储空间,存储无效的数据

那一般来说如果没有第三方的备份工具的情况下,怎么来通过pg_archivecleanup 来进行archivelog 的清理。

需要关注几个点

1 清理的时,清理的WAL_LOG 是否已经是包含在最后一次的备份中,保证清理的WAL_LOG 也可以从备份文件中恢复数据库

2 清理的时候,对于保存在非主库的wal_log 怎么办

一般来说,设置自动清理archive_log 可以在配置文件中添加

archive_cleanup_command = 'pg_archivecleanup archivelocation %r'

来操作。

但一般来说这样做好处少,弊病多,我比较喜欢写相关的脚本,定时去运行的方式,并且可以记录相关的LOG 日志等等。

可以写一个脚本,来辅助定时清理相关的archive_log

当然这样的方法也是有弊端的,如果由于备份的原因的故障,而直接使用天数来清理会有因为没有备份而直接将 wal_log 给清理掉,所以更加靠谱的方法是通过某些命令来获得需要截止的清理的Wal_log 名称。

例如 备份后的

会在wal_log 里面有backup 的标记,这说明这个WAL log 以前的数据已经备份了,如果清理这个WAL LOG 之前的log 是安全的。

000000010000000300000030.00000060.backup

使用下面的脚本可以来更安全的清理

#!/bin/bash
ARCHIVEDIR='/pgdata/archive'
CHK_SAFE=$(find $ARCHIVEDIR -type f -mtime +3 -name '*backup' -printf '%f\n' | sort -r | head -1)
cd $ARCHIVEDIR
/usr/local/postgres/bin/pg_archivecleanup $ARCHIVEDIR $CHK_SAFE
find $ARCHIVEDIR -type f -mtime +3 -a -name '*backup' -a ! -newer $CHKPOINT -delete

补充:postgresql流日志误删处理(xlog)

今天同事误删postgresql库数据文件下的pg_xlog文件夹,导致所有流日志丢失,数据库无法启动,观察警告日志:

2018-03-12 18:45:54 CST LOG: database system shutdown was interrupted; last known up at 2018-03-12 17:48:27 CST
2018-03-12 18:45:54 CST LOG: could not open file "pg_xlog/000000010000001400000060" (log file 20, segment 96): No such file or directory
2018-03-12 18:45:54 CST LOG: invalid primary checkpoint record
2018-03-12 18:45:54 CST LOG: could not open file "pg_xlog/000000010000001400000060" (log file 20, segment 96): No such file or directory
2018-03-12 18:45:54 CST LOG: invalid secondary checkpoint record
2018-03-12 18:45:54 CST PANIC: could not locate a valid checkpoint record
2018-03-12 18:45:54 CST LOG: startup process (PID 32680) was terminated by signal 6: Aborted
2018-03-12 18:45:54 CST LOG: aborting startup due to startup process failure

用postgresql自带的pg_resetxlog工具可以跳过对WAL log的恢复。不过会丢失一些事务。恢复命令也很简单如下:

pg_resetxlog -f /var/lib/pgsql/9.6/data

然后启动postgrsql ,数据库就可正常进入

参考:pg_resetxlog官方文档

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。如有错误或未考虑完全的地方,望不吝赐教。

时间: 2021-01-11

Postgresql中LIKE和ILIKE操作符的用法详解

LIKE和ILIKE操作符可以模糊匹配字符串,LIKE是一般用法,ILIKE匹配时则不区分字符串的大小写. 它们需要结合通配符使用,下面介绍两种常用的通配符. %:百分号用于匹配字符串序列,可匹配任意组合: _:下划线用于匹配任何单一字符. 举例来说明LIKE和ILIKE操作符的区别. 先创建一张数据表table1,包含两列:id列和name列,代码如下: create table table1(id int, name varchar); insert into table1 values(1

postgresql连续归档及时间点恢复的操作

简介 前面我们介绍了通过pgsql的流复制在生产环境中搭建高可用环境来保证服务的可持续性:我们也要对数据库进行周期备份,来防止数据的丢失,这就需要连续归档,它不仅可以用于大型数据库的增量备份和恢复,也可以用于搭建standby镜像备份.    PostgreSQL默认处于非归档模式.开启归档模式,主要涉及到三个参数:wal_level,archive_mode和archive_commandwal_level参数默认为mininal,设置此参数为archive或者之上的级别都可以打开归档.当po

PostgreSQL 实现distinct关键字给单独的几列去重

PostgreSQL去重问题一直困扰着我,distinct和group by远不如MySQL用起来随便,但是如果掌握了规律,还是和MySQL差不多的 主要介绍的是distinct关键字 select distinct id,name,sex,age from student 假如有一张student表,字段如上图,我查询student表中所有信息用distinct去重(上面的SQL语句),pgsql就会根据所有的字段通过算法取得重复行的第一行,但是很明显,ID这个字段我在设计的时候不会让它重复,

浅谈PostgreSQL中大小写不敏感问题

本文主要讨论PostgreSQL中大小写不敏感存在的问题. 默认情况下,PostgreSQL会将列名和表名全部转换为小写状态. 图1 Person与person 如图1所示,我们创建表person,其中包含name列.然后插入一条记录.执行SELECT查询时,使用列名Name和表名Person而不是name和person,发现仍然可以正常获取刚刚插入表person中的记录. 图2 创建表Person? 此时如果我们再想创建表Person,会得到一个错误,因为此时PostgreSQL实际上把表名从

postgresql 实现启动、状态查看、关闭

利用psql启动数据库 [postgres@highgo ~]$ pg_ctl start 查看系统中运行的postgres进程 #ps -ef | grep postgres 连接postgresql数据库 #psql -h 127.0.0.1 -d postgres -U postgres 停止postgresql数据库实例 #pg_ctl stop #ps -ef | grep postgres 启动服务器最简单的方法是像下面这样: $ postgres -D /usr/local/pgs

PostgreSQL LIKE 大小写实例

PostgreSQL 数据库 函数upper("字符串"):转成大写字符串 WHERE UPPER("User_Name") LIKE upper(username) 此句查询"User_Name" 中值大小写不区分. SELECT "User_Id","User_Image","User_Name","User_Birthday","User_Sex&qu

PostgreSQL归档配置及自动清理归档日志的操作

在一般的生产环境中,数据库都需要开启归档模式,那么在pg中如何开启归档模式呢? pg中的归档配置涉及几个参数如下: # - Archiving - 是否开启归档 #archive_mode = off # enables archiving; off, on, or always # (change requires restart) 归档命令,注意 %p %f %% 格式化的含义. %p 是被归档的redo文件的路径, %f 是被归档的redo文档的文件名 %% 是百分号 #archive_c

PostgreSQL 实现列转行问题

1 测试表数据 SELECT relative_label_content FROM frk_s.label_cor_gene relative_label_content ------ AA BB CC 2 列转行写法 写法1: string_agg SELECT frwybs, string_agg (relative_label_content, ',') as relative_label_content FROM frk_s.label_cor_gene GROUP BY frwybs

解决PostgreSQL日志信息占用磁盘过大的问题

当PostgreSQL启用日志时,若postgresql.conf日志的相关参数还使用默认值的话磁盘很容易被撑爆.因此在启用了logging_collector参数时,需要对其它相关的参数进行调整. 系统默认参数如下 #log_destination = 'stderr' #日志格式,值为stderr, csvlog, syslog, and eventlog之一. logging_collector = on #启用日志 #log_directory = 'log' #日志文件存储目录 #lo

Postgresql 如何清理WAL日志

WAL是Write Ahead Log的简写,和oracle的redo日志类似,存放在$PGDATA/pg_xlog中,10版本以后在$PGDATA/pg_wal目录. 如果开启了归档,在目录archive_status下会有一些文件,以ready结尾的,表示可以归档但还没有归档,done结尾的表示已经归档. 和WAL日志数量相关的几个参数: wal_keep_segments = 300 # in logfile segments, 16MB each; 0 disables checkpoi

推荐的一篇用多种脚本清理iis日志的代码第1/3页

应用场合:主要用与虚拟主机,也可用于个人服务器 产生背景:2005年某月某日,一向运行正常的虚拟主机死机了,让机房值班人员重启数次,都不成,接显示器进系统看,提示:C盘空间不足,半夜还得去机房处理,到机房后先断网,再进系统发现有两个地方有问题,C:\WINDOWS\system32\LogFiles文件有6G,还有一个就是Symantec隔离病毒的地方,到网上找了下,最大可能性是我们的虚拟主机的所有日志都写在这里,并且没人知道写在这里,郁闷,在IIS里看了下,还真是这么回事,日志天天都在长,当时

MySQL 自动清理binlog日志的方法

说明: 开启MySQL binlog日志的服务器,如果不设置自动清理日志,默认binlog日志一直保留着,时间一长,服务器磁盘空间被binlog日志占满,导致MySQL数据库出错. 使用下面方法可以安全清理binlog日志 一.没有主从同步的情况下清理日志 mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)'; #mysql 定时清理5天前的binlog mysql -u root

MS SQL Server数据库清理错误日志的方法

SQL错误日志记录了数据库运行过程的遇到的各种问题及一些重要信息,作为排错需要,我们通常都不会主动去清理这些日志文件,只有每次重启服务器时,SQL会自动删除时间最老的日志文件,并新生成一个日志文件.通过在服务器上查看数据库的日志文件,发现存在大量的query notification dialog的信息,而且出现的频率非常的高,导致日志文件增大非常快.通过google了解到这个错误跟service broker的消息机制由关系,可以通过使用跟踪标记:DBCC TraceOn(4133,-1)可消

mysql 正确清理binlog日志的两种方法

mysq 正确清理binlog日志 前言: MySQL中的binlog日志记录了数据库中数据的变动,便于对数据的基于时间点和基于位置的恢复,但是binlog也会日渐增大,占用很大的磁盘空间,因此,要对binlog使用正确安全的方法清理掉一部分没用的日志. [方法一]手动清理binlog 清理前的准备: ① 查看主库和从库正在使用的binlog是哪个文件 show master status\G show slave status\G ② 在删除binlog日志之前,首先对binlog日志备份,以

Mysql数据库清理binlog日志命令详解

概述 今天主要分享下mysql数据库应该如何正确的删除binlog日志,这里要注意不要强制使用rm命令进行清除.否则mysq-bin.index错乱,最终导致后期expire-log-days配置项失效. 1.查看binlog日志 mysql> show binary logs; 2.删除某个日志文件之前的所有日志文件 purge binary logs to 'mysql-bin.000035'; 3.清理2019-09-09 13:00:00前binlog日志 PURGE MASTER LO

浅谈Linux下通过find命令进行rm文件删除的小技巧

我们经常会通过find命令进行批量操作,如:批量删除旧文件.批量修改.基于时间的文件统计.基于文件大小的文件统计等,在这些操作当中,由于rm删除操作会导致目录结构变化,如果要通过find结合rm的操作写成脚本,就会遇到一些麻烦,本文通过一个例子为大家进行介绍. 系统环境: SUSE Linux Enterprise Server 11 或 Red Hat Enterprise Linux 问题症状: 客户现场有一个自动化的脚本,有以下的find语句,每天运行以删除某个目录下7天以前的文件或目录,

Oracle 11g如何清理数据库的历史日志详解

本文主要给大家介绍了关于Oracle 11g清理数据库历史日志的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍 1. 创建存放数据库待删除日志文件路径 用于存放准备删除,这里假设放在/home/Oracle/delete路径下 $ cd /home/oracle/delete $ mkdir -p audit_file_dest background_dump_dest user_dump_dest core_dump_dest listenr_log_dest 2. 查

IIS日志清理(CMD版,VBS版,JS版,WSH版)

应用场合:主要用与虚拟主机,也可用于个人服务器 产生背景:2005 年某月某日,一向运行正常的虚拟主机死机了,让机房值班人员重启数次,都不成,接显示器进系统看,提示:C盘空间不足,半夜还得去机房处理,到机房后先断网,再进系统发现有两个地方有问题,C:\WINDOWS\system32\LogFiles文件有6G,还有一个就是Symantec隔离病毒的地方,到网上找了下,最大可能性是我们的虚拟主机的所有日志都写在这里,并且没人知道写在这里,郁闷,在IIS里看了下,还真是这么回事,日志天天都在长,当

PostgreSQL数据库事务出现未知状态的处理方法

背景 数据库的事务是原子操作,要么成功,要么失败.但是实际上在客户端的视角,可能有第三种状态:unknown状态. 当客户端提交事务结束(rollback , commit , prepare xact , rollback pxact , commit pxact)的请求后,数据库收到请求,数据库可能执行失败,也可能执行成功,不管怎样都要写对于的WAL日志,还有CLOG,然后数据库要将执行结果返回给客户端ACK. 这里存在几种可能,导致客户端不知道执行到底怎么样了? 收到客户端请求后,数据库没

PostgreSQL教程(八):索引详解

一.索引的类型: PostgreSQL提供了多 种索引类型:B-Tree.Hash.GiST和GIN,由于它们使用了不同的算法,因此每种索引类型都有其适合的查询类型,缺省时,CREATE INDEX命令将创建B-Tree索引.         1. B-Tree:   复制代码 代码如下: CREATE TABLE test1 (         id integer,         content varchar     );     CREATE INDEX test1_id_index