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.创建用户并授权
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引起的，因为它需要在页面上进行排他锁。这些类型的冲突并不常见。
·死锁冲突
·其它冲突
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
