CDC的实现原理
iPaaS CDC框架及其原理
iPaaS CDC是一个构建在Apache Kafka之上的CDC开源平台，主要用途是在事务日志中记录提交给每个源数据库表的所有行级更改。它提供了一个连接器库，支持多种数据库，例如MySQL、Oracle、PostgreSQL等。这些连接器可以监视和记录数据库更改并将其发布到Kafka等流服务。
iPaaS CDC的工作原理基于日志的CDC，确保捕获所有的数据变更，以极低的延迟生成变更事件，同时避免因为频繁轮询导致CPU使用率增加。例如，对于MySQL或PostgreSQL，延迟在毫秒范围内。iPaaS CDC不需要更改数据模型，并且可以捕获删除操作以及旧记录状态以及其他元数据。
CDC监听之MySQL中的biglog
MySQL的Binlog，即二进制日志，记录数据库更改（不包括查询操作）的日志文件。这些更改包括数据的插入、更新、删除以及数据定义语言（DDL）操作，如创建表、修改表结构等。Binlog对数据库复制、数据恢复和审计至关重要。
Binlog记录数据库的物理变更，即对磁盘上数据页的实际更改。这种记录方式使得Binlog能够精确再现任何数据库操作。事务的变更被记录到Binlog中，如果事务提交，相关的Binlog事件也会被标记为提交状态；如果事务回滚，相关的Binlog事件也会相应回滚。
CDC监听之Oracle的LogMiner和XStream API
LogMiner
LogMiner是Oracle提供的一个分析工具，它可以解析Oracle Redo日志文件，将数据库的数据变更日志解析成变更事件输出。LogMiner特别适用于调试、审计或者回退某个特定的事务。作为一个完全免费的工具，LogMiner可以分析在线和离线日志文件，适用于分析本数据库或其他数据库的重作日志文件。然而，Oracle对解析日志文件的进程做了严格的资源限制，因此对于大规模的表，数据解析可能会比较慢。
XStream API
CDC监听之PostgreSQL的逻辑解码能力
PostgreSQL的逻辑解码（Logical Decoding）是一种强大的功能，它允许用户以一种连贯、易于理解的格式提取数据库表的所有持久化变更，而无需详细了解数据库的内部状态。自PostgreSQL 9.4版本起，逻辑解码通过解码预写日志（write-ahead log, WAL）的内容实现，这些内容描述了存储级别的变更，并将其转换成特定于应用程序的格式，例如元组流或SQL语句。
在逻辑复制的上下文中，一个槽（slot）代表了可以按照在原始服务器上变更产生顺序重放到客户端的变更流。每个槽流式传输单个数据库的变更序列。输出插件将预写日志的内部表示转换成复制槽消费者所期望的格式。这些插件用C语言编写、编译，并安装在运行PostgreSQL服务器的机器上，它们使用了一些PostgreSQL特定的API。
逻辑解码的主要优势在于其能够提供一种高效、可靠的数据流，用于捕获和复制数据库变更。这对于数据同步、备份、审计和分析等场景非常有用。逻辑解码支持多种输出插件，如decoderbufs和pgoutput，这些插件能够将WAL中的变更转换成不同的格式供消费者使用。
decoderbufs输出插件为逻辑解码生成一个Protobuf消息，每个数据库变更对应一个消息，包含更新表行的新旧元组。而pgoutput插件则提供了更细粒度的控制和更好的性能，尤其是在处理大量变更时。
逻辑解码的实现依赖于PostgreSQL的WAL配置，它允许数据库在处理事务时记录足够的信息，以便能够回放这些事务以重建数据库状态。这要求在postgresql.conf配置文件中设置适当的参数，如wal_level设置为logical，以及配置max_wal_senders和max_replication_slots等参数，以支持逻辑解码和复制槽的使用。
如何在iPaaS DataFlow中创建CDC数据同步任务
首先，在ETL开发列表中，创建同步任务。
接下来选择数据来源和数据去向。
然后配置字段映射，是否创建新表等操作。
点击创建后，发布本次新建的同步任务，一个简单的数据同步任务就完成了。后续可以在目标数据库中看到创建的新表及同步的数据，当原表有新增数据时，同步的表也会增加一条数据。
本期内容就为大家介绍到这里了，如果您有需要进一步视频讲解，或者您有更好的建议，欢迎联系我们反馈！
往期精选
