结构图以下:sql
Postgresql早在9.0版本开始支持物理复制,也称为流复制,经过从实例级复制出一个与主库如出一辙的备库。流复制同步方式有同步,异步两种,若是主节点和备节点不是很忙,一般异步模式下备库和主库的延迟时间可以控制在毫秒级。物理复制只能复制整个实例。数据库
逻辑复制也成为选择性复制,能够作到基于表级别的复制,选择须要逻辑复制的表,而不是复制实例上的全部数据库的表,10版本不支持内置的逻辑复制,一般使用第三方逻辑复制。架构
WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,可是二者本质不一样,流复制是基于WAL物理复制,逻辑复制是基于WAL逻辑解析,将WAL解析成一种清晰,易于理解的格式。oracle
流复制和逻辑复制主要有如下差别:app
核心原理是主库将预写入日志WAL日志发给备库,备库接收到WAL日志后进行重作。异步
逻辑复制核心是基于WAL,逻辑复制会根据预先设置好的规则解析WAL日志,将二进制文件解析成必定格式的逻辑变化信息(有点像oracle的物理备库和逻辑备库)。工具
环境状况:post
主机性能 |
主机名测试 |
IP |
操做系统 |
Postgresql版本 |
master |
10pg1 |
192.168.10.41 |
Centos6.9 |
PostgreSQL 10.8 |
slave |
10pg2 |
192.168.10.51 |
Centos6.9 |
PostgreSQL 10.8 |
这种环境的部署包括两种方式:
① 数据文件拷贝的方式
② pg_basebackup方式部署
本次将介绍pg_basebackup方式部署。
1. 两台都要安装postgresql
2. 主库建立建立Replication用户(如下都是主库操做)
CREATE ROLE rep login replication password 'rep';
修改master的pg_hba.conf文件:
修改Master库数据库配置(postgresql.conf)
要使用流复制,必定要把wal_level = hot_standby设置成hot_standby,其中要开启归档模式
wal_level = hot_standby # 这个是设置主为wal的主机
max_wal_senders = 5 # 这个设置了能够最多有几个流复制链接
wal_keep_segments = 128 # 设置流复制保留的最多的xlog数目
wal_sender_timeout = 60s # 设置流复制主机发送数据的超时时间
max_connections = 100 # 这个设置要注意下,从库的max_connections必需要大于主库的
配置完后重启主库。
3. 如下都是备库操做
修改master的pg_hba.conf文件:
host all all 192.168.10.0/24 md5
host replication rep 192.168.10.41/24 md5
host replication rep 192.168.10.51/24 md5
使用pg_basebackup建备库
pg_basebackup -h 192.168.10.41 -Urep -Ft -Pv -Xf -z -Z5 -p 5432 -D /backup/20190629/
中止备库进行恢复操做:
cd /pgsql/
mv pg_data/ pg_databak
mkdir -p /pgsql/pg_data
cd /pgsql/
chmod 700 pg_data
chown -R postgres:postgres /pgsql/
tar -zxvf /backup/20190629/base.tar.gz -C /pgsql/pg_data/
拷贝主库的recovery.conf文件到备库(主库执行)
scp /usr/local/pgsql/share/recovery.conf.sample 192.168.10.51:/pgsql/pg_data/recovery.conf
备库修改recovery.conf
standby_mode=on
primary_conninfo = 'user=rep password=rep host=192.168.10.41 port=5432'
recovery_target_timeline = 'latest'
启动备库后,会报错,接下来修改postgresql.conf
vi postgresql.conf
max_connections = 200 # 通常查多于写的应用从库的最大链接数要比较大
hot_standby = on # 说明这台机器不只仅是用于数据归档,也用于数据查询
max_standby_streaming_delay = 30s # 数据流备份的最大延迟时间
wal_receiver_status_interval = 10s # 多久向主报告一次从的状态,固然从每次数据复制都会向主报告状态,这里只是设置最长的间隔时间
hot_standby_feedback = on # 若是有错误的数据复制,是否向主进行反馈
测试:
主库操做:
备库:
同步正常。
备库只能执行查询,与Oracle dg相似,且slave停掉后,主库可以正常的运行,wal日志不能传向远端。
启动后,把主库的归档日志传向备库,备库继续应用日志(不像ORACLE须要手动应用日志)。
备库停库后主库delete操做:
备库启动后,主库传完归档日志操做:
主备库一致性查询操做:
主备一致,且主库执行同步查询:
select pid,state, client_addr,sync_priority,sync_state from pg_stat_replication;
select * from pg_stat_replication ;
检查数据库主从复制进度:
查看流复制的信息可使用主库上的视图
select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
查看备库落后主库多少字节
select pg_xlog_location_diff(pg_current_xlog_location(),replay_location)/1024/1024 as MB from pg_stat_replication;
select pg_xlog_location_diff(pg_current_xlog_location(),replay_location)/1024/1024/1024 as GB from pg_stat_replication;
级联复制
select pg_xlog_location_diff(pg_last_xlog_replay_location(),replay_location)/1024/1024/1024 as GB from pg_stat_replication;
查看备库由于冲突而被取消的SQL:
select * from pg_stat_database_conflicts;
显示备库详细信息:pg_controldata
备库wal 日志清理:
因为个人备库WAL日志存在/pgsql/pg_data/pg_wal目录。
vi /pgsql/pg_data/recovery.conf
archive_cleanup_command = 'pg_archivecleanup /pgsql/pg_data/pg_wal %r'
异步流复制能够转换成同步流复制。
主库配置postgresql.conf:
synchronous_commit = on
synchronous_standby_names = 'standby1' --备库设置节点别名
备库配置recovery.conf
primary_conninfo = 'application_name=standby1 user=rep password=rep host=192.168.10.41 port=5432 sslmode=disable sslcompression=1'
recovery_target_timeline = 'latest'
配置完后重启主备库。
查看同步方式:
select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
同步复制环境中,因为主库提交事务至少须要一个备库接收WAL,并返回确认信息后主库才向客户端返回成功,一方面保证了数据的完整性,另外一方面对于一主一备的同步环境变现的陷阱是,若是备库宕机,主库上的写操做即处于等待状态(这点跟ORACLE不同,Oracle 有gap,主库会向备库传送归档),读操做不影响,须要手动的把归档同步到备库,因此生产上,建议使用异步方式(一主一从架构)。
查看延迟(wal延迟时间衡量):
select * from pg_stat_replication ;
经过WAL日志应用延迟量衡量:
select
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)) as sent_delay,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn)) as write_delay,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), flush_lsn)) as flush_delay,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) as replay_delay
from pg_stat_replication;
select * from pg_stat_wal_receiver;
查看恢复进程是否处于恢复模式:
SELECT PG_IS_IN_RECOVERY();
显示备库最近接收的WAL日志位置:
select pg_last_wal_receive_lsn();
显示备库最近应用的WAL日志位置:
select pg_last_wal_replay_lsn();
显示备库最近事务的应用时间:
select pg_last_xact_replay_timestamp();
显示主库WAL当前写入位置:
select pg_current_wal_lsn();
建议主备库事先作个快照
首先判断主备库
ps -ef | grep "wal"
能够查看有
主
备:
或者查看如下SQL 有内容的为主库,没有内容的为从库。
select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
或者查看
select pg_is_in_recovery(); -- t为备 f为主库
pg_controldata 备库Database cluster state参数 为 in archive recovery模式;主库为in production 模式。
9.0以前切换须要文件出发方式,9.1开始,支持pg_ctlpromote出发方式,相比文件出发方式更方便。
Promote命令发出后,运行中的备库将中止恢复模式,并切换成读写模式的主库。步骤以下:
1.关闭主库,建议使用-m fast模式关闭。
pg_ctl stop -D /pgsql/pg_data/ -m fast
2.备库执行命令激活备库
pg_ctl promote -D /pgsql/pg_data
查看备库原备库recovery.conf 变成recovery.done,表示切换完成(测试已切换完成)
查看新主库:
测试新主库能够进行读写操做,切换成功。
因为考录到主库宕机以后不可用,并无作主备互相切换,只作备库升为主库操做。
Pg_rewind 是pgsql一个很是好的数据同步工具,若是主备互相切换的时候忘记关闭主库,除了从新搭建备库外,就会用到提供的pg_rewind工具。
pg_rewind:
主备库设置参数 wal_log_hints = on ,若是数据库初始化的时候是 --data-checksums选项能够不用设置此参数,因为--data-checksums会在数据块上进行检测,发现I/O错误,开启后后性能损失。
设置号wal_log_hints = on 后,进行重启生效。
① 激活备库
参数设置好后,备库提高为主库
pg_ctl promote -D /pgsql/pg_data
提高成功。
② 主库转换为备库
关闭原来的主库。
pg_ctl stop -D /pgsql/pg_data/ -m fast
使用pg_rewind 工具增量同步10pg2到10pg1的数据。
pg_rewind --target-pgdata=/pgsql/pg_data/ --source-server='host=192.168.10.51 port=5432 user=postgres password=postgres dbname=postgres' -P
mv recovery.done recovery.conf
vi recovery.conf
把主库信息修改一下
vi postgresql.conf
修改监听地址。
后启动成功后
pg_ctl start -D /pgsql/pg_data/
查看日志有报错
把51的日志cp到41 wal日志目录(因为我主库有新的数据生成)
新备库立马同步正常。
延迟设置:
若是备库不须要实时同步,设置此参数:
vi recovery.conf
recovery_min_apply_delay = 30s
默认是0 毫秒,支持ms,s,min,h,d(毫秒,秒,分钟,小时,天),注意参数须要重启生效;
若是设置时间过大,须要注意wal目录的空间是否足够大。