postgresql从库搭建--物理复制

1 复制类型

PostgreSQL支持物理复制（流复制）及逻辑复制2种。经过流复制技术，能够从实例级复制出一个与主库如出一辙的实例级的从库。流复制同步方式有同步、异步两种。

另外一种复制方式为逻辑复制，区别于物理复制的是物理复制是基于实例级的复制，只能复制整个PostgreSQL实例，而不能基于部分库及表。从PostgreSQL10开始，出现了基于表级别的复制，即逻辑复制。

2  流复制

主库安装及从库编译此处就省略了，直接进入主从复制的安装环节。

2.1 修改主库配置文件postgresql.conf

/* 除了基础参数,搭建备库至少须要配置以下参数 */ listen_address = '*' wal_level = replica archive_mode = on archive_command = 'cp %p /data/postgresql/archive/%f ' max_wal_senders= 10 wal_keep_segments=1024 hot_standby = on

参数简要说明：

listen_address： 按需设置,本次测试配置为全部主机都可以访问,生产环境能够按需配置网段或IP等 wal_level： 设置流复制模式至少设置为replica archive_mode: 本次启用归档 archive_command：WAL日志归档命令,生产环境能够将归档拷贝到对应目录或其余机器上,本次测试配置为归档到本机的另外一个目录下 max_wal_senders： 最大WAL发送进程数，此数量需大于等于从库个数且比max_connections小。 wal_keep_segments： pg_wal目录下保留WAL日志的个数,每一个WAL文件默认16M,为保障从库能在应用归档落后时依旧能追上主库，此值建议设置较大一点。 hot_standby： 此参数控制在恢复归档期间是否支持只读操做，设置为ON后从库为只读模式。

注意： 上述参数中有涉及归档日志的路径，需手动建立

mkdir -p  /data/postgresql/archive/

2.2  建立复制帐号

为了数据安全及便于权限控制，建立一个复制专用的数据库帐号

postgres=# create user repl  REPLICATION  LOGIN ENCRYPTED  PASSWORD 'repl123'; CREATE ROLE

2.3  修改配置文件pg_hba.conf

添加复制帐号的权限，因可能会主从切换，所以 主从机器的IP均添加。也能够设置网段，以便于后期添加从库。

# replication privilege. local replication all trust host replication all 127.0.0.1/32 trust host replication all ::1/128 trust host replication repl 192.168.56.33/24 md5 host replication repl 192.168.56.32/24 md5

2.4  备份数据

从机上在线备份主库数据，并将数据放在指定路径，此路径建议与主库路径一致。可使用pg_basebackup

命令在线热备份，具体命令以下：

pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p -X s -v -P -R -D /data/postgresql/data/ -l postgres32

pg_basebackup命令中的参数说明：

-h 指定链接的数据库的主机名或IP地址，这里就是主库的ip

-U 指定链接的用户名，此处是咱们刚才建立的专门负责流复制的repl用户

-F 指定生成备份的数据格式，支持p（plain原样输出）或者t（tar格式输出）

-X 表示备份开始后，启动另外一个流复制链接从主库接收WAL日志，有 f(fetch)和s (stream）两种方式，建议使用s方式

-P 表示显示数据文件、表空间传输的近似百分比 容许在备份过程当中实时的打印备份的进度

-v 表示启用verbose模式，命令执行过程当中会打印各阶段日志，建议启用

-R 表示会在备份结束后自动生成recovery.conf文件，这样也就避免了手动建立

-D 指定把备份写到哪一个目录，这里尤为要注意一点就是作基础备份以前从库的数据目录（/data/postgresql/data）目录须要手动清空

-l 表示指定个备份的标识，运行命令后能够看到进度提示

以上备份命令输出过程以下

[postgres@PG33 data]$ pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p   -X s  -v -P -R -D /data/postgresql/data/ -l postgres32 Password: pg_basebackup: initiating base backup, waiting for checkpoint to complete pg_basebackup: checkpoint completed pg_basebackup: write-ahead log start point: 0/2000028 on timeline 1 pg_basebackup: starting background WAL receiver pg_basebackup: created temporary replication slot "pg_basebackup_17737"
56041/56041 kB (100%), 1/1 tablespace pg_basebackup: write-ahead log end point: 0/20000F8 pg_basebackup: waiting for background process to finish streaming ... pg_basebackup: base backup completed

从以上日志信息看出pg_basebackup命令首先对数据库作一次checkpoint，以后基于时间点作一个全库基准备份，全备过程当中会拷贝$PGDATA数据文件和表空间文件到备库节点对应目录。

2.5 修改recovery.conf

以上备份命令中生成了recovery.conf 文件,所以简单修改便可。

standby_mode = 'on' primary_conninfo = 'user=repl password=repl123 host=192.168.56.32 port=5432 sslmode=disable sslcompression=0 target_session_attrs=any' ## 添加以下信息 recovery_target_timeline = 'latest'

参数说明：

standby_mode： 设置是否启用数据库为备库，若是设置成on，备库会不停地从主库上获取WAL日志流，直到获取主库上最新的WAL日志流 primary_conninfo：设置主库的链接信息，这里设置了主库IP、端口、用户名信息等，此处是明文密码，生产环境建议配置非明文密码，而是将密码配置在另外一个隐藏文件中 covery_target_timeline： 设置恢复的时间线（timeline），默认状况下是恢复到基准备份生成时的时间线，设置成latest表示从备份中恢复到最近的时间线，一般流复制环境设置此参数为latest，复杂的恢复场景可将此参数设置成其余值

2.6 启动从库

直接使用pg_ctl或配置服务启动从库便可。

pg_ctl  -D /data/postgresql/data/  -l pg33.log  start

若是启动过程当中出现以下错误

waiting for server to start....2019-09-26 10:40:54.327 CST [10267] FATAL: data directory "/data/postgresql/data" has invalid permissions

2019-09-26 10:40:54.327 CST [10267] DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).

stopped waiting

pg_ctl: could not start serve

Examine the log output.

则须要先修改权限，再启动便可

[postgres@PG33 data]$ chmod 0750 /data/postgresql/data/ [postgres@PG33 data]$ pg_ctl -D /data/postgresql/data/  -l pg33.log start waiting for server to start.... done server started

2.7 测试主从同步

在主库建立表并新增数据

[postgres@PG32 ~]$ psql psql (11.4) Type "help" for help. postgres=# create table test2(id int primary key, name varchar(20)); CREATE TABLE postgres=# insert into test2 values(1,'aaa'),(2,'abc'); INSERT 0 2

在从库查看

[postgres@PG33 data]$ psql psql (11.4) Type "help" for help. postgres=# select * from test2; id | name ----+------
  1 | aaa 2 | abc

数据已正常同步

2.8 查看复制状态

经过pg_stat_replication视图能够查看复制状态

postgres=# select pid ,usesysid,usename,client_addr,state,sync_state from pg_stat_replication; pid | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------
 25123 |    16797 | repl    | 192.168.56.33 | streaming | async (1 row)

以上查询结果sync_state字段值为async，表示主备数据复制使用异步方式；state值为streaming,表示流复制方式。

2.9 调整为同步复制

前面的步骤部署的为异步复制,如想配置为同步复制，则调整recovery.conf配置文件里的 synchronous_commit及synchronous_standby_names 后重启或reload便可。

synchronous_commit = remote_write synchronous_standby_names = '*'

以后再查看结果以下：

postgres=# select pid ,usesysid,usename,client_addr,state,sync_state from pg_stat_replication; pid | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------
 16265 |    16797 | repl    | 192.168.56.33 | streaming | sync (1 row)

此时状态已变为同步复制了。

注： synchronous_commit 有多种方式，在流复制模式下,主要设置状况以下：

remote_write： 当流复制主库提交事务时，需等待备库接收主库发送的WAL日志流并写入备节点操做系统缓存中，以后向客户端返回成功，这种状况下备库实例出现异常关闭时不会有已传送的WAL日志丢失风险，但备库操做系统异常宕机就有已传送的WAL丢失风险了，此时WAL可能还没彻底写入备节点WAL文件中，简单地说remote_write表示本地WAL已落盘，备库的WAL还在备库操做系统缓存中，也就是说只有一份持久化的WAL，这个选项带来的事务响应时间较低

on： 设置成on表示流复制主库提交事务时，需等待备库接收主库发送的WAL日志流并写入WAL文件，以后才向客户端返回成功，简单地说on表示本地WAL已落盘，备库的WAL也已落盘，也就是说有两份持久化的WAL，但备库此时尚未完成重作，这个选项带来的事务响应时间较高

remote_apply： 表示表示流复制主库提交事务时，需等待备库接收主库发送的WAL并写入WAL文件，同时备库已经完成重作，以后才向客户端返回成功，简单地说remote_apply表示本地WAL已落盘，备库WAL已落盘而且已完成重作，这个设置保证了拥有两份持久化的WAL，同时备库也完成了重作，这个选项带来的事务响应时间最高，即性能最差。

原文出处：https://www.cnblogs.com/gjc592/p/11586011.html