Postgresql备份和增量恢复方案

前言

最近工作上使用的数据库一直是Postgresql,这是一款开源的数据库,而且任何个人可以将该数据库用于商业用途。在使用Postgresql的时候,让我最明显的感觉就是这数据库做的真心好,虽然说数据库的安装包真的很小,但是性能和操作的便捷是一点也不输给其他商业的大型数据库,另外在命令行界面下对该数据库直接进行操作的感觉真的是很爽。在使用数据库的时候,我们作为小公司的数据库管理员有一项工作是不可能避免的,那就是数据的备份和恢复问题。PostgreSQL虽然各个方面的有点很多,但是在数据库备份这方面,它是不支持增量备份的,这点确实让人觉得很是可惜啊。不过,瑕不掩瑜,总的来说这是一款很好的数据库软件。

之前,我们在 《Postgresql主从异步流复制方案》 一节中,部署了Postgresql的主从异步流复制环境。主从复制的目的是为了实现数据的备份,实现数据的高可用性和容错行。下面主要简单地介绍下我们运维Postgresql数据库时的场景备份与恢复方案。

增量备份

PostgreSQL在做写入操作时,对数据文件做的任何修改信息,首先会写入WAL日志(预写日志),然后才会对数据文件做物理修改。当数据库服务器掉重启时,PostgreSQL在启动时会首先读取WAL日志,对数据文件进行恢复。因此,从理论上讲,如果我们有一个数据库的基础备份(也称为全备),再配合WAL日志,是可以将数据库恢复到任意时间点的。

上面的知识点很重要,因为我们场景的增量备份说白了就是通过基础备份 + 增量WAL日志 进行重做恢复的。

增量备份设置

为了演示相关功能,我们基于 《Postgresql主从异步流复制方案》 一节中的环境pghost1服务器上,创 建相关管理目录

切换到 postgres 用户下

mkdir -p /data/pg10/backups
mkdir -p /data/pg10/archive_wals

backups目录则可以用来存放基础备份

archive_wals目录自然用来存放归档了

接下来我们修改我们的postgresql.conf文件的相关设置

wal_level = replica

archive_mode = on

archive_command = '/usr/bin/lz4 -q -z %p /data/pg10/archive_wals/%f.lz4'

archive_command 参数的默认值是个空字符串,它的值可以是一条shell命令或者一个复杂的shell脚本。

在archive_command的shell命令或脚本中可以用 %p 表示将要归档的WAL文件的包含完整路径信息的文件名,用 %f 代表不包含路径信息的WAL文件的文件名。

修改wal_level和archive_mode参数都需要重新启动数据库才可以生效,修改archive_command不需要重启,只需要reload即可,例如:

postgres=# SELECT pg_reload_conf();

postgres=# show archive_command ; 

创建基础备份

我们使用之前介绍过的pg_basebackup命令进行基础备份的创建, 基础备份很重要,我们的数据恢复不能没有它,建议我们根据相关业务策略,周期性生成我们的基础备份。

$ pg_basebackup -Ft -Pv -Xf -z -Z5 -p 25432 -D /data/pg10/backups/

这样,我们就成功生成我们的基础数据备份了

设置还原点

一般我们需要根据重要事件发生时创建一个还原点,通过基础备份和归档恢复到事件发生之前的状态。

创建还原点的系统函数为:pg_create_restore_point,它的定义如下:

postgres=# SELECT pg_create_restore_point('domac-201810141800');

恢复到指定还原点

接下来,我们通过一个示例,让我们的数据还原到我们设置的还原点上

首先,我们创建一张测试表:

CREATE TABLE test_restore(
 id SERIAL PRIMARY KEY,
 ival INT NOT NULL DEFAULT 0,
 description TEXT,
 created_time TIMESTAMPTZ NOT NULL DEFAULT now()
);

初始化一些测试数据作为基础数据,如下所示:

postgres=# INSERT INTO test_restore (ival) VALUES (1);
INSERT 0 1
postgres=# INSERT INTO test_restore (ival) VALUES (2);
INSERT 0 1
postgres=# INSERT INTO test_restore (ival) VALUES (3);
INSERT 0 1
postgres=# INSERT INTO test_restore (ival) VALUES (4);
INSERT 0 1

postgres=# select * from test_restore;
 id | ival | description |   created_time
----+------+-------------+-------------------------------
 1 | 1 |    | 2018-10-14 11:13:41.57154+00
 2 | 2 |    | 2018-10-14 11:13:44.250221+00
 3 | 3 |    | 2018-10-14 11:13:46.311291+00
 4 | 4 |    | 2018-10-14 11:13:48.820479+00
(4 rows)

并且按照上文的方法创建一个基础备份。如果是测试,有一点需要注意,由于WAL文件是写满16MB才会进行归档,测试阶段可能写入会非常少,可以在执行完 基础备份之后,手动进行一次WAL切换。例如:

postgres=# select pg_switch_wal();
 pg_switch_wal
---------------
 0/1D01B858
(1 row)

或者通过设置archive_timeout参数,在达到timeout阈值时强行切换到新的WAL段。

接下来,创建一个还原点,如下所示:

postgres=# select pg_create_restore_point('domac-1014');
 pg_create_restore_point
-------------------------
 0/1E0001A8
(1 row)

接下来我们对数据做一些变更, 我们删除test_restore的所有数据:

postgres=# delete from test_restore;
DELETE 4

下面进行恢复到名称为“domac-1014”还原点的实验,如下所示:

停止数据库

$ pg_ctl stop -D /data/pg10/db

移除旧的数据目录

$ rm -rf /data/pg10/db

$ mkdir db && chmod 0700 db

$ tar -xvf /data/pg10/backups/base.tar.gz -C /data/pg10/db

cp $PGHOME/share/recovery.conf.sample /pgdata/10/data/recovery.conf

chmod 0600 /pgdata/10/data/recovery.conf

修改 recovery.conf, 修改以下配置信息:

restore_command = '/usr/bin/lz4 -d /data/pg10/archive_wals/%f.lz4 %p'
recovery_target_name = 'domac-1014

然后启动数据库进入恢复状态,观察日志,如下所示:

bash-4.2$ pg_ctl start -D /data/pg10/db
waiting for server to start....2018-10-14 11:26:56.949 UTC [8397] LOG: listening on IPv4 address "0.0.0.0", port 25432
2018-10-14 11:26:56.949 UTC [8397] LOG: listening on IPv6 address "::", port 25432
2018-10-14 11:26:56.952 UTC [8397] LOG: listening on Unix socket "/tmp/.s.PGSQL.25432"
2018-10-14 11:26:56.968 UTC [8398] LOG: database system was interrupted; last known up at 2018-10-14 09:26:59 UTC
2018-10-14 11:26:57.049 UTC [8398] LOG: starting point-in-time recovery to "domac-1014"
/data/pg10/archive_wals/00000002.history.lz4: No such file or directory
2018-10-14 11:26:57.052 UTC [8398] LOG: restored log file "00000002.history" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.077 UTC [8398] LOG: restored log file "000000020000000000000016" from archive
2018-10-14 11:26:57.191 UTC [8398] LOG: redo starts at 0/16000060
2018-10-14 11:26:57.193 UTC [8398] LOG: consistent recovery state reached at 0/16000130
2018-10-14 11:26:57.193 UTC [8397] LOG: database system is ready to accept read only connections
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.217 UTC [8398] LOG: restored log file "000000020000000000000017" from archive
 done
server started
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.384 UTC [8398] LOG: restored log file "000000020000000000000018" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.513 UTC [8398] LOG: restored log file "000000020000000000000019" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.699 UTC [8398] LOG: restored log file "00000002000000000000001A" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.805 UTC [8398] LOG: restored log file "00000002000000000000001B" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:57.982 UTC [8398] LOG: restored log file "00000002000000000000001C" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:58.116 UTC [8398] LOG: restored log file "00000002000000000000001D" from archive
/data/pg10/archive_w : decoded 16777216 bytes
2018-10-14 11:26:58.310 UTC [8398] LOG: restored log file "00000002000000000000001E" from archive
2018-10-14 11:26:58.379 UTC [8398] LOG: recovery stopping at restore point "domac-1014", time 2018-10-14 11:17:20.680941+00
2018-10-14 11:26:58.379 UTC [8398] LOG: recovery has paused
2018-10-14 11:26:58.379 UTC [8398] HINT: Execute pg_wal_replay_resume() to continue.

重启后,我们对test_restore表进行查询,看数据是否正常恢复:

postgres=# select * from test_restore;
 id | ival | description |   created_time
----+------+-------------+-------------------------------
 1 | 1 |    | 2018-10-14 11:13:41.57154+00
 2 | 2 |    | 2018-10-14 11:13:44.250221+00
 3 | 3 |    | 2018-10-14 11:13:46.311291+00
 4 | 4 |    | 2018-10-14 11:13:48.820479+00
(4 rows)

可以看到数据已经恢复到指定的还原点:domac-1014。

这时,recovery.conf可以移除,避免下次数据重启,数据再次恢复到该还原点

总结

备份和恢复是数据库管理中非常重要的工作,日常运维中,我们需要根据需要进行相关策略的备份,并且周期性地进行恢复测试,保证数据的安全。

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • PostgreSQL实战之启动恢复读取checkpoint记录失败的条件详解

    1.首先读取ControlFile->checkPoint指向的checkpoint 2.如果读取失败,slave直接abort退出,master再次读取ControlFile->prevCheckPoint指向的checkpoint StartupXLOG-> |--checkPointLoc = ControlFile->checkPoint; |--record = ReadCheckpointRecord(xlogreader, checkPointLoc, 1, true

  • PostgreSQL新手入门教程

    自从MySQL被Oracle收购以后,PostgreSQL逐渐成为开源关系型数据库的首选. 本文介绍PostgreSQL的安装和基本用法,供初次使用者上手.以下内容基于Debian操作系统,其他操作系统实在没有精力兼顾,但是大部分内容应该普遍适用. 安装 1.首先,安装PostgreSQL客户端. sudo apt-get install postgresql-client 然后,安装PostgreSQL服务器. sudo apt-get install postgresql 2.正常情况下,安

  • Postgresql主从异步流复制方案的深入探究

    前言 数据库的备份工作在日常生产中极为重要,如果你咨询一个DBA如何才能设计出高可用的数据备份与恢复方案,相信很多人都会从架构上给出很多容灾的意见.但归根到底,如果业务环节中数据库还牵涉到分布式环境,我认为一个好的方案需要达到三大要求: 多副本 持久化 一致性 日常架构设计中,我们不仅要保证数据额的成功备份,还要保证备份的数据可以快速恢复.在众多备份恢复可靠性方案中 主从复制 技术,可以说是最常见的实现,本文主要是介绍postgresql主备数据库的异步流复制的环境搭建与主备切换的操作实践,除了

  • PostgreSQL 数据库性能提升的几个方面

    1.使用EXPLAIN EXPLAIN命令可以查看执行计划,在前面的blog中已经介绍过.这个方法是我们最主要的调试工具. 2.及时更新执行计划中使用的统计信息 由于统计 信息不是每次操作数据 库 都 进 行更新的,一般是在 VACUUM . ANALYZE . CREATE INDEX等DDL执行的时候会更新统计信息, 因此执 行 计 划所用的 统计 信息很有可能比 较 旧. 这样执 行 计 划的分析 结 果可能 误 差会 变 大. 以下是表tenk1的相关的一部分统计信息. SELECT r

  • Windows下Postgresql数据库的下载与配置方法

    注意下载的是二进制版,不是带Windows Installer的. http://www.enterprisedb.com/products-services-training/pgbindownload x86下载http://get.enterprisedb.com/postgresql/postgresql-9.2.4-1-windows-binaries.zip x64下载http://get.enterprisedb.com/postgresql/postgresql-9.2.4-1-

  • PostgreSQL 安装和简单使用第1/2页

    据我了解国内四大国产数据库,其中三个都是基于PostgreSQL开发的.并且,因为许可证的灵活,任何人都可以以任何目的免费使用,修改,和分发 PostgreSQL,不管是私用,商用,还是学术研究使用.本文只是简单介绍一下postgresql的安装和简单的使用,语法方面涉及的比较少,以方便新手上路为目的. 1.系统环境和安装方法 : PostgreSQL的安装方法比较灵活,可以用源码包安装,也可以用您使用的发行版所带的软件包来安装,还可以采用在线安装-- 1.1 系统环境:Ubuntu Linux

  • 在Windows下自动备份PostgreSQL的教程

    背景 在我工作上一个使用PostgreSQL数据库的项目上需要一个自动化系统来每天执行备份.经过一番研究决定通过创建一个Windows批处理文件并添加到Windows计划任务中来实现. 下面是具体步骤: 怎样配置 第一步: 下载批处理文件. 第二步: 你可以通过一个简单的命令(schtasks /?查看帮助)或者使用图形界面(开始-控制面板-系统和安全-管理工具-任务计划程序)运行任务计划管理工具,还可以在%SYSTEMROOT%\System32目录下双击Taskschd.msc来启动它.  

  • Windows下PostgreSQL安装图解

    现在谈起免费数据库,大多数人首先想到的可能是MySQL,的确MySQL目前已经应用在国内很多领域,尤其是网站架设方面.但是,实际上功能最强大.特性最丰富和最复杂的免费数据库应该是PostgreSQL.它的很多特性正是当今许多商业数据库例如Oracle.DB2等的前身. 其实笔者最近也是因为项目需要,接触了一点PostgreSQL的皮毛,最近PostgreSQL又刚发布了8.1版本,笔者结合网上各位高手的经验谈一点自己的安装心得,和才开始接触PostgreSQL的新手朋友共同学习. 从Postgr

  • Postgresql备份和增量恢复方案

    前言 最近工作上使用的数据库一直是Postgresql,这是一款开源的数据库,而且任何个人可以将该数据库用于商业用途.在使用Postgresql的时候,让我最明显的感觉就是这数据库做的真心好,虽然说数据库的安装包真的很小,但是性能和操作的便捷是一点也不输给其他商业的大型数据库,另外在命令行界面下对该数据库直接进行操作的感觉真的是很爽.在使用数据库的时候,我们作为小公司的数据库管理员有一项工作是不可能避免的,那就是数据的备份和恢复问题.PostgreSQL虽然各个方面的有点很多,但是在数据库备份这

  • rman恢复方案和oracle异机恢复

    注:①恢复的前提是已经做好备份②完全恢复数据库是数据库遇到故障,在恢复时候没有丢失任何已经提交事物数据的恢复不完全恢复数据库是数据库遇到故障,在恢复时候丢失部分数据的恢复③在linux下需要设置环境变量,即需要恢复的oracle数据库的实例名:export ORACLE_SID=orcl④当用resetlogs启动数据库时,应该要对数据库进行一次全备份 一.恢复方案1.丢失数据文件,进行完全恢复 复制代码 代码如下: RMAN>startup mount;RMAN>restore databa

  • mysql增量备份及断点恢复脚本实例

    简介 增量备份是指在一次全备份或上一次增量备份后,以后每次的备份只需备份与前一次相比增加或者被修改的文件.这就意味着,第一次增量备份的对象是进行全备后所产生的增加和修改的文件:第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件,如此类推. 目的 解决完全备份中时间长.恢复慢的问题,采取了增量备份 特点 优:无重复数据,备份量不大,时间短 缺:需要上次完全备份及完全备份后的增量备份才能恢复,需对增量备份逐个反复恢复,操作繁琐 实现方式 通过mysql的二进制日志间接实现增量备份:

  • Mysql实现增量恢复的方法详解

    实验介绍 增量恢复一般适用的场景: 1.人为的sql语句破坏了数据库 2.在进行下一次完全备份之前发生系统故障导致数据库数据丢失 3.在主从架构中,主库数据发生了故障 丢失完全备份之后更改的数据的恢复步骤 1.首先做一个完全备份,确保生成完全备份的sql文件. mysql> select * from yx; #完全备份前数据库 +----------+--------+ | name | score | +----------+--------+ | zhangsan | 100.00 | |

  • PostgreSQL备份工具 pgBackRest使用详解

    前言 pgBackRest是一款开源的备份还原工具,目标旨在为备份和还原提供可靠易用的备份. 特性 并行备份和还原 备份操作期间压缩通常是其瓶颈所在.pgBackRest通过并行处理解决了备份期间压缩出现的瓶颈问题. 本地远程操作 自定义协议允许 pgBackRest以最小化配置通过SSH在本地或者远程执行备份.还原和归档.并且该程序也通过协议层提供了PostgreSQL查询接口,以便于必须要再远程访问PostgreSQL,从而保证了其安全性能. 全量,增量和差异备份 支持全量,增量和差异备份.

  • PostgreSQL 数据库跨版本升级常用方案解析

    大家好,我是只谈技术不剪发的 Tony 老师.对于企业而言,将数据库系统升级到新版本通常可以获得更好的性能.更多的功能.最新的安全补丁和错误修复等.因此,本文就来介绍一下 PostgreSQL 数据库版本升级的 3 种常用方案. 升级方案概述 PostgreSQL 版本号由主要版本和次要版本组成.例如,PostgreSQL 12.4 中的 12 是主要版本,4 是次要版本:PostgreSQL 10.0 之前的版本由 3 个数字组成,例如 9.6.19,其中 9.6 是主要版本,19 是次要版本

  • MySQL数据库完全备份与增量备份详解

    目录 定义 完全备份与恢复演示 定义 完全备份就是将数据库中的数据及所有对象全部备份. 由于 MySQL 服务器中的数据文件是基于磁盘的文本文件,所以完全备份就是复制数据库文件,是最简单也是最快速的方式. 但 MySQL 服务器的数据文件在服务器运行期间,总是处于打开状态,为实现真正的完全备份,需要先停止 MySQL 数据库服务器. 为了保障数据的完整性,在停止 MySQL 服务器之前,需要先执行 flush tables 语句将所有数据写入到数据文件中.对于该方法同学们只需了解,因为将生产环境

  • mysql全量备份、增量备份实现方法

    mysql全量备份.增量备份.开启mysql的logbin日志功能.在/etc/my.cnf文件中加入以下代码: [mysqld] log-bin = "/home/mysql/logbin.log" binlog-format = ROW log-bin-index = "/home/mysql/logindex" binlog_cache_size=32m max_binlog_cache_size=512m max_binlog_size=512m 重启mys

  • mysql mysqldump数据备份和增量备份

    本篇文章主要讲如何使用shell实现mysql全量,增量备份.增量备份在周一-周六凌晨3点,会复制mysql-bin.00000*到指定目录:而全量备份则使用mysqldump将所有的数据库导出,每周日凌晨3点执,并会删除上周留下的mysq-bin.00000*.然后对mysql的备份操作会保留在bak.log文件中.如下图:开始:2013年05月02日 15:10:57 结束:2013年05月02日 15:12:16 20130502.sql.tgz succ是由DBFullyBak.sh产生

  • 用Python写脚本,实现完全备份和增量备份的示例

    需求: 在/root/backup下面有两个文件夹dst和src.要求在周一的时候进行完全备份,其余日子进行增量备份.从src备份到dst. 思路及关键点: 建立一个文件,以字典方式记录src的文件名以及文件对应的md5的值 完全备份的时候将文件名和md5值写在一个文件里面.cPickle的知识点. 增量备份的时候比较文件名是否在key里面,没有就要备份:有的话,这个文件的md5值是否改变,改变了就要备份 os.path.join()拼接路径,os.listdir(),os.chdir() ti

随机推荐