CentOS7中PotsgreSQL11双机备份

Love The Way You Lie 2022-04-08 08:23 383阅读 0赞

根据搜集的资料安装测试并在安装测试过程中整理的文档，如有不足希望不吝赐教。

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

**目录**

一、环境介绍

二、主节点配置

1.修改配置文件

2.创建超级用户

3.基础备份

三、配置备节点

1.修改配置文件

四、查询主备

1.pg\_controldata命令

2.字典表pg\_stat\_replication

3.进程信息识别

4.通过pg函数

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

# 一、环境介绍 #

系统：两台CentOS7.5

ip：172.17.0.84（主）、172.17.0.86（备）

数据库版本：PotsgreSQL11

主从流复制配置：https://www.cnblogs.com/yjf512/p/4499547.html

# 二、主节点配置 #

## 1.修改配置文件 ##

使用postgres用户：su - postgres

进入data目录(实际目录可能不同)：cd /var/lib/pgsql/11/data

修改配置文件：vim postgresql.conf

编辑文件内容，找到如下设置项并修改：

wal_level = hot_standby		# 这个是设置主为wal的主机
    max_wal_senders = 1		# 这个设置了可以最多有几个流复制连接，差不多有几个从，就设置几个
    wal_keep_segments = 500	  # 设置流复制保留的最多的xlog数目
    hot_standby = on
    logging_collector = on
    log_directory = 'log'
    log_filename = 'postgresql-%a.log’

上边配置项部分需要取消注释，日志配置如果已经有，保持默认即可。修改完成后保存退出。

## 2.创建超级用户 ##

登录数据库，在主节点数据库中创建一个超级用户，standby数据库会使用这个用户连接到主库上拖WAL日志。

psql

下面创建用户命令是在登录数据库后执行：

create user standby SUPERUSER LOGIN password 'standby';

![20181207113703476.png][]

## 3.基础备份 ##

开启备份功能

psql -c "select pg\_start\_backup('backup0001')"

![2018120711373490.png][]

使用scp命令将data目录下数据远程拷贝到备库data目录下：

scp -r /var/lib/pgsql/11/data/\* 172.17.0.86:/var/lib/pgsql/11/data/

> 因为上面的命令会默认使用postgresql创建的用户postgres，因此此处使用了root用户发送，但是需要在发送完成后在备机上修改文件属组，直接递归将整个data目录的用户和组全部修改即可（chown -R postgres:postgres data/）。
> 
> scp -r /var/lib/pgsql/11/data/\* root@172.17.0.86:/var/lib/pgsql/11/data/

关闭备份功能

psql -c "select pg\_stop\_backup()"

![20181207113803931.png][]

修改完成后重启主数据库。

# 三、配置备节点 #

## 1.修改配置文件 ##

修改data目录下postgresql.conf文件，把其中的hot\_standby设置为on。

拷贝示例文件/usr/pgsql-11/share/recovery.conf.sample到/var/lib/pgsql/11/data/目录下，然后改名成recovery.conf：

mv recovery.conf.sample recovery.conf

编辑（vim）recovery.conf修改相关的配置项为如下内容：

standby_mode = 'on'
    primary_conninfo = 'host=172.17.0.84 port=5432 user=standby password=standby'

![20181207113905150.png][]

修改完成后保存退出，然后重启从数据库。

# 四、查询主备 #

## 1.pg\_controldata命令 ##

首先切换到postgres用户（已经切换忽略）：su - postgres

然后使用pg\_controldata命令查看状态，这里需要注意的是，pg\_controldata命令并不一定是在data目录下，也不一定可以直接使用，因此可以用find命令（find / -name pg\_controldata）查找pg\_controldata位置，然后再使用命令的完整路径查看。

本次完整路径为：/usr/pgsql-11/bin/pg\_controldata，执行命令查看：

主机：

![20181207113959836.png][]

备机：

![20181207114010596.png][]

可以看到主机的cluster state是in production，备机的cluster state是in archive recovery。

## 2.字典表pg\_stat\_replication ##

在postgres用户下，登录数据库，然后使用下面查询语句：

select pid,application\_name,client\_addr,client\_port,state,sync\_state from pg\_stat\_replication;

在主机字典表中是能查到记录，备机中是查询不到的。如下：

主机：

![20181207114047787.png][]

备机：

![20181207114050530.png][]

## 3.进程信息识别 ##

使用命令ps -ef|grep postgres查看进程，可以通过进程信息识别主备机。如下：

主机：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70][]

备机：

![20181207114125868.png][]

## 4.通过pg函数 ##

在postgres用户下，登录数据库，然后使用下面查询语句：

select pg\_is\_in\_recovery();

主机是f，备机是t。

主机：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70 1][]

备机：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70 2][]

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

END

[20181207113703476.png]: /images/20220407/da2555521e4a40b9a0dd061f65ccb307.png
[2018120711373490.png]: /images/20220407/cae8e6ffd8e54b95aa07d8f9e4f43767.png
[20181207113803931.png]: /images/20220407/3b870f1140ca4868a0bddac26f7932de.png
[20181207113905150.png]: /images/20220407/90165535cefb43bc95e4e8b1b3ec4edf.png
[20181207113959836.png]: /images/20220407/596a19b4f7c4428ab7fe9bfdd413d23a.png
[20181207114010596.png]: /images/20220407/4054e55729344995a46b720a1c975080.png
[20181207114047787.png]: /images/20220407/8b46721113854a439794cbc279c280b7.png
[20181207114050530.png]: /images/20220407/96d493df44c8471b83f8df3ef6ca5836.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70]: /images/20220407/a13f67ea6d784a6d9e27303b53e0452f.png
[20181207114125868.png]: /images/20220407/f4ccb4e203be43308ddc5269a60b084b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70 1]: /images/20220407/8f75d1248d9240dd972f1f469d82e676.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTkxNzU2_size_16_color_FFFFFF_t_70 2]: /images/20220407/d6d2afca7e7a47c9b9a994a99b9f8a00.png