2001年V7.1引入WAL日志。
2006年V8.2引入warm standby(也叫warm standby日志传输),引入了持续归档和持续recover的概念。
在standby端,会持续不断的执行recover过程。这也意味着,即使standby server是在线的,但是不能接收任何连接。这属于异步复制,所以有可能会丢失数据。
2010年V9.0,引入了流复制和hot standby。增加了两个postmaster进程:walsender、walreceiver。也是会持续不断地归档和recover过程,但是该过程是通过后台进程实现的。这样,standby可以提供只读查询。同时增加了两个监控复制的函数:pg_last_xlog_receive_location和pg_last_xlog_replay_location。不过复制仍然是异步的。
2011年V9.1引入同步流复制。
可以对单个事务块切换成异步复制:SET LOCAL synchronous_replication TO OFF
1.创建用户并授权
在主库创建一个复制用户并授予replication角色:
CREATE USER rep_user REPLICATION;
2.主库配置pg_hba.conf文件
# TYPE DATABASE USER ADDRESS METHOD host replication rep_user <ip address range> <auth_method>
3.主库重新加载pg_hba.conf文件
$ pg_ctl reload 或 postgres# select pg_reload_conf();
4.备份主库
使用pg_basebackup备份,备份时加上参数-R,这样会把备份信息也写入到新的数据目录
5.启动standby
复制冲突仅发生在备库上。主上没有冲突。当walreceiver进程启动 WAL重做操作时,冲突发生在从库。WAL重做操作需要独占锁,而独占锁可能由任何长时间运行的查询或事务持有。重做操作一直等到超时。这些终止被归类为复制冲突。这些冲突的性质可能非常不同。
PostgreSQL有pg_stat_database_conflicts 视图,它告诉我们什么类型的冲突以及发生了多少。
我们可忽略pg_stat_database视图,因为它只有一个BigInt字段来维护冲突计数。它并没有真正提供对这些冲突性质的任何见解。
常见的冲突有:
·表空间冲突,比如temp_tablespaces被删除了,临时表空间用于临时表、索引、排序操作等。
·锁冲突,比如要查询的表,主库正在alter操作
·快照冲突,比如从库上要访问的行,在主库上已经被vacuum
·bufferpin冲突,这些主要是由hot chain修剪或版本14中btree索引的版本duplicate churn引起的,因为它需要在页面上进行排他锁。这些类型的冲突并不常见。
·死锁冲突
·其它冲突