数据库主从备份
PG SQL
备份
首先，需要修改postgresql.conf文件的几个参数修改如下：
wal_level = ‘replica’
archive_mode = ‘on’
### %p会被要被归档的文件路径所替代，而%f只会被文件名所替代。如果你需要在命令中嵌入一个真正的%字符，可以使用%%
archive_command = 'copy /y "%p" "D:\\archive\\%f"'
archive_mode = ‘on’
archive_command = ‘copy /y ”%p” ”D:\archive\%f”’
之后需要重启数据库使配置生效。
连接到服务器执行命令：
-- 开始一次非排他的备份 pg_start_backup(label text [, fast boolean [, exclusive boolean ]])
select pg_start_backup('backup_label', false, false);
-- 结束一次非排他的备份
select * from pg_stop_backup(false);
主从
PostgreSQL数据库本身提供三种HA模式：
- 基于日志文件的复制
Master库向Standby库异步传输数据库的WAL日志，Standby解析日志并把日志中的操作重新执行，以实现replication功能。缺点在于Master库必须等待每个WAL日志填充完整后才能发给Standby，如果在填充WAL日志的过程中Master库宕机，未发送的日志内的事务操作会全部丢失。
- 异步流复制模式
Master库以流模式向Standby库异步传输数据库的WAL日志，Standby解析收到的内容并把其中的操作重新执行，以实现replication功能。这种方式和“基于日志文件的复制”相比不需要等待整个WAL日志填充完毕，大大降低了丢失数据的风险，但在Master库事务提交后，Standby库等待流数据的时刻发生Master宕机，会导致丢失最后一个事务的数据。同时备库可以配置成HOT Standby，可以向外提供查询服务，供分担负载。
- 流同步复制模式（Synchronous Replication）
顾名思义，是流复制模式的同步版本。向Master库发出commit命令后，该命令会被阻塞，等待对应的WAL日志流在所有被配置为同步节点的数据库上提交后，才会真正提交。因此只有Master库和Standby库同时宕机才会丢数据。多层事务嵌套时，子事务不受此保护，只有最上层事务受此保护。纯读操作和回滚不受此影响。同时备库可以配置成HOT Standby，可以向外提供查询服务，供分担负载。采用这种模式的性能损耗依据网络情况和系统繁忙程度而定，网络越差越繁忙的系统性能损耗越严重。
主服务器
创建备份账号：
create role repl login replication encrypted password '123456';
修改postgresql.conf并重启
wal_level= logical
max_wal_senders = 32 # 这个设置了可以最多有几个流复制连接，不少于从服务器数量
wal_keep_segments = 256 ＃ 设置流复制保留的最多的xlog数目
wal_sender_timeout = 60s ＃ 设置流复制主机发送数据的超时时间
max_connections = 100 # 这个设置要注意下，从库的max_connections必须要大于主库的
archive_mode = on
# 归档logfile segment
archive_command = 'test ! -f /pg_archive/%f && cp %p /pg_archive/%f'
synchronous_standby_names = '' #standby application name, in recover.conf 如果Standby库无响应Master库会被hung住，多个使用逗号分隔，异步使用空。
hot_standby=on
增加从服务器权限
vim /var/lib/pgsql/9.6/data/pg_hba.conf
# 添加如下内容
host replication repl 10.0.1.0/24 md5
host all repl 10.0.1.1/24 trust
从服务器
执行pg_basebackup
pg_basebackup -F p –progress -D /data/pgsql/data2 -h 10.12.12.10 -p 5432 -U replica –password
/data/pgsql/data2这个目录是空的