ClickPipes 背后的技术实现：在 ClickHouse 中构建 MySQL 变更数据捕获

本文字数：4437；估计阅读时间：12 分钟

作者：Kaushik Iska, Philip Dubé

简介

变更数据捕获（Change Data Capture，CDC）是现代数据架构中实现实时数据集成的重要技术模式。本文将深入探讨 ClickPipes —— ClickHouse Cloud 提供的原生数据集成方案 —— 如何在内部实现对 MySQL 数据库的 CDC。文章面向工程师与架构师，旨在帮助读者深入理解这一高可靠、高性能数据库复制机制背后的工作原理。

MySQL 复制基础

我们先回顾一下 MySQL 中的复制基本原理。

二进制日志：MySQL CDC 的核心

MySQL 的二进制日志（binlog）是其整个复制架构的基础。它会按顺序记录所有对数据库数据和结构所做的更改，概念图如下：

这些日志事件包括：

• 数据操作（INSERT、UPDATE、DELETE）

• 数据定义（CREATE、ALTER、DROP）

• 事务边界（BEGIN、COMMIT、ROLLBACK）

每个 binlog 事件都包含一个事件头（包含时间戳、服务器 ID 等元数据），以及一个事件体，记录实际的数据变更内容。

二进制日志格式

MySQL 支持三种 binlog 格式：

1. STATEMENT：记录执行的 SQL 语句

   1. 日志数据量小

   1. 遇到非确定性函数时可能导致复制不一致

   1. 不适用于 CDC 场景

2. ROW：记录实际变更的行数据

   1. 包含变更前和变更后的行镜像

   1. 数据最精确，但日志体积较大

   1. 是实现 CDC 所必须的格式

3. MIXED：默认采用 STATEMENT 格式，在需要时切换为 ROW 格式

   1. 同样不适用于 CDC

前提条件 — binlog_row_image = FULL

为了保证每次行级变更都能携带完整的变更前和变更后镜像，ClickPipes 要求源 MySQL 数据库将参数 binlog_row_image 设置为 'FULL'。这是 MySQL 8.x 中的默认配置。虽然 MINIMAL 或 NOBLOB 等轻量模式可以省略未发生变化的列，从而减少日志体积，但这会影响 ClickPipes 的幂等更新能力，并可能导致主键更新操作不安全。启用 FULL 模式主要会增加包含大量 UPDATE 的日志大小，而 INSERT 和 DELETE 基本不受影响，因此整体性能开销通常可控。

全局事务标识符（GTI