标签：主库 WAL PostgreSQL standby 复制 冲突 pg
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引起的，因为它需要在页面上进行排他锁。这些类型的冲突并不常见。
·死锁冲突
·其它冲突
标签：主库,WAL,PostgreSQL,standby,复制,冲突,pg 来源： https://www.cnblogs.com/abclife/p/16459943.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。