PostgreSQL基础备份_增量备份与任意点恢复
栏目: 数据库 · PostgreSQL · 发布时间: 5年前
内容简介:背景假设恢复到某一个指定的时间:如:2018-10-19 10:00:00 (业务场景,在10:30错误的操作删除了某些数据,想恢复到:2018-10-10 10:00:00)
背景
- 操作错误,删除数据,进行恢复
- 数据库崩溃进行恢复
备份和恢复的原理
- 在某一时间点进行一次全量的基础备份,恢复只能基于这个基础备份
- 设置增量日志,不断的进行日志备份。这种日志是预写入日志(WAL),可以根据这个日志恢复到基础备份以来的任意事务点(时间点或者是设置的恢复点)
开发环境
- windows server 2008/windows 7
- PostgreSQL 9.4/(pg10稍有不同)
- 压缩文件gzip
Windows/pg9.4 备份步骤
- 备份与恢复都是需要在安装数据库的机器进行,建议使用的客户端为自带的pgadmin或者是命令行
- 下载windows版本的 gzip压缩软件,并安装。譬如:安装目录为:C:/gzip
-
找到数据库的数据目录。可以通过的命令行,show data_directory得到。如下:
postgres=# show data_directory; data_directory ----------------- D:/pg_data/data (1 row) SHOW
-
在data的上级目录建立基础备份目录和增量日志目录。按照上面的路径例子:D:/pg_data/data,会得到如下的目录
D:/pg_data/data D:/pg_data/data_bak #直接拷贝data目录,预防失败情况 D:/pg_data/pg_archive #用于增量备份的日志 D:/pg_data/pg_base #用于基础备份
-
修改配置文件: D:/pg_data/data/postgres.conf
-
打开归档
archive_mode = on
-
设置归档指令
archive_command = 'C:/gzip/bin/gzip -c %p > D:/pg_data/pg_archive/%f.gz' #注释:%p:表示日志路径,%f:表示日志文件名,使用gzip进行压缩,否则日志非常大。大概有几百倍的压缩率。
-
设置日志级别,至少为archive
wal_level = archive #注释: minimal为最小的日志,这个不能用于日志的备份.至少是hot_standby才能做主从复制
-
打开归档日志进程
max_wal_senders = 2 #表示开个新的进程把日志负责日志的传送。设置大于0即可
-
可选,打开日志收集,主要是为了出现问题的时候查看日志,定位问题
logging_collector = on
-
视情况而定,设置wal日志的保留数目,有时候基础备份太大,导致wal被复写,导致备份失败
wal_keep_segments= 200 # 200 * 16MB = 3200MB 的wal备份
-
打开归档
-
修改复制流权限配置文件 data/pg_hba.conf,否则基础备份会失败
# replication privilege. host replication postgres 127.0.0.1/32 trust
- 重启数据库服务
-
配置PostgreSQL的各种 工具 文件到环境变量Path中去, 主要是利用备份工具等,如
C:\Program Files\PostgreSQL\9.4\bin
-
进入windows命令行(cmd) ,执行如下命令,进行基础备份
pg_basebackup -h 127.0.0.1 -U postgres -p 5430 -Ft -Pv -Xf -z -Z5 -D D:/pg_data/pg_base #命令的参数用途,参考 pg_basebackup --help
进行基础备份后,在目录D:/pg_data/pg_base/下面有文件:base.tar.gz,到这一步,必须成功,否则检测前面步骤出问题的地方。 -
一般此时会在 D:/pg_data/pg_archive目录下面生成日志备份文件,如果没有,尝试强制日志归档命令:
select pg_switch_xlog(); # 在pg10中为:select pg_switch_wal();
此时,在日志归档目录中D:/pg_data/pg_archive中会出现归档日志,到这一步,也必须成功,否则检测前面步骤出现问题的地方。 - 若上面没有正常完成,查看base/pg_log/目录下面的最新日志,定位问题。
windows/pg9.4恢复步骤
假设恢复到某一个指定的时间:如:2018-10-19 10:00:00 (业务场景,在10:30错误的操作删除了某些数据,想恢复到:2018-10-10 10:00:00)
- 关闭数据库服务。备份data的数据为data_bak,防止恢复失败,导致更大的数据丢失。
- 删除data里面的所有内容,并解基础备份的数据D:/pg_data/pg_base/base.tar.gz到data目录中去。
- 在PostgreSQL的安装目录,C:\Program Files\PostgreSQL\9.4\share下,拷贝recovery.conf.sample文件到data目录下面,并修改名字为:recovery.conf
-
修改recovery.conf文件的内容
- 修改恢复命令
restore_command = 'C:/gzip/bin/gzip -c -d D:/pg_data/pg_archive/%f.gz > %p'
1.修改恢复得到的时间点recovery_target_time = '2018-10-19 10:00:00 +08' # +08表示东八区
- 启动数据库,即可恢复到指定的时间。
备份方案
- 建议后台程序/或者人工1个月执行一次基础备份。否则还原的时间太长,或者归档日志的丢失造成的损失
- 基础备份建议只是保留1年或者是半年。时间太长意义不大
其他
- Linux版本相对容易,步骤基本一致,采用直接的cp或者tar,gzip压缩备份恢复日志可实现。注意点是base权限为0600,recovery.conf权限为:0700
- lz4号称最快的压缩解压算法,在linux/windows上面实现都有问题
- windows实战过程,只有gzip压缩解压可行
- 直接采用复制日志文件的机制,windows的copy有问题,采用gnu的cp可行。这个方式有个问题,日志太大。造成磁盘空间浪费
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Postgresql备份与增量恢复
- 实战-MySQL定时增量备份(2)
- 浅谈使用 Binlog 实现 MySQL 增量备份
- xtrabackup全量、增量备份恢复mysql数据库
- percona-xtrabackup实现数据库完全,增量的备份和还原(含一些版本问题与坑)
- 细说HTTP增量更新
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。