原副标题：PostgreSQL方式论拷贝NSA
在互联网化黄金时代的那时，他们都尊重统计数据会缔造商业价值。为的是最小化统计数据的商业价值，他们时不时的创建着统计数据北迁的管线，从等价到直链，从亲密关系型到非亲密关系型，从云下到云上，从数仓到统计数据湖，企图在各式各样情景发掘统计数据的商业价值。而在这密布的统计互联网服务中，方式论拷贝承担着极为重要的配角。
让他们将视点从繁杂的互联网拉回当中的两个西北侧，从PostgreSQL起程，对其方式论拷贝的基本原理展开NSA。
基本概念与原理
方式论拷贝，是如前所述拷贝标记拷贝统计数据或其变动的一类方式。区别于力学拷贝对网页操作方式的叙述，方式论拷贝是对外交事务及统计数据位元的一类叙述。
图-WAL统计报文实例
总的上看，力学拷贝的统计报文是对tablespace/database/filenode文档的块展开操作方式，而方式论拷贝的文本是对位元展开叙述。
接下去他们上看方式论拷贝中的两个基本概念：
*拷贝槽
拷贝槽是历史记录拷贝状况的几组重要信息。虽然WAL（预写式笔记）文档在统计数据或者说落盘后会删掉，拷贝槽会避免过早地清扫方式论拷贝导出所需的WAL笔记。在方式论拷贝中，每一连接埠从一般而言统计资料库INS13ZD数据传输一连串更动，创建拷贝槽须要选定其采用的输入应用程序，与此同时创建拷贝槽时能提供更多两个镜像。
*输入应用程序
输入应用程序负责将WAL笔记解码为可读的格式，常用的应用程序用test_decoding(多用来测试)，pgoutput（默认采用），wal2json（输入为json）。PostgreSQL定义了一连串回调函数，他们除了采用上述应用程序，可以通过回调函数编写自己的输入应用程序。
图-拷贝槽统计报文
*复制协议与消息
psql “dbname=postgres replication=database”
开启INS13ZD数据传输WAL
START_REPLICATION[ SLOT slot_name] [ PHYSICAL] XXX/XXX[ TIMELINE tli]
无论是力学拷贝，还是方式论拷贝，采用PostgreSQL的发布订阅或者pg_basebackup搭建流拷贝，都是通过拷贝协议与定义的消息展开交互（力学拷贝和方式论拷贝统计报文文本不同）
图- WAL统计数据流消息类型
图-方式论拷贝中的XLogData消息
*工作流程
当他们了解了基本概念之后，上看一下整个导出的工作流程。虽然WAL文档里两个外交事务的文本并不一定是连续的，所以须要通过Reorder后放在buffer中，根据外交事务ID组织成一条消息，COMMIT后发送给输入应用程序，输入应用程序导出后将消息流发送给目标端。
图-方式论导出工作流程
问题与演进
当他们掌握了方式论拷贝的基本原理，计划采用其构建他们的统计数据北迁应用之前，他们还有一些问题并没有解决。让他们来一起看看是什么亟待解决的问题，以及他们如何展开处理。
* 问题一：Failover slot
为的是高可用性，统计资料库至少会存在一主一备的架构，当主库故障展开高可用切换时，备库却没有相应的拷贝槽重要信息，也就是缺少failover slot。这是虽然保存slot重要信息的力学文档，未同步至备库。那么他们如何手动创建两个faliover slot呢？
1. 主库创建拷贝槽，检查备库wal文档是否连续
2. 拷贝包含slot重要信息的力学文档至备库，在pg_repslot目录下
3. 备库重启，重启后才可以看到拷贝槽重要信息，原因是读取slot力学文档的函数StartupReplicationSlots只会在postmaster进程启动时调用。
4. 定期查询主库slot状况，采用pg_replication_slot_advance函数推进备库拷贝槽
自此，他们在备库上也有了相应的重要信息，手动实现了failover slot。PostgreSQL生态中著名的高可用软件Patroni也是以这种方式展开了实现，区别只是在Patroni查询主库slot状况时将重要信息写入了DCS中，备库拿到DCS中的位点信息展开推进。
* 问题二：DDL同步
原生的方式论拷贝不支持导出DDL语句，他们可以采用事件触发器来展开处理。
1. 采用事件触发器感知表结构变更，历史记录到DDL_RECORD表中，并将该表通过方式论拷贝展开发布。
图-事件触发器实现DDL同步
* 问题三：双向同步
当统计数据北迁涉及双向同步的管线时，例如想实现双主双写，对统计资料库同一对象展开操作方式，就会出现WAL循环。
图-相同表双向同步导致统计数据循环
部分DTS应用为的是解决这个问题会创建辅助表，在外交事务中先对辅助表展开操作方式，通过导出到对辅助表的操作方式而得知该历史记录是有DTS应用插入，从而过滤该外交事务，不再循环导出。PostgreSQL对外交事务提供更多了Origin历史记录，无须辅助表，通过pg_replication_origin_session_setup函数或者发布订阅中的replorigin_create即可选定Origin ID。
选定Origin ID后，他们除了可以导出后通过DTS应用展开过滤，还也可以通过导出应用程序中的FilterByOriginCB回调函数在导出过程中过滤，这种方式减少了统计数据数据传输，效率更高。
图-test_decoding中OriginFilter函数DEMO
* 其他问题
除了以上三个问题，还有一些采用的问题或限制。这里列出了一些，不再展开，仅简要说明。
Toast处理：对于toast值(消息格式中可以判断)，他们在处理时一般采用占位符展开处理，接收端接收到占位符就不对这一列展开处理，虽然有些麻烦，但这也是在和数据传输toast值的方案中权衡的结果。
心跳表：虽然拷贝槽历史记录的XMIN是全局的，当他们发布的表一直没有更新时，XMIN没有推进导致WAL积压，他们可以创建一张心跳表，周期性写入统计数据并发布，使XMIN展开推进。
大外交事务延迟：根据前文提到的工作流程他们可以知道默认外交事务在COMMIT后才会展开导出，这对于大外交事务来说势必会导致延迟，PG14版本提供更多了streamin模式展开导出，即外交事务展开中展开导出并发送至接收端。
应用与实践
前两节他们从基本原理及问题的角度对PostgreSQL展开了NSA，接下去他们看如何通过他们掌握的方式论拷贝基本原理，展开统计数据北迁的应用与实践。
*全量与增量同步
在真实的统计数据北迁情景中，大部分都是全量和增量都要同步的情景，并且他们打通了统计数据数据传输的通道后，也对这条通道的安全，效率，以及功能的扩展，例如清洗，脱敏等ETL能力提出了新的要求。他们先上看一下如何实现全量与增量的同步。
图-统计报文向示意图
主要流程包括：
1. 创建拷贝槽并导出镜像
2. 根据镜像展开全量统计数据北迁
3. 根据拷贝槽展开增量统计数据的北迁
他们采用了PG统计资料库或者消息队列MQ作为统计数据代理，全量与增量导出可以与此同时展开，当全量统计数据处理完毕后，状况机通知增量处理程序展开增量发布。而对于代理中的统计数据，可以在导出后展开预处理。
*自建实例北迁上云实践
最后和大家分享两个自建实例北迁上云的实践，该案例是将自建的PG10版本实例北迁至京东云上的RDS PG 11版本，通过对增量统计数据的回流以及统计数据校验保证了统计数据安全与业务平稳切换。
图-统计数据北迁上云
DTS应用主要分为如下两个阶段：
1. 统计数据检查阶段：检查主键，权限，配置
2. 统计数据北迁阶段：结构，存量，增量统计数据北迁，监控北迁状况
3. 应用北迁阶段：切换域名，引入流量
4. 回滚阶段：增量统计数据回流，若出现问题可快速回滚。
END
开源社区的终点究竟在哪？
这里有最新开源资讯、软件更新、技术干货等文本
点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦~
