postgresql10.0逻辑复制原理及最佳实践.docx

PostgreSQL 逻辑复制原理与最佳实践
本文章来自于阿里云云栖社区
摘要： 标签 PostgreSQL , logical replication , 逻辑复制 , 最佳实践 背景 PostgreSQL ，备库可以作为只读库打开，提供给用户使用。
标签
PostgreSQL , logical replication , 逻辑复制 , 最佳实践
背景
PostgreSQL ，备库可以作为只读库打开，提供给用户使用。
物理复制的好处
1. 物理层面完全一致，这是许多商业数据库的惯用手段。例如Oracle的DG。
2. 延迟低，事务执行过程中产生REDO record，实时的在备库apply，事务结束时，备库立马能见到数据。不论事务多大，都一样。
3. 物理复制的一致性、可靠性达到了金融级的需求，不必担心数据逻辑层面不一致。
但是物理复制要求主备块级完全一致，所以有一些无法覆盖的应用场景，例如备库不仅要只读，还要可写。又比如备库不需要完全和主库一致，只需要复制部分数据，或者备库要从多个数据源复制数据，等等。
物理复制无法覆盖的场景
1. 数据库实例的部分，例如单个数据库或者某些表的复制需求。
例如某个游戏业务，账号体系是一套数据库，如果全国各地有多个接入点，全部都连到中心数据库进行认证可能不太科学。那么就希望将登陆需要用到的一些数据表同步到多个数据中心，而不是整个数据库实例。
2. 数据到达subcriber后，针对不同数据，设置触发器。
3. 将多个数据库实例的数据，同步到一个目标数据库。
例如多个数据库同步到一个大的数据仓库。
4. 在不同的数据库版本之间，复制数据
5. 将一个数据库实例的不同数据，复制到不同的目标库。
例如省级数据库的数据，按地区划分，分别复制到不同的地区。
6. 在多个数据库实例之间，共享部分数据。
例如某个业务按用户ID哈希，拆分成了8个数据库，但是有些小的维度表，需要在多个数据库之间共享。
以上场景是物理复制无法覆盖的。
逻辑复制应运而生，实际上，，PostgreSQL就支持逻辑复制了，只是一直没有将其引入内核。
，将会在内核层面支持基于REDO流的逻辑复制。
另一个好消息是，你可以针对同一个数据库实例，同时使用逻辑复制和物理复制，因为他们都是基于REDO的。
下面我们来看一下逻辑复制的概念、架构、监控、安全、最佳实践。
逻辑复制概念
PostgreSQL 逻辑复制是事务级别的复制，引入了几个概念
publication - 发布者
发布者指数据上游节点，你需要将哪些表发布出去？
上游节点需要配置这些东西
1. 需要将数据库的REDO的wal_level配置为logical。
2. 需要发布逻辑复制的表，必须配置表的REPLICA IDENTITY，即如何标示老的记录。
被复制的表，建议有PK约束。
alter table table_name
REPLICA IDENTITY { DEFAULT | USING INDEX index_name | FULL | NOTHING }
解释
REPLICA IDENTITY
This form changes the information which is written to the write-ahead log to identify rows which are updated or deleted.
This option has no effect except when logical replication is in use.
记录PK列的
1. DEFAULT (the default for non-system tables) records the old values of the columns of the primary key, if any.
记录指定索引列（索引的所有列须是not null列，其实和PK一样，但是某些情况下，你可以选一个比PK更小的UK）
2. USING INDEX records the old values of the columns covered by the named index, which must be unique, not partial, not deferrable, and include only columns marked NOT