Postgres11.4pg_basebackupP

    报错截图：

pg_basebackup: could not get write-ahead log end position from server: ERROR: could not open file "./.postgresql.conf.swn": Permission denied

成都创新互联公司服务项目包括灵寿网站建设、灵寿网站制作、灵寿网页制作以及灵寿网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，灵寿网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到灵寿省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

一、环境准备：【生产环境】
1、
Master   PG host IP :172.17.16.16                  host name：hkzbxdb1
Standby PG host IP:172.17.16.18                   host name：hkzbxdb2

2、PG Cluster 理想环境是版本一致，所以主备库版本如下：

3、停止Firewalls防火墙【主备机】、初始化PG数据库【主备机】、iptables规则配置【假如你用到/主备】;
4、Master host 配置：pg_hba.conf 和postgresql.conf；创建replication role账户repl；

文件路径：/var/lib/pgsql/11/data/pg_hba.conf
配置pg_hba.conf
keepalives 参数非必须,主要是监控TCP连接状态使用;

/var/lib/pgsql/11/data/postgresql.conf 

配置流复制功能WAL归档这部分可以不用配置，当然也可以采用"流复制+WAL连续归档"的容灾方案;

这几个replication参数比较重要，可以根据自己的需求调整参数值，更多详细信息建议参考官网文档https://www.postgresql.org/docs/11/warm-standby.html：

备注："WAL知识点参考信息，来自PG官网"

至此,环境准备完毕。

二、理论准备
       启动流复制
       在Streaming Replication中，三种进程协同工作。甲walsender主服务器上的过程发送WAL数据到备用服务器; 然后，备用服务器上的walreceiver和启动进程接收并重放这些数据。walsender和walreceiver使用单个TCP连接进行通信。
       流复制的启动顺序图：

（1）启动主服务器和备用服务器。
（2）备用服务器启动启动过程。
（3）备用服务器启动walreceiver进程。
（4）walreceiver向主服务器发送连接请求。如果主服务器未运行，则walreceiver会定期发送这些请求。
（5）当主服务器收到连接请求时，它启动walsender进程并在walsender和walreceiver之间建立TCP连接。
（6）walreceiver发送备用数据库集群的最新LSN。一般而言，这一阶段被称为信息技术领域的握手。
（7）如果备用的最新LSN小于主要的最新LSN（备用的LSN <主要的LSN），则walsender将WAL数据从前LSN发送到后一个LSN。这样的WAL数据由存储在主要的pg_xlog子目录（版本10或更高版本，pg_wal子目录）中的WAL段提供。然后，备用服务器重放接收的WAL数据。在此阶段，备用数据库赶上主数据库，因此称为追赶。
（8）流复制开始起作用。
每个walsender进程保持适合连接的walreceiver或任何应用程序的工作阶段的状态（请注意，它不是连接到walsender的walreceiver或应用程序的状态。）以下是它的可能状态：

启动 - 从启动walsender到握手结束。见图。（5） - （6）。
追赶 - 在追赶阶段。见图（7）。
流 - 虽然流复制正在运行。见图（8）。
backup - 在为pg_basebackup实用程序等备份工具发送整个数据库集群的文件期间。
该pg_stat_replication视图显示所有正在运行的walsenders的状态。一个例子如下所示：  

三、"ERROR:  could not open file "./.postgresql.conf.swn": Permission denied"，解决思路;
    1、根据报错提示查找文件及路径；
          # locate .postgresql.conf.swn  
                /var/lib/pgsql/11/data/.postgresql.conf.swn
    2、根据搜索结果，查看/var/lib/pgsql/11/data/l路径下的所有文件【含隐藏】及权限;
          # ls -la /var/lib/pgsql/11/data/
                正确的权限如下截图,可以对比看，如果不匹配修改对应红色框内的权限

    3、权限修改命令
            # chmod -R 700           /var/lib/pgsql/11/data                             变更data及子目录文件权限为RWX
             # chgrp   -R postgres   /var/lib/pgsql/11/data                             变更data及子目录文件所属组为postgres
             # chown  -R postgres  /var/lib/pgsql/11/data                              变更data及子目录文件所有者为postgres       
 4、以上是针对MAster Host修改；需要注意的是修改完毕之后记得重启PG服务器或系统;
 5、在Standby Host主机上登录postgres账户,然后执行pg_basebackup命令从主库异步复制PG数据资料；
             #su - postgres                                                                         从ROOT或其他账户切换到postgres账户
             # pg_basebackup -D $PGDATA -Fp -Xs -v -P -h 172.17.16.16 -p 5432 -U repl
             "备注：A.至此，正常的情况是，你可以在/var/lib/pgsql/11目录下看到data文件变大，且data下的文件和主库保持一致；
                         B.如果，你在执行pg_basebackup 命令后，提示：“/var/lib/pgsql/11/data”存在且不为空，那么你需要执行C,然后重新执行pg_basebackup命令.
                         C.执行，备份原data并新建data，Command：
                                    #mv /var/lib/pgsql/11/data /var/lib/pgsql/11/data_back
                                    #mkdir /var/lib/pgsql/11/data
                                    "

    6、备库重启PG服务,然后对比主从库信息会发现此时两边数据库信息是一致的，"问题解决".