一、验证postgresql增量合并的方案

结果：没有有效可行的增量合并方案，暂时放弃

二、梳理postgresql基于wal的增量备份

物理备份与还原适用于跨小版本的恢复但是不能跨平台

逻辑备份与还原备份数据适用于跨版本和跨平台的恢复

postgersql增量备份步骤

1.首先创建归档目录

例如:归档目录为/archive_pg_xlog/xlog

1>mkdir -p /archive_pg_xlog/xlog
2>chown -R postgres:postgres /archive_pg_xlog/xlog
3>chmod 700 /archive_pg_xlog/xlog

2.修改postgresql.conf配置文件

1>wal_level=archive(配置wal的级别)
2>archive_mode=on(开启归档)
3>archive_command='DATE=`date +%Y%m%d`;DIR="/archive_pg_xlog/xlog/$DATE";(test -d $DIR || mkdir -p $DIR)  cp %p $DIR/%f'(配置归档路径)

3.重新启动数据库服务

systemctl restart postgresql（使配置生效）

4.做全量备份

 1>psql -c 'select pg_start_backup(now()::text);'，#执行该命令表示开始备份
 2>tar -cf base.tar /var/lib/pgsql/data/*
 3>psql -c 'select pg_stop_backup();'#tar结束后要关闭备份

5.如果表空间存在，还需要备份表空间，没有则不需要

6.以上操作完成后，增量备份就自动开始了

当xlog写满后，就自动归档到我们指定的目录了

postgresql利用xlog进行还原

模拟灾难，直接删除data目录（或者是data目录下的所有文件丢失）

先检查数据库是否已经停止，如果还未停止需要停止

mkdir data;chown postgres:postgres data;chmod 700 data

将备份的base.tar全量包拷贝到data目录，解压

cp /usr/share/psql/recovery.conf.sample ./data
vim recovery.conf.sample配置restore_command=''
chown postgres:postgres recovery.conf.sample;chmod 700 recovery.conf.sample;mv recovery.conf.sample recovery.conf

启动数据库，当recovery.conf变成了recovery.done时即表示恢复完成

注:xlog文件名由时间线TimeLineID（8位16进制）、逻辑日志文件号（8位16进制）和段文件ID（8位16进制）组成

测试1.

第一次全量时，db有一百万条数据，然后再次插入一百万条数据，模拟灾难，正常恢复

第二次全量时，是在第一次模拟灾难后的场景，即第二次全量备份时有两百万条数据，再次插入十万条数据，模拟灾难，正常恢复

测试2.

再次模拟灾难，在第二次全备份新增十万条数据后，直接删掉data目录

用第一次的全备份数据结合产生的增量来进行恢复，结果，只有两百万条数据，说明该增量不可合并

测试3.

模拟某个xlog文件丢失时

结果：丢失的xlog文件只影响该丢失的xlog文件依赖的全量备份（会导致数据丢失），但是不会影响xlog文件丢失后面的全量备份

对于丢失这种情况暂时还没有找到恢复的办法

如果要还原到最近的那一次,也就是不是因为误操作的等原因的恢复，则不需要配置还原点

recovery_target_name=''(这个是还原点的名字)
recovery_target_time=''(这个是要还原到的具体时间点)
recovery_target_xid='' (以最后结束时的id为准)

创建还原点,也就是还原点的名字select pg_create_restore_point('pitr_test');

创建基于时间的还原点,select now();

创建基于xid的还原点,select txid_current();

补充：PostgreSQL中的log, xlog和clog

pg_log

$PGDATA/pg_log是数据库运行活动日志的默认保存目录，它包括错误信息，查询日志以及启动/关闭数据库的信息。当PostgreSQL启动失败时，这里应该是你第一个应该查看的信息。一些Linux发行版以及其他的软件包管理系统会将这个日志目录移到某些地方，比如：/var/log/postgresql

你可以在pg_log目录里自由地删除、重命名、压缩或者移动文件而不会有什么不好的结果，只要Postgres用户仍然有权限写该目录。如果pg_log随着许多大文件而膨胀，你可能需要在postgresql.conf里减小你想记录日志的事件。

pg_xlog

$PGDATA/pg_xlog是PostgreSQL的事务日志。 这是一些二进制日志文件的集合，文件名类似00000001000000000000008E，它包含最近事务的一些描述数据。这些日志也被用于二进制复制。如果复制、归档或者PITR失败了，当归档正在恢复时，这个目录保存的数据库日志可能会膨胀数GB。这可能会导致你用完你的磁盘空间。不像pg_log，你不能自由地删除、移动或者压缩这个目录的文件。你甚至不能在没有符号链接到该目录的情况下移动这个目录。删除pg_xlog的文件可能会导致不可恢复的数据库损坏。

如果你发现自己处在这样的情况：你发现有100G大小的文件在pg_xlog目录并且数据也启动不了，并且你已经禁止归档/复制并且尝试清理磁盘空间等任何其他的方式，请做以下两个步骤：

1、从pg_xlog目录里移动文件到一个备份磁盘或者共享网络驱动器中，也不要删除它们。

2、移动一些最老的文件，直到足够允许PostgreSQL启动起来。

pg_clog

$PGDATA/pg_clog包含了事务的元数据。这种日志用于告诉PostgreSQL哪个事务已经完成、哪个还没有完成。clog是比较小的并且没有任何理由会膨胀，所以，你应该没有任何理由去碰触它。在任何时候你都不应该从pg_clog里删除文件，如果你这样子做，还不如完全地删除整个数据库目录。缺少clog是不可恢复的。请注意，这意味着，如果你在$PGDATA目录里备份文件，你应该确定同时包含pg_clog和pg_xlog，否则你可能会发现你的备份是不可用的。

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