PostgreSQL复制技术的演变

WAL日志

2001年V7.1引入WAL日志。

warm standby(即日志传输)

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引起的，因为它需要在页面上进行排他锁。这些类型的冲突并不常见。

·死锁冲突

·其它冲突