postgresql恢复备份主从

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了postgresql恢复备份主从，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6206字，纯文字阅读大概需要9分钟。

内容图文

http://m.blog.chinaunix.net/uid-20665047-id-5817656.html

http://www.postgres.cn/docs/11/continuous-archiving.html#BACKUP-ARCHIVING-WAL

https://blog.csdn.net/yaoqiancuo3276/article/details/80826073

全量备份

我们要做实时恢复，就需要对数据库做增量备份，也就是记录每次数据库的操作。恢复的时候，就按照记录，一条条的把数据还原到正确的地方。但是不管怎么样，都需要有一个基准，也就是从一个初始状态开始，按照操作记录，一条条的恢复。

pg_basebackup

pg_basebackup的作用相当于是把数据库目录下的相关数据文件拷贝到一个地方。

只能用这个做全量备份或是自己拷贝所有的数据库文件，不可以使用pg_dump、pg_dumpall或者navicat的备份工具备份。因为pg_dump等只是把数据库的表备份出来。postgresql的还原需要数据库目录中的一些信息。这也是与mysql不一样的地方。

mysql是在当前数据的基础上，一条条的执行binlog中的命令。而postgresql是在数据库文件记录的当前状态下，向前同步到对应的状态。比如同步了第几条wal日志信息，还有哪些信息没同步，需要同步到第几个。如果仅仅是把数据库的表导出来，这个无法做还原，因为数据库当前状态一直是最新的状态，就算把数据改回原来的数据，对于数据库来说，只不过是更新了新的数据，并不认为是回退到了原来的某个时间点。

pg_basebackup -D /home/postgres/basebackup/

把数据全备份到指定目录

pg_dump

pg_dump dbname > dbback1

把数据库名字是dbname的数据备份到dbback1中，上面的语句并没有指定用户名和密码，是因为在postgres自己的用户下，默认配置是peer访问权限，也就是在自己用户下，不需要输入密码。

psql db_payserver < dbback1

把原来备份的数据还原。

db_dumpall

db_dumpall备份的数据更多。这个是把整个数据库备份。每个单独的数据库调用的是db_dump。但是它还额外备份了一些其他信息，其中包括

所有数据库公用的全局对象（pg_dump不保存这些对象），数据库角色和表空间都会被转储。包括适数据库用户和组、表空间以及适合所有数据库的访问权限等属性。

pg_dumpall需要多次连接到PostgreSQL服务器（每个数据库一次）。如果你使用口令认证，可能每次都会要求口令。这种情况下使用一个~/.pgpass会比较方便。

pg_dumpall > dball

psql -f dball

打开归档

与mysql的binlog类似，postgresql也会保留对数据库的操作日志，这也是时间点恢复的基础。同样需要我们配置相关参数打开。

修改配置

vim /etc/postgresql/11/main/postgresql.conf

wal_level = logical                     # minimal, replica, or logical
                                        # (change requires restart)
archive_mode = on               # enables archiving; off, on, or always
                                # (change requires restart)
archive_command = ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f‘           # command to use to archive a logfile segment
                                # placeholders: %p = path of file to archive
                                #               %f = file name only
                                # e.g. ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f‘

配置解释

wal_level-设置wal log需要记录哪些信息，minimal记录的信息不全，不能恢复数据。所以信息需要是replica或是更高的logical。这个等级就是记录的信息越来越多。

archive_mode-是否打开归档

archive_command-这个是当postgresql完成一个归档的时候，运行的命令。postgresql与mysql一样会记录每一次数据库操作，放到一个文件中。这个文件是有大小限制的，默认16m的时候就会换一个文档。当发生这个操作的时候，就会运行archive_command指定的命令。我们可以把当前的文档拷贝到一个地方备份起来。test的目的是不要覆盖已有的文件

wal_level是设置wal日志的模式，postgresql不管有没有设置，都会有wal日志。

postgresql产生wal日志后，会不断的删除原来的wal文档，为了可以恢复到以前更老的时间点，需要每次postgresql完成一个wal日志文件创建下一个文件的时候，把当前的文件拷贝到一个地方保存起来。归档的作用就是postgresql给我们提供的一个借口，可以自动的完成这个操作。

注意事项

windows下创建的目录，用来拷贝保存wal日志。权限需要增加network service用户组，不然会报错没有权限，无法拷贝数据。

重启服务或是系统

我们可以调用pg_switch_wal命令来刷新强制产生一次归档，看看数据是否拷贝到我们命令设置的地方。

数据还原测试

通过pg_basebackup全量本分数据库

这就相当于做了一个还原点，从现在这个点往后的数据都可以还原

确定打开了wal日志，并设定为replica或logical

确定打开了归档

修改数据

第一条数据改为111

第二条数据改为222

第三条数据改为333

查看当前wal日志

SELECT pg_walfile_name(pg_current_wal_lsn())

查看当前wal详细信息

/usr/lib/postgresql/11/bin/pg_controldata /var/lib/postgresql/11/main

手动归档当前wal日志

select pg_switch_wal();

手动把当前的wal刷新一下，切换到另一个新的日志。这样就可以分析当前的日志了。因为分析正在使用的wal日志有可能会报错。

运行这个命令或是数据库在重启（也就是关闭的时候）或是在系统重启（也就是数据库关闭的时候），都会切换日志，运行归档命令。

这个也可以不做，因为恢复数据的时候需要停止数据库，这是也会归档wal日志。

停止数据库

把数据库的data目录拷贝到一个地方，防止恢复失败的时候导致更多数据丢失

C:\Program Files\PostgreSQL\11\data

/var/lib/postgresql/11/main

上面是windows和linux下默认安装的data目录

清空原来的data目录下的数据

把上面pg_basebackup备份的数据拷贝到data目录

就相当于从备份那个点开始还原

分析日志

pg_waldump是用来分析wal日志的命令

pg_waldump 000000040000000000000010

这个命令就是导出日志的详细信息。这个命令有可能不在系统的环境中，直接执行会报找不到命令的错误，可以通过find找到对应的位置。

postgresql的wal日志有一个很大的问题，就是不知道执行的是什么sql语句。这个与mysql的binlog比起来就麻烦了很多。虽然有一些方法可以导出来，但是太麻烦了。希望postgresql以后可以提供直接在日志中显示sql语句的功能。

上面就是wal日志的详细信息，我们可以看到COMMIT信息，还有对应的日期。COMMIT信息上面描述了这次操作的类型，比如HOT_UPDATE，就是运行了update命令，更新了数据。

我们看到中间有running xid 1205; online等信息，xid 1205就是这次运行的事务id。也就是我们修改数据库，默认数据库也会开启事务，与我们自己写的事务一样，为了保证这次修改要么成功，要么没修改，不存在中间状态。

我们还原的时候可以根据这个事务id还原，就可以保证精确度。

上面修改了三次，我们看到这里有三个事务id，1205、1206、1207。所以如果还原到第二条修改，那就是1206.

拷贝wal日志到data目录下的pg_wal

拷贝recovery.conf.sample到data目录下，并且修改名字为recovery.conf

这里面有注释，可以根据注释修改，我这里只打开了两个

restore_command = ‘‘

recovery_target_xid = ‘1206‘

第一个是必须要开的，就是把原来的归档，wal日志，拷贝到pg_wal目录，如果提前自己拷贝进来，直接是空就好了。

第二个是按照xid的模式还原到1206个xid

启动数据库

我们看到数据还原到第二条修改，第三条修改还是原来的值

postgresql恢复备份主从

标签：ini   开启   sele   产生   描述   数据库操作   数据   segment   无法拷贝   

本文系统来源：https://www.cnblogs.com/studywithallofyou/p/12403160.html

内容总结

以上是互联网集市为您收集整理的postgresql恢复备份主从全部内容，希望文章能够帮你解决postgresql恢复备份主从所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端