PostgreSQL 本身是支持流式复制的，而大部分数据库都支持逻辑复制的方式，流式复制稳定高效，但缺点是不灵活，而逻辑复制的优点就在于此。

逻辑的复制的优点

1 可以进行数据的过滤

2 可以进行数据的融合

3 部分数据的复制

逻辑复制使用发布/订阅模型，因此我们在上游(或发布者)创建发布，在下游(或订阅者)创建订阅。

通过一个例子我们来进行实际的逻辑复制的理解

1 先在原库上创建一张表

2 创建发布publication, 在创建复制的过程是在当前的数据库中建立复制通道发布的本质是一组表

create publication repl_test for all tables;

3 然后我们在目的库建立相同的表，或者近似的表（近似表的意思是和源表有的字段都必须有）

create table repl_table1 (id serial constraint primarykey primary key,name varchar(20),create_time timestamp);

4 创建相关的replication 对源与目的

create subscription repl_test connection 'user=repl password=password host=10.50.132.195 port=5432 dbname=repl_test' publication repl_test;

这里有几个注意的点

1 两个物理的数据库需要能进行联通，并且有一个账号可以进行数据的访问，一般来说权限需要使用 superuser

2 在复制的时候针对的是源的数据库，并且要写清楚对于源数据库的中已经建立的publication.

3 相关的表之间的连接就建立好了。

我们可以在主库插入数据，再在从库进行数据的校验

到此我估计大家的问题已经一大堆了

我先替大家提几个问题

1  如果我在从库的表插入记录可以吗？如果插入的记录和主库有冲突怎么办？

2   怎么监控数据的复制

3   如果我在主库建立表，不在从库建立表，会怎样

4   如果我在从库修改数据，会出现什么情况

1  如果我们在从库插入记录并且数据和主库有冲突会如何

实验步骤：

1 在源数据库插入数据

2 查看目的数据库的表是否已经有了数据

3 我们在从库上插入数据

4 然后再在主库上继续插入数据

主库

从库

我看可以看到 主库的数据插入到从库并没有被影响，主要是因为并未产生主键的冲突

然后我们继续查看在从库插入数据，占用主库下一次要插入占用的主键，再在主库继续插入数据。

主库

从库

我看可以看到主库的表和从库的表已经不一致了。

问题是我们怎么办？

我尝试删除从库的与主库冲突的数据，看看会怎样？

我们可以看到，从库的数据继续接受主库的数据

这点是比较好的，因为部分数据库在遇到这样的问题时复制就停止了，就算是修复的数据后，也不能继续进行，可能还需要整体的复制修复等等

2  怎么监控复制的问题

监控的问题主要分为两个部分

1 publication

2 subscription

3 在主库建表后，进行数据的插入，但是在从库上并未建立相关的表，造成的结果就是复制停止了。

通过查看主库和从库的 pg_stat_replication  和  pg_stat_subscription

发现已经没有相关的数据

4 直接在从库的错误日志中可以看到明显的错误提示

此时复制已经中断

总结：数据复制中，如果选择复制所有表，在添加新表后，需要在从库也建立相关的表结构。如果不做则表复制就直接错误并不在进行工作。

如何恢复，直接在从库上建立表的结构后，数据就开始复制 ，并且复制自动开始，复制恢复。

4 在从库进行数据的修改

这里就不在截图，直接将结果展现

如果你对从库的表的数据进行UPDATE 非主键的情况下，其实对于复制的影响并不是很大，但不建议这样做。