非你想的那个 CDC，实为我这个 CDC 也

背景

CDC，Change Data Capture，直译为变更数据捕获，反正能理解就对了。

答案在哪里

你是否在调研数据库数据实时复制方面，遇到以下问题：

• 基于 binlog（transaction log）事件流

• 一款支持多种主流数据库复制的产品，包括 MySQL、PostgreSQL、SQL Server、Oracle、Cassandra 等

• 基于分布式流处理平台，比如基于 Kafka（或 Pulsar），可以利用 Kafka Connector 功能，这样方便数据复制到很多你想要的地方

• 最好大公司开源，社区活跃，版本更新快

那么，答案来了，就是地摊经济。

哦，No，纠正一下，是 Debezium。

此 CDC 非彼 CDC

或许大家都使用过 canal，当然也可能使用 maxwell，笔者后续文章还会介绍 Netflix DBLog，在生产实践方面的功能非常强大。

无论是 canal 还是 maxwell，都死磕 MySQL，当然他们也很优秀，但是笔者不聊它们。

今天，笔者介绍一款专注于 CDC 的产品，Debezium。

接触过 CDC 的读者，不清楚有多少人研究过 Debezium（https://github.com/debezium/debezium），笔者经过一段时间深入研究，发现项目本身还是不错的，当然某些问题也是存在的，这个以后结合案例和大家细聊。

Debezium 是 RedHat 设计的一款开源产品，为捕获数据更改（Capture Data Change，CDC）提供了一个低延迟的流式处理平台，通过安装配置 Debezium 监控数据库，可以实时消费行级别（row-level）数据的更改。Debezium 是构建在 Apache Kafka 之上，可扩展，经官方验证可处理大容量的数据。

既然 Kafka 普及度那么高，所以使用 Debezium 就水到渠成了。

快速过一下官方描述：

Debezium is an open source distributed platform for change data capture. Start it up, point it at your databases, and your apps can start responding to all of the inserts, updates, and deletes that other apps commit to your databases. Debezium is durable and fast, so your apps can respond quickly and never miss an event, even when things go wrong.

不翻译了，都是英语六级单词，大家都能看懂。

Debezium

Debezium 架构

首先，我们看一下基于 Debezium 的 CDC pipeline 的架构：

Debezium 可以通过 Apache Kafka Connect 部署和应用的，包括 Source 和 Sink connector。

• Source connector 比如 Debezium，摄取数据写入 Kafka。

• Sink connector 从 Kafka topics 中消费数据并写入到其他系统。

除了 Kafka broker 本身以外，Kafka Connect 还作为一项单独的服务运行。如果部署了 MySQL 和 Postgres 的 Debezium connector，那么可以使用客户端库建立到这两个源数据库的连接，在使用 MySQL 时访问 binlog，在使用 Postgres 时从逻辑复制流读取数据。

既然捕获更改事件的数据位于 Apache Kafka 中，那么我们就可以使用来自 Kafka Connect 生态系统的各种 Connector 将 CDC 数据传输到其他系统和数据库，比如 Elasticsearch、数据仓库和分析系统或缓存。

Debezium 特性

Debezium 是 Apache Kafka Connect 的一组 Source connectors，使用 CDC 从不同的数据库中获取更改事件（INSERT、UPDATE 和 DELETE），实时同步到 Kafka，稳定性强且速度非常快。与其他方法（比如双写）不同，Debezium 实现的基于 log 的 CDC：

• 确保所有的数据更改都是可捕获的

• 非常低延迟地生产变更事件（比如 MySQL、Postgres 都是毫秒级别），避免增加 CPU 负载

• 不需要更改数据模型（例如 LAST_UPDATE_TIMESTAMP 列）

• 可以捕获删除

• 可以捕获旧记录状态以及其他元数据（取决于数据库的功能和配置）

前奏

为了方便大家跟着笔者实战，在本篇案例中，笔者的环境如下：

• Confluent Platform 5.5.0 Confluent Platform 自带了 Zookeeper、Kafka、KSQL、Kafka-Connector。自己部署的 Apache Kafka 环境都是可以的，不要忘记部署 KSQL，以及 Kafka Connector。

• Elasticsearch/Kibana 7.6.1

• MySQL/MariaDB

本篇文章，以 MySQL 作为数据源，后续再补充 PostgreSQL 等。

方案解读

为了实现将 MySQL 的数据实时同步到 Elasticsearch，可以分两个步骤：

• 1. 使用 Debezium，通过 MySQL binlog 将数据同步到 Kafka Topic
  

• 2. 使用 Kafka Connector，将 Kafka Topic 数据同步到 Elasticsearch
  

Connector 插件

为了捕获 MySQL 变更记录并写入 Elasticsearch，我们需要部署以下 Connectors：

• MySqlConnector

• PostgresConnector

• ElasticsearchSinkConnector

以上 Source 和 Sink 的 Connector 可以从 https://docs.confluent.io/current/connect/managing/connectors.html 下载并安装到 confluent 指定的目录，并在配置文件中配置路径，比如笔者的环境为：

# 配置文件
/etc/kafka/connect-distributed.properties


# 配置 plugins 路径
plugin.path=/usr/local/confluent/share/kafka/plugins

如果环境准备完成，并且 Kafka connector 启动成功，就可以进行查询：

# curl -s localhost:8083/connector-plugins|jq '.[].class'|egrep 'MySqlConnector|ElasticsearchSinkConnector|PostgresConnector|SqlServerConnector'


"io.confluent.connect.elasticsearch.ElasticsearchSinkConnector"
"io.debezium.connector.mysql.MySqlConnector"
"io.debezium.connector.postgresql.PostgresConnector"
"io.debezium.connector.sqlserver.SqlServerConnector"

案例实战

笔者会介绍两个使用的方式：

• MySQL -> Kafka -> Elasticsearch

• MySQL -> ksqlDB -> Elasticsearch

实战1: MySQL -> Kafka -> Elasticsearch