PostgreSQL流复制之一：原理+环境搭建（转发+整理）

资料来源：

原理：http://www.javashuo.com/article/p-ahhfshag-br.html

原理：http://www.javashuo.com/article/p-qulzikte-dp.html

主备库配置：https://blog.csdn.net/silenceray/article/details/54692908

postgres主备切换之文件触发方式：https://blog.csdn.net/m15217321304/article/details/88850146

参考：流复制延迟参数https://cloud.tencent.com/developer/article/1524114

 

1、PostgreSQL经过WAL日志构建高可靠性原理：

PostgrepSQL在数据目录的子目录pg_xlog子目录中维护了一个WAL日志文件，能够把WAL日志备份到另一台备份服务器，经过重作WAL日志的方式在备服务器上恢复数据（相似Oracle的redo日志）。

WAL日志复制到另一台备份服务器能够有两种方式：

一、 WAL日志文件复制

此种方式是写完一个WAL日志后，才把WAL日志文件拷贝到备份数据库中。这样一般备份会落后主库一个WAL日志文件，当主数据库发生故障时，主数据库的WAL文件并无填充完毕未传输（默认16MB）、或者时延等缘由致使WAL文件没有传输完毕，会致使被数据库可能存在必定的数据丢失。此种方式是postgreSQL9.0前版本主要提供的WAL日志复制机制。

采用此方式的WAL复制，须要：

• 主数据库的wal_level配置为archive或以上。
• PostgreSQL 9.1以后提供了一个很方便的工具pg_basebackup，使用完成一次基础备份到备数据库。
• 后续产生WAL文件，能够经过archive_command参数调度命令传输至备机。

二、流复制（Streaming Replication）

流复制是PostgreSQL 9.0以后才提供的新的传递WAL日志的方法。经过流复制，备库不断的从主库同步相应的数据，并在备库apply每一个WAL record，这里的流复制每次传输单位是WAL日志的record。它的好处是只要主库一产生日志，就会立刻传递到备库，同WAL日志文件相比有更低同步延迟。

同时PostgreSQL9.0以后提供了Hot Standby能力，备库在应用WAL record的同时也可以提供只读服务。

PostgreSQL的流复制最多支持1主8备、支持级联复制（主->备1，备1->备2）。

 

PostgreSQL流复制的核心部分由walsender，walreceiver和startup三个进程组成：

1. walreceiver启动后经过recovery.conf文件中的primary_conninfo参数信息连向主库，主库经过链接参数replication=true启动walsender进程。
2. walreceiver执行identify_system命令，获取主库systemid/timeline/xlogpos等信息，执行TIMELINE_HISTORY命令拉取history文件。
3. 执行wal_startstreaming开始启动流复制，经过walrcv_receive获取WAL日志，期间也会回应主库发过来的心跳信息（接收位点、flush位点、apply位点），向主库发送feedback信息（最老的事务id），避免vacuum删掉备库正在使用的记录。
4. 执行walrcv_endstreaming结束流复制，等待startup进程更新receiveStart和receiveStartTLI，一旦更新，从新进入2/3/4步骤。

 WAL流复制支持同步、异步方式：

•  异步流复制模式中，主库提交的事务不会等待备库接收WAL日志流并返回确认信息，所以异步流复制模式下主库与备库的数据版本上会存在必定的处理延迟，延迟的时间主要受主库压力、备库主机性能、网络带宽等影响，当正常状况下，主备的延迟一般在毫秒级的范围内，当主库宕机，这个延迟就主要受到故障发现与切换时间的影响而拉长，不过虽然如此，这些数据延迟的问题，能够从架构或相关自动化运维手段不断优化设置。
• 同步流复制模式中，要求主库把WAL日志写入磁盘，同时等待WAL日志记录复制到备库、而且WAL日志记录在任何一个备库写入磁盘后，才能向应用返回Commit结果。一旦全部备库故障，在主库的应用操做则会被挂起，因此此方式建议起码是1主2备。

 

2、搭建PostgreSQL数据库异步流复制环境

前提，数据库安装完毕。以主、备库以下规划为例：

主库地址/端口	10.10.10.1  /  5432
备库地址/端口	10.10.10.2  /  5432
备主流复制用户名/密码	u_standby  /  standby123
数据库用户名	postgre

PostgreSQL主备数据库的同步设置主要涉及以下文件：

1. pg_hba.conf                 postgresql 主库访问规则文件
2. postgresql.conf            postgresql 主库配置文件
3. recovery.conf               postgresql 备库访问主库配置文件
4. .pgpass                        postgresql 备库访问主库的密码文件

正常主备流复制状况下：

• 主库须要pg_hba.conf、postgresql.conf
• 备库须要recovery.conf、.pgpass

实际操做中，建议主、备库上都配置这四个文件，由于主、备库角色是随着倒换变动的。注：recovery.conf文件在备库上是recovery.conf，在主库上配置为recovery.done。

 

主库配置：

一、   配置postgresql.conf

wal_level = hot_standby  # minimal, replica, or logical   使得日志支持Streaming Replication

max_wal_senders = 2  # max number of walsender processes   这个设置了能够最多有几个流复制链接，几个并发的standby数据库就设置几个

wal_keep_segments = 256     设置流复制保留的最多的xlog数目，不要设置过小致使WAL日志尚未来得及传送到standby就被覆盖。一个WAL文件默认16M

hot_standby = on  # "on" allows queries during recovery  设置为备库时是否支持可读

logging_collector = on

log_directory = 'pg_log'

log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'

 

二、   配置pg_hba.conf

# TYPE  DATABASE    USER            ADDRESS              METHOD

host    all             all             127.0.0.1/32            trust

host    all             all             ::1/128                trust

host    replication      u_standby        10.10.10.0/32       trust

其中：

1） u_standby为在主库上建立的用于备库链接主库进行流复制的用户，此用户须要用户须要有REPLICATION权限和LOGIN权限。开户如：

create user u_standby SUPERUSER LOGIN password 'standby123';

2） 10.10.10.0/32为备库地址段+掩码；也可配置为具体的standby数据库地址+掩码，可配置多条。用于指定哪些地址的standby数据用哪一个用户名/密码到主库获取WAL日志数据。使用地址段格式，则地址段内的IP均可以无密码对此数据库进行访问，安全性可能会下降。所以，在生产环境中建议严格按照具体主机IP方式配置。

 

三、   （可选）配置recovery.done、.pgpass

同备库recovery.conf、.pgpass配置。recovery.conf中以下IP、端口、用户名要对应备库信息：

primary_conninfo = 'host=10.10.10.1 port=5432 user=u_standby'   备库链接主库地址、端口、用户名、密码

 

四、   配置完毕需重启数据库

pg_ctl restart -m fast

 

进行主库->备库基础备份：

一、   关闭备库，并清空数据

　　$pg_ctl stop -m fast

　　rm -rf /var/lib/pgsql/data/*

 二、   进行一次主库数据基本备份到备库

方式一（在主库操做）：

　　//开启备份功能，pg_start_backup() 函数会在主库上发起一个在线备份，命令执行后，将数据文件压缩拷贝到备份节点上:

　　$postgres=# select pg_start_backup('backup0001')

　　//将data目录下的数据远程拷贝到备库的data目录下

　　$scp -r /opt/pgsql/data/* 10.10.10.2:/opt/pgsql/data/

　　//关闭备份功能

　　$postgres=# select pg_stop_backup()

方式二（9.0版本后引入了pg_basebackup工具，在备库操做）：

　　pg_basebackup工具支持对主库发起一个基准备份，发起备份须要超级用户权限或REPLICATION权限，注意max_wal_senders参数配置，由于pg_basebackup工具将消耗至少一个WAL发送进程。

　　//以下IP为主库地址

　　pg_basebackup -h 10.10.10.1 -U u_standby -F p -x -P -R -D /var/lib/pgsql/9.5/data/ -1 rep_backup   //-R 表示会在备份结束后自动生成recovery.conf文件，这样就避免了手动建立。

 

备库配置：

一、   修改postgresql.conf

　　hot_standby = on  # "on" allows queries during recovery  设置为备库时是否支持可读

二、   配置recovery.conf

　　standby_mode = on

　　recovery_target_timeline = 'latest'

　　primary_conninfo = 'host=10.10.10.1 port=5432 user= u_standby password=standby123 '   本库为备库会，链接主库地址、端口、用户名、密码

三、   设置链接主库密码.pgpass

　　10.10.10.1: 5432:replication: u_standby:standby123  //备库都主库同步WAL日志使用

　　10.10.10.2: 5432:replication: u_standby:standby123  //倒换后，主库降备库，新备库使用

四、   配置完毕需重启数据库

　　pg_ctl start

 

结果检查：

一、   配置成功后，能够查看主、备库的walsender、walreceiver进程。

ps -ef | grep wal

主库：

postgres 6939 6935 0 23:16 ? 00:00:00 postgres: wal writer process

postgres 6983 6935 0 23:42 ? 00:00:00 postgres: wal sender process repuser 172.17.0.5(45910) streaming 0/3000140

备库：

postgres 26481 26479 0 23:42 ? 00:00:00 postgres: wal receiver process streaming 0/3000140

 

3、PostgreSQL的同步流复制

同步流复制配置内容相似异步流复制，差别点在于：

一、   主库的postgresql.conf文件，增长：

　　synchronous_standby_names = 'standby001'

       synchronous_standby_names是设置同步流复制的备库的主机名，该名称会在备库中的参数中指定。

二、   备库的recoveryt.conf文件

　　primary_conninfo = 'host=192.168.100.32 port=5866 user=tbing application_name=standby001'

       application_name参数就是设置的同步流复制备库的主机名，该参数值和主库的synchronous_standby_names的参数值一致。

三、   检查流复制状态

　　执行：

　　select * from pg_stat_replication

　　返回：

　　sync_state       | sync     表示同步流复制

　　sync_state       | async    表示异步流复制

 

4、PostgreSQL主备数据库切换

1、识别当前库主、备角色：

方式一：

　　postgres=# select pg_is_in_recovery();   结果是f则为主库，t为备库。

方式二：

　　pg_controldata 结果为cluster state是in production则为主库；结果为cluster state是in archive recovery则为备库。

方式三：

　　Select pid, application_name, client_addr, client_port, state, sync_state from pg_stat_replication  查询到结果为主库，查询不到结果为备库。

 

2、主备倒换

在PostgreSQL如主库出现异常时，备库如何激活。有2种方式：

方式一：使用pg_ctl promote来激活（PostgreSQL9.1后支持）

（1）关闭主库（模拟主库故障）：

　　$ pg_ctl stop -m fast

（2）在备库上执行pg_ctl promote命令激活备库

　　若是recovery.conf变成recovery.done表示备库已切换成主库

（3）原主库变备库

　　在新备库上建立recovery.conf、.pgpass文件，内容参考前文章节。启动新备库：

　　$ pg_ctl start

方式二：备库在recovery.conf文件中有个配置项trigger_file，是激活standby的触发文件，经过检测这个文件是否存在，存在则激活standby为master。

（1）在recovery.conf中配置触发器文件地址，修改本参数后须要重启备库：

　　recovery_target_timeline = 'latest'

　　standby_mode = on

　　primary_conninfo = 'host=10.10.10.1 port=5432 user= u_standby password=standby123 '

　　trigger_file = '/home/postgres/pg11/trigger'

（2）停掉原主库，会发现原备库变为可读写。

　　$ pg_ctl stop -m fast

（3）在备库建立trigger_file

　　$ touch /home/postgres/pg11/trigger

（4）发现原备库变为主库，方法参考“识别当前库主、备角色”。

 

3、故障的原主库，从新做为备库使用

在异步流复制（async）模式下，主库故障切换后，可能存在原主库故障时还有数据没来及的复制到备库，这些数据将丢失。（注：PostgreSQL的Streaming Replication是以事务为单位，即便数据未同步完毕，也不会出现备库某个事务只恢复一半的状况，所以事务一致性仍是能够保证的。）

此种状况下，原主库的最后一个事务时间戳比复制到原备库（新主库）的事务时间戳更新。好比：倒换前最后几个事务是100/101/102，故障前流复制到100事务，则故障切换后，原主库中最新一个事务是102，原备库（新主库）中复制的最后一个事务是100，后续新主库（原备库）将在100的基础上，进行新的事务操做。原主库数据、新主库数据出现分叉点。所以，若是但愿原主库恢复服务后做为新备库运行，则须要：

方式一：删库，重搭新备库（详细参考前文备库配置过程）

　　一、 关闭库，并清空数据（清楚数据便可，不须要重装数据库）

　　　　pg_ctl stop -m fast

　　　　rm -rf /var/lib/pgsql/data/*

　　二、 新备库进行数据基本备份

　　　　pg_basebackup  ….

　　三、 启动新备库

　　　　pg_ctl start

方式二：采用pg_rewind降级为备库，继续服务

若是你的数据库到达TB级别，采用方式一的全量数据基础备份将花费数个小时。为了解决此问题，PostgreSQL9.5引入了pg_rewind功能。原主库（新备库）能够经过pg_rewind操做实现故障时间线的回退。回退后再重新主库中获取最新的后续数据。此时，原主库的数据无须进行从新全量初始化就能够继续进行Streaming Replication，并做为新的Slave使用。

详见pg_rewind使用说明。