PostgreSQL 基于日志的备份与还原

参考:http://www.postgresql.org/docs/9.5/static/continuous-archiving.html

http://www.mkyong.com/database/postgresql-point-in-time-recovery-incremental-backup/

wal,即预写式日志,是日志的标准实现方式,简单而言就是将对数据库的变动记录到日志 中,而后在将具体的新数据刷新到磁盘。PostgreSQL将该日志维护在数据文件夹下的子文件夹pg_xlog中。当数据库崩溃后,可以通过“重放”日志中的“动作”,将数据库恢复。也就是说,只要拥有一个基础备份和完整的日志文件,理论上可以将数据库库恢复到任意基础备份以来的任意时刻点。不仅如此,如果在另一个实例上将这些日志不停的“重放”,那么就拥有了一个完整的在线备份,也就是“复制”。

pg_xlog下日志文件不会无限制增多,也就是说并不用担心日志的增多使得磁盘空间捉襟见肘。默认每个日志文件为16M大小,即当增长到16M时,就会切换到别的文件,并复用之前的文件 。因此,为了保证有个完整的日志链,必须将写满的文件复制保存到一个特定的文件 夹。对于最后一个还未满16M的日志文件,可以手动触发一次切换。

备份(操作均使用系统账号postgres完成 )

  1. 登录数据库创建测试数据库
postgres@debian:~$ psql
psql (9.5.0)

Type "help" for help.

postgres=# CREATE DATABASE test;

CREATE DATABASE
  1. 修改配置文件,开启日志备份,将写满的文件复制到archive文件夹下
vim /etc/postgresql/9.5/main/postgresql.conf
wal_level = archive

archive_mode = on

archive_command = ‘ test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f‘
  1. 创建archive文件夹,并重启数据库服务
[email protected]:~$ mkdir archive

[email protected]:~$ /usr/lib/postgresql/9.5/bin/pg_ctl restart -D /var/lib/postgresql/9.5/main/ -o "-c config_file=/etc/postgresql/9.5/main/postgresql.conf"

2016-01-18 09:30:42 CST [2937-2] LOG:  received fast shutdown request

2016-01-18 09:30:42 CST [2937-3] LOG:  aborting any active transactions

2016-01-18 09:30:42 CST [2942-2] LOG:  autovacuum launcher shutting down

2016-01-18 09:30:42 CST [2939-1] LOG:  shutting down

waiting for server to shut down.....2016-01-18 09:30:44 CST [2939-2] LOG:  database system is shut down

 done

server stopped

server starting

[email protected]:~$ 2016-01-18 09:30:45 CST [2972-1] LOG:  database system was shut down at 2016-01-18 09:30:44 CST

2016-01-18 09:30:45 CST [2972-2] LOG:  MultiXact member wraparound protections are now enabled

2016-01-18 09:30:45 CST [2971-1] LOG:  database system is ready to accept connections

2016-01-18 09:30:45 CST [2976-1] LOG:  autovacuum launcher started
  1. 创建测试表
postgres@debian:~$ psql

psql (9.5.0)

Type "help" for help.

postgres=# \c test

You are now connected to database "test" as user "postgres".

test=# CREATE TABLE testPITR1 AS SELECT * FROM pg_class, pg_description;

SELECT 1192063
  1. 创建基础备份
psql -c "SELECT pg_start_backup(‘base‘, true)"

cd /var/lib/postgresql/9.5/

tar -cvf main.tar main

psql -c "SELECT pg_stop_backup()"

  6. 继续创建测试表,切换日志

postgres@debian:~$ psql

psql (9.5.0)

Type "help" for help.

postgres=# \c test

You are now connected to database "test" as user "postgres".

test=# CREATE TABLE testPITR2 AS SELECT * FROM pg_class, pg_description;

SELECT 1203562

test=#  select * from current_timestamp;

              now             

-------------------------------

 2016-01-18 10:02:15.229335+08

(1 row)

test=# CREATE TABLE testPITR3 AS SELECT * FROM pg_class, pg_description;

SELECT 1215061

test=#  select * from current_timestamp;

              now             

-------------------------------

 2016-01-18 10:02:51.029447+08

(1 row)

test=# select pg_switch_xlog();

 pg_switch_xlog

----------------

 0/3DDE6750

(1 row)

恢复

关闭数据库,模拟数据库宕机,此时,数据库test中应该有3张表,其中1张表在基础备份前,也就是恢复完数据文件即可找回,而另2张表则需恢复相应的日志文件。模拟恢复到testPITR2创建时刻点。

  1. 关闭数据库服务,重命名数据文件夹
[email protected]:~$ /usr/lib/postgresql/9.5/bin/pg_ctl stop -D /var/lib/postgresql/9.5/main/

2016-01-18 10:06:12 CST [2971-2] LOG:  received fast shutdown request

2016-01-18 10:06:12 CST [2971-3] LOG:  aborting any active transactions

2016-01-18 10:06:12 CST [2976-2] LOG:  autovacuum launcher shutting down

2016-01-18 10:06:12 CST [2973-1] LOG:  shutting down

waiting for server to shut down.....2016-01-18 10:06:13 CST [2973-2] LOG:  database system is shut down

 done

server stopped

[email protected]:~$ mv 9.5/main 9.5/main.old
  1. 解压备份数据文件,开启服务,验证此时只有基础备份前的表testpitr1
postgres@debian:~$cd /var/lib/postgresql/9.5/

postgres@debian:~/9.5$ tar -xvf 9.5/main.tar

postgres@debian:~$ 2016-01-18 10:26:40 CST [3342-1] LOG:  database system was interrupted; last known up at 2016-01-18 09:54:56 CST

2016-01-18 10:26:40 CST [3342-2] LOG:  redo starts at 0/17000098

2016-01-18 10:26:40 CST [3342-3] LOG:  invalid record length at 0/17009348

2016-01-18 10:26:40 CST [3342-4] LOG:  redo done at 0/170092D8

2016-01-18 10:26:40 CST [3342-5] LOG:  last completed transaction was at log time 2016-01-18 09:48:26.585085+08

2016-01-18 10:26:40 CST [3342-6] LOG:  MultiXact member wraparound protections are now enabled

2016-01-18 10:26:40 CST [3341-1] LOG:  database system is ready to accept connections

2016-01-18 10:26:40 CST [3346-1] LOG:  autovacuum launcher started

postgres@debian:~$ psql

psql (9.5.0)

Type "help" for help.

postgres=# \c test

You are now connected to database "test" as user "postgres".

test=# \d

           List of relations

 Schema |   Name    | Type  |  Owner  

--------+-----------+-------+----------

 public | testpitr1 | table | postgres

(1 row)
  1. 停掉数据库,删除数据文件夹,重新解压基础备份,创建recovery.conf,将数据库恢复到testpitr2时刻
vi recovery.conf

restore_command = ‘cp /var/lib/postgresql/archive/%f %p‘

recovery_target_time = ‘2016-01-18 10:02:15‘

[email protected]:~/9.5/main$ /usr/lib/postgresql/9.5/bin/pg_ctl start -D /var/lib/postgresql/9.5/main/ -o "-c config_file=/etc/postgresql/9.5/main/postgresql.conf" -l /var/lib/postgresql/recovery.log

可以在恢复日志中看到这么一句话:

2016-01-18 11:22:39 CST [1743-44] LOG:  recovery stopping before commit of transaction 630, time 2016-01-18 10:02:46.080443+08
  1. 验证,进入数据库,发现testpitr2已经恢复
postgres@debian:~$ psql

psql (9.5.0)

Type "help" for help.

postgres=# \c test

You are now connected to database "test" as user "postgres".

test=# \dt

           List of relations

 Schema |   Name    | Type  |  Owner  

--------+-----------+-------+----------

 public | testpitr1 | table | postgres

 public | testpitr2 | table | postgres

(2 rows)

如果需要恢复table3,则必须再次删除数据文件夹,建立recovery.conf。

时间: 2024-12-29 10:32:47

PostgreSQL 基于日志的备份与还原的相关文章

sqlserver日志的备份与还原

----------完整备份与还原----------                --完整备份数据库--backup database studb to disk='e:\stu.bak'backup log studb to disk='e:\stu_log.bak' use mastergo--还原数库库-- restore database studb from disk='e:\stu.bak' with replace,norecovery restore log studb fr

(2.8)备份与还原--在大容量恢复模式下事务日志的角色

简介 日志的作用是保证持久性和数据一致性,通过日志可以实现数据的Undo与Redo,因此通过日志,SQL Server不仅仅可以实现灾难恢复,还可以通过日志的Redo来实现高可用性.本篇文章主要讲述日志在SQL Server中提供的几种高可用性中的作用以及在灾难恢复中的角色. 日志损坏 日志可能会由于IO子系统的故障而损坏,当出现日志损坏时,如果您对日志的原来略有了解,并能在日志损坏的情况下尽量挽救数据,那么感觉一定是非常好的:-),下面我们来了解几种日志损坏的情况下的恢复情况. 1.数据库正常

基于文件组备份还原

目前手上有一个资料库,切分几个文件,一个主文件组一个归档文件组,只有主文件有变化,其他文件组固定时间内,将主文件组内文件转移至归档文件组中. 备份时,完整备份文件过大,使用文件组备份方式处理. 备份: 1.完整备份资料库 2.备份各文件组 backup database [Test] filegroup='primary' to disk='D:\DB\Primary.bak' 3.备份日志 backup log Test to disk='D:\DB\log.bak' with norecov

(2.7)备份与还原--在完全恢复模式下事务日志的角色

简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会小.而墨菲定律(事情如果有变坏的可能,无论这种可能性有多小,它总会发生)仿佛是给DBA量身定做的.在上篇文章介绍的简单恢复模式下,从最近一次备份到当前的数据都会存在丢失的风险.而完整备份模式使得数据丢失的风险大大减少.本文主要介绍在完整备份模式下概念原理和日志所处的角色. 完整(Full)恢复模式 完整恢复模式通过将对数据库的任何修改记录到日志来给予数据最大程度的保护.在完整恢复模式下,日志的作用不仅仅是保证了数

(2.6)备份与还原--在简单恢复模式下事务日志的角色

简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如"简单"这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先要了解SQL Server提供的几种不同备份类型. SQL Server提供的几种备份类型 SQL Server所提供的几种备份类型基本可以分为以下三种(文件和文件组备份以及部分备份不在本文讨论之列): 1.完整(Full)备份:直接将所备份的数据的所有区(Extent)

Mariadb学习笔记-日志及备份

Mysql的日志种类 查询日志:general_log 慢查询日志:log_slow_querles 错误日志:log_error,log_warnings 二进制日志:binlog 中继日志:relay_log 事务日志:innodb_log 查询日志 记录查询语句,日志存储位置: 文件:file表:table(mysql.general_log) general_log={ON|OFF}general_log_file=HOSTNAME.loglog_output={FILE|TABLE|N

mysql备份与还原

防伪码:志向不过是记忆的奴隶,生气勃勃地降生,但却很难成长. 一.mysqldump备份结合binlog日志恢复 MySQL 备份一般采取全库备份加日志备份的方式,例如每天执行一次全备份,每小时执行一 次二进制日志备份.这样在 MySQL 故障后可以使用全备份和日志备份将数据恢复到最后一个 二进制日志备份前的任意位置或时间. 1.binlog介绍 mysql的二进制日志记录着该数据库的所有增删改的操作日志(前提是要在自己的服务器上 开启binlog),还包括了这些操作的执行时间.为了显示这些二进

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

ORACLE RMAN备份及还原 RMAN可以进行增量备份:数据库,表空间,数据文件

ORACLE RMAN备份及还原 RMAN可以进行增量备份:数据库,表空间,数据文件 只有使用过的block可以被备份成backup set 表空间与数据文件对应关系:dba_data_files / v$datafile_header 在noarchivelog模式下,可以使用RMAN备份read-only和offline的表空间 ORACLE RMAN停机备份: 备份 RMAN连接上ORACLE,WINDOWS下在命令模式下 RMAN TARGET / 连接本地数据库用的是本地认证模式.RM