PG备份恢复（二）

阅读量：664 次

发布时间：2019-03-15

本文共 9574 字，大约阅读时间需要 31 分钟。

文章目录

二、物理备份

2.1 冷备

物理冷备就是将数据库停止掉后，通过对PGDATA目录进行物理拷贝进行物理备份。该方式最大的缺点就是为保证数据一致性必须停止数据库。

2.2 热备

1、快照备份

通过对服务器进行快照备份，使用文件系统或者块设备级别的快照功能完成备份，保证数据为备份时刻的一致性。

2、PITR热备份(point-in-time-recover)

RITR的实现主要是基于PG数据库的WAL日志，数据库所有的变更操作都会记录在WAL日志中。在PG数据库中WAL日志可用于做崩溃恢复，当数据库宕机重启后，数据库定位最后一次checkpoint的位点，并通过WAL日志恢复checkpoint之后的所有变更操作，以便于数据库达到一个一致性状态。也正是基于此原理，PITR也是通过WAL日志来保障数据备份的一致性。

PG的物理热备主要分为两部分，第一部分是数据文件的在线拷贝，这部分也被称为基础备份，基础备份无法保证数据的一致性；第二部分是WAL日志的备份。基础备份 + WAL日志备份才称得上PG数据库的一个完整的备份，才能保障备份数据库的一致性。

1）pg_hba.conf 文件

pg_hba.conf文件为pg的认证配置文件，无论是我们用户登录还是主从复制，都需要在该文件下填写相关的认证配置，保证可正常联通数据库。

pg_hba.conf主要由5个参数组成：Type（主机类型）、Database（数据库名）、User（用户名）、Address（IP地址和掩码）、 Method（加密方法）

Type

表示允许的连接方式。

"local"表示使用 Unix-domain socket 进行连接；

“host” 表示可以使用 ssl或者非ssl加密的 TCP/IP socket 进行连接；

“hostssl” 表示必须通过ssl加密的 TCP/IP socket 进行连接；

“hostnossl” 表示通过使用非ssl的 TCP/IP socket 进行连接。

Database

表示可以访问数据库信息，可以为 “all”, “sameuser”, “samerole”, “replication”，或者业务数据库名称；

“all"并不包括"replication”，若需要方通replication需要单独编写放通规则；

多个数据库使用逗号分隔

User

表示认证配置的数据库用户信息，可以为"all"也可以指定某个数据库用户；

多个用户授权可使用逗号分隔；

可引用外部文件中配置信息信息认证配置，@${filename}

Address

表示认证配置的主机IP信息，可以是一个主机名，也可以是IP+掩码；

0.0.0.0/0表示所有主机

Method

表示密码加密策略，可以设置为"trust", “reject”, “md5”, “password”, “scram-sha-256”, “gss”, “sspi”, “ident”, “peer”, “pam”, “ldap”, “radius” or “cert”；

password表示以明文方式发送密码；

2）wal日志备份

方式	特点
wal日志归档	总是落后一个wal日志，通过cp、scp等命令实现
流复制	主要有同步和异步两种模式，准实时备份，主从复制搭建基于此方式实现

wal日志归档配置

# 相关参数配置，修改后需要重启数据库# 归档目录需要对postgres进行授权$ vi postgresql.confwal_level = replica             # minimal, replica, or logicalarchive_mode = on               # enables archiving; off, on, or always                                # (change requires restart)archive_command = 'cp %p /data/pgsql12/archive/%f && echo %f >> /data/pgsql12/archive/archive.list'             # command to use to archive a logfile segment# 重启数据库$ psql -D /data/pgsql12/data stop$ psql -D /data/pgsql12/data start# 查看归档wal日志$ pwd/data/pgsql12/archive$ lltotal 16388-rw------- 1 postgres postgres 16777216 Sep  5 16:44 00000001000000000000000D-rw------- 1 postgres postgres       25 Sep  5 16:44 archive.list

3）pg_basebackup 工具

pg_basebackup工具必须通过 replication协议连接数据库实例，所以在使用 pg_basebackup 工具之前，我们需要先根据实际情况配置 pg_hba.conf 认证信息。

pg_basebackup工具只能对整个数据库实例进行备份，无法单独选择某个数据库、某张表进行备份。该工具可以连接到一个主数据库进行备份，也可以通过连接到一个standby数据库实例进行备份。

基本语法以及重要参数：

pg_basebackup [OPTION]...

参数	含义
-D/–pg-data	备份文件目录，表示将备份文件写入到那个目录下
-F/–format	默认为p、可选择p、t
-r/–max-rate	传输数据的最大速率限制
-R/–write-recovery-conf	输出用于replication的配置信息
-X, --wal-method	指定复制wal日志的方式，有none、fetch、stream，推荐使用stream避免接收wal信息是源端日志被覆盖
-z, --gzip	是否压缩，配合-F t使用
-Z, --compress=0-9	压缩等级，数字越大压缩率越大、越消耗CPU资源
-c, --checkpoint	设置checkpoint的模式：fast、spread
-C, --create-slot	创建复制槽
-S, --slot=SLOTNAME	指定复制槽名称
-l, --label=LABEL	指定一个备份标识，便于运维人员后续的维护
-n, --no-clean	do not clean up after errors
-N, --no-sync	do not wait for changes to be written safely to disk
-P, --progress	打印备份进度信息
-v, --verbose	输出详细的信息

常用备份命令示例

用于搭建standby数据库的常用命令：

# -h、-p -U 指定源数据库IP、port、数据库用户 信息# -D 指定目标端数据目录# -P、-v 表示打印详细的备份信息# -R 表示写入replication的恢复文件 ??(有点不要确定具体做了什么)# -X stream 表示备份开始后，启动一个stream链接从主数据库接收wal日志，避免了featch模式下wal日志被覆盖的风险# -C、-S 指定了在源数据库创建一个什么名称的复制槽# -l 若不指定会创建一个默认的标签，建议使用该参数做一些时间标识，便于维护-bash-4.2$ pg_basebackup -h 192.168.0.175 -p 5432 -D /data/pgsql12/data/ -U repl  -P -v -R -X stream -C -S ${pgstandby_slotname}-bash-4.2$ cat backup_label.old                             //查看标签信息START WAL LOCATION: 0/2000028 (file 000000010000000000000002)CHECKPOINT LOCATION: 0/2000060BACKUP METHOD: streamedBACKUP FROM: masterSTART TIME: 2020-09-05 13:06:31 CSTLABEL: pg_basebackup base backupSTART TIMELINE: 1-bash-4.2$

用于基本的备份恢复常用命令

4）按时间恢复示例

1.先通过pg_basebackup做一次基础备份

$ pg_basebackup -D /data/pg_backup/  -v -P -Urepl -h 127.0.0.1 -p5432 -Rpg_basebackup: initiating base backup, waiting for checkpoint to completepg_basebackup: checkpoint completedpg_basebackup: write-ahead log start point: 0/F000028 on timeline 1pg_basebackup: starting background WAL receiverpg_basebackup: created temporary replication slot "pg_basebackup_15981"32566/32566 kB (100%), 1/1 tablespacepg_basebackup: write-ahead log end point: 0/F000138pg_basebackup: waiting for background process to finish streaming ...pg_basebackup: syncing data to disk ...pg_basebackup: base backup completed

2.写入部分数据

db1=# create table t3(id int);CREATE TABLEdb1=# insert into t3 values (generate_series(1,1000));INSERT 0 1000db1=# select now();              now------------------------------- 2020-09-05 17:34:21.595701+08(1 row)db1=# select pg_current_wal_lsn(),                  pg_walfile_name(pg_current_wal_lsn()),                  pg_walfile_name_offset(pg_current_wal_lsn()); pg_current_wal_lsn |     pg_walfile_name      |      pg_walfile_name_offset--------------------+--------------------------+----------------------------------- 0/100201A8         | 000000010000000000000010 | (000000010000000000000010,131496)(1 row)db1=# select pg_current_wal_lsn(); pg_current_wal_lsn-------------------- 0/100201A8(1 row)db1=# create table t4(id int);CREATE TABLEdb1=# insert into t4 values (generate_series(1,1000));INSERT 0 1000

3.模拟数据库故障，通过基本备份以及wal归档日志进行恢复

$ pg_ctl -D /data/pgsql12/data/ stopwaiting for server to shut down.... doneserver stopped$ ll /data/pgsql12/archivetotal 65544-rw------- 1 postgres postgres 16777216 Sep  5 16:44 00000001000000000000000D-rw------- 1 postgres postgres 16777216 Sep  5 17:26 00000001000000000000000E-rw------- 1 postgres postgres 16777216 Sep  5 17:26 00000001000000000000000F-rw------- 1 postgres postgres      337 Sep  5 17:26 00000001000000000000000F.00000028.backup-rw------- 1 postgres postgres 16777216 Sep  5 17:40 000000010000000000000010-rw------- 1 postgres postgres      141 Sep  5 17:40 archive.list

4.将基础备份拷贝只PGDATA目录下

$ mv data data_bak$ mv pg_backup data         //该步骤要关注目录的权限，默认备份的目录权限不正确，可使用cp -r来做

5.修改 postgresql.auto.conf 文件的相关recover参数

# 基于时间点进行恢复restore_command = 'cp /data/pgsql12/archive/%f %p > /data/pgsql12/archive/recovery.log 2>&1 'recovery_target_time = '2020-09-05 17:34:21'# 基于lsn进行恢复restore_command = 'cp /data/pgsql12/archive/%f %p > /data/pgsql12/archive/recovery.log 2>&1 'recovery_target_lsn='0/100201A8'

6.启动数据库进行恢复

$ pg_ctl  -D /data/pgsql12/data start -l /data/pgsql12/logs/logfilewaiting for server to start.... doneserver started# 基于时间点恢复的日志2020-09-05 18:04:14.891 CST [16354] LOG:  starting PostgreSQL 12.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit2020-09-05 18:04:14.891 CST [16354] LOG:  listening on IPv4 address "0.0.0.0", port 54322020-09-05 18:04:14.891 CST [16354] LOG:  listening on IPv6 address "::", port 54322020-09-05 18:04:14.895 CST [16354] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"2020-09-05 18:04:14.912 CST [16355] LOG:  database system was interrupted; last known up at 2020-09-05 17:26:43 CST2020-09-05 18:04:14.928 CST [16355] LOG:  entering standby mode2020-09-05 18:04:15.290 CST [16355] LOG:  restored log file "00000001000000000000000F" from archive2020-09-05 18:04:15.310 CST [16355] LOG:  redo starts at 0/F0000282020-09-05 18:04:15.312 CST [16355] LOG:  consistent recovery state reached at 0/F0001382020-09-05 18:04:15.419 CST [16354] LOG:  database system is ready to accept read only connections2020-09-05 18:04:15.861 CST [16355] LOG:  restored log file "000000010000000000000010" from archive2020-09-05 18:04:15.875 CST [16355] LOG:  recovery stopping before commit of transaction 496, time 2020-09-05 17:37:55.830747+082020-09-05 18:04:15.875 CST [16355] LOG:  recovery has paused2020-09-05 18:04:15.875 CST [16355] HINT:  Execute pg_wal_replay_resume() to continue.# 基于lsn恢复的日志2020-09-05 18:09:51.809 CST [16442] LOG:  starting PostgreSQL 12.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit2020-09-05 18:09:51.809 CST [16442] LOG:  listening on IPv4 address "0.0.0.0", port 54322020-09-05 18:09:51.809 CST [16442] LOG:  listening on IPv6 address "::", port 54322020-09-05 18:09:51.814 CST [16442] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"2020-09-05 18:09:51.919 CST [16443] LOG:  database system was interrupted; last known up at 2020-09-05 17:26:43 CST2020-09-05 18:09:51.989 CST [16443] LOG:  entering standby mode2020-09-05 18:09:52.086 CST [16443] LOG:  restored log file "00000001000000000000000F" from archive2020-09-05 18:09:52.119 CST [16443] LOG:  redo starts at 0/F0000282020-09-05 18:09:52.121 CST [16443] LOG:  consistent recovery state reached at 0/F0001382020-09-05 18:09:52.121 CST [16442] LOG:  database system is ready to accept read only connections2020-09-05 18:09:52.164 CST [16443] LOG:  restored log file "000000010000000000000010" from archive2020-09-05 18:09:52.179 CST [16443] LOG:  recovery stopping after WAL location (LSN) "0/100201A8"2020-09-05 18:09:52.179 CST [16443] LOG:  recovery has paused2020-09-05 18:09:52.179 CST [16443] HINT:  Execute pg_wal_replay_resume() to continue.

7.数据验证

postgres=# \c db1You are now connected to database "db1" as user "postgres".db1=# \d        List of relations Schema | Name | Type  |  Owner--------+------+-------+---------- public | t1   | table | postgres public | t2   | table | postgres public | t3   | table | postgres(3 rows)db1=# select count(*) from t3; count-------  1000(1 row)db1=# select count(*) from t4;ERROR:  relation "t4" does not existLINE 1: select count(*) from t4;

问题：

1、如果我们基于lsn进行恢复，如何寻找需要恢复到的Lsn位点信息？

2、当主从架构加直接恢复master时会出现以下报错，我们应该如何处理这种情况？

2020-09-05 18:05:48.345 CST [16387] ERROR:  replication slot "pgstandby1" does not exist2020-09-05 18:05:53.351 CST [16388] ERROR:  replication slot "pgstandby1" does not exist

转载地址：http://zgxmz.baihongyu.com/

你可能感兴趣的文章