ClickPipes 的 MySQL CDC 连接器正式 GA

摘要

只需几次点击，即可将 MySQL 和 MariaDB 的数据复制到 ClickHouse Cloud 中，实现极速分析。现在支持并行快照、更高的可靠性和可观测性，以及编程配置（Cloud API、Terraform）。

在 ClickHouse，我们非常推崇为合适的工作使用合适的工具。在首个原生变更数据捕获（CDC）连接器发布后不久，ClickPipes（Postgres），我们就致力于为那些在分析工作负载上已经超出 MySQL 能力的客户提供同样的体验：让 OLTP 专注于处理关键任务的操作工作负载，并将复杂的分析查询、报告和商业智能工作负载卸载到 ClickHouse 速度的 OLAP 上。

挑战是什么？为完全不同的源数据库构建新的 CDC 连接器没有一刀切的方法，因此功能的完整性和稳定性不仅需要时间，还需要生产环境的实践。在迁移了超过1PB的数据，服务了数百个生产客户之后，我们很高兴地宣布 MySQL CDC 连接器现已全面可用！

“对于 Kit 来说，ClickHouse 无疑是目前最快的数据库。如果你的应用运行在 MySQL 上怎么办？你可能需要花一年时间构建一个 ETL 管道并永久维护它。或者，在 ClickPipes 中按一个按钮，你就可以在 ClickHouse 速度下对生产数据运行分析工作负载。附带的好处是，你还可以免费获得审计日志和软删除。” — Kim MacCormack，高级工程经理，Kit

立即开始

立即注册 ClickHouse Cloud，试用适用于 ClickPipes 的 MySQL CDC 连接器！

注册

有什么新功能？

并行快照加快初始加载和重新同步

快照是保证 CDC 管道中数据一致性的关键操作，但它通常意味着需要处理和摄取来自生产实例的数百 GB 数据。你希望它快，这样你就能快速启动并运行并从故障中恢复快，但对上游的影响尽可能小。

在最初的实现中，快速快照要求你手动选择特定类型（数值或时间）的特定逻辑分区键列才能尝试并行处理；所有其他场景都会回退到缓慢的单线程扫描。现在这都已成为过去：ClickPipes自动从表的主键中检测合适的逻辑分区键（现在也包括字符串和 UUID 类型），并分配工作负载，使你的快照在默认情况下就快。在我们的基准测试中，一个 1TB 的快照在单线程上需要一天多的时间，而在 32 个 worker 上分布式完成大约需要一小时。这就是区别所在。

更安全的生产环境默认值

CDC 是一种温和的野兽，有很多故障模式很容易导致无法在不完全重新同步的情况下恢复复制。为了降低这种风险，MySQL CDC ClickPipes 现在要求：

• 基于 GTID 的复制：虽然最初的 MySQL CDC ClickPipes 实现将此配置作为可选项，但现在它是新 ClickPipes 的默认设置。为什么做出这一更改？基于文件位置的复制是 MySQL 中的一种传统机制，它将恢复绑定到特定服务器上的特定（binlog 文件，偏移量），这在故障转移时会中断，并需要手动干预。从 MySQL v5.6.5（以及 MariaDB 10.0.2）开始，可以使用一种基于全局事务标识符（GTID）的更可靠且拓扑无关的机制，允许在故障转移场景后自动恢复复制。
• （至少）72 小时的 binlog 保留：MySQL CDC ClickPipes 只有在包含其处理的最后一个 GTID 的 binlog 段未被清除时才能恢复复制。我们观察到许多不可恢复的错误，如果在故障场景或长时间暂停期间 binlog 没有过早轮换，清除管道恢复所需的段，这些错误本可以避免。最少 72 小时为 ClickPipe 提供了足够的回旋余地，以便在最坏情况下恢复，或在发生这种情况之前处理 ClickHouse 端的背压，从而避免强制完全重新同步。

这两个要求在管道创建时都会进行验证，因此你需要确保上游配置匹配，然后再创建新的 ClickPipe。如果你使用基于文件位置的复制在活跃的 MySQL CDC ClickPipe 中，我们强烈建议将其迁移到基于 GTID 的复制，并使用新的 GTID 默认创建任何新的 ClickPipes。需要注意的是，配置 GTID 将不会影响使用传统机制的现有管道；它们可以共存。

改进的可观测性，便于故障排除

尽管连接器从一开始就完全集成到 ClickHouse Cloud 体验中，但 CDC ClickPipes 在可观测性方面欠佳：调试缓慢的 CDC 管道通常需要一定程度的猜测，或提交支持工单以确定瓶颈是上游 MySQL、下游 ClickHouse，还是两者之间。

对于 GA，我们扩展了内置指标和监控，使其也报告资源利用率和滞后。以下指标现在可在 ClickPipes UI 和ClickHouse Cloud Prometheus 端点中获取：

资源利用率

你现在可以独立调查可能需要扩展 CDC ClickPipes 的场景（例如在快照期间或流量突发时），排除资源饱和作为复制延迟的根本原因，以及其他基本的故障排除工作流程。

CPU 使用率：服务中所有 CDC ClickPipes 消耗的核心数对比分配量，或拉取和推送进程当前正在使用的计算量。

内存使用率：服务中所有 CDC ClickPipes 消耗的内存对比分配量，或拉取和推送进程当前占用的 RAM 量。

网络接收带宽：管道上的入站吞吐量，或每秒从源拉取的数据量。

复制延迟

现在也更容易了解数据的时效性，以及复制延迟是发生在源端、ClickHouse 端，还是在两者之间。

源端延迟： 拉取过程相对于 MySQL 实时 binlog 的落后程度，或 MySQL 中发生更改与 ClickPipes 拉取该更改之间的时间。 目标端延迟： 已拉取的更改到达 ClickHouse 所需的时间，或更改被拉取与在目标端可查询之间的时间。 端到端延迟： 上述两个指标之和，或从 MySQL 中发生更改到该更改出现在 ClickHouse 中的总时间。

Terraform 和 OpenAPI 支持

ClickOps（即 在用户界面中点击按钮）对于入门很有用，但管理生产部署的团队需要 Terraform 等标准工具，以安全、确定且版本控制的方式配置和管理资源。与其他 ClickPipes 类型一样，MySQL CDC ClickPipes 可以使用 Open API 和 Terraform（v3.14.0+）进行管理。如果您希望将现有的 ClickPipes 纳入源代码控制，请按照 这篇博文 中的步骤将这些资源导入到您的 Terraform 状态中。

并非所有为使 MySQL CDC 连接器达到 GA 就绪而付出的工作都能用简洁的标题概括：从数据类型保真度到较小的可靠性修复，我们的团队投入了无数时间使连接器达到生产和企业就绪状态。如果您想了解更多细节，我们建议您让智能体查看 PeerDB 仓库 以获取完整的更改概览。🤖

定价

作为本次过渡的一部分，MySQL CDC ClickPipes 的计费自 2026 年 9 月 1 日起生效，并将反映在您 ClickHouse Cloud 账户的下一个计费周期中。该连接器采用基于数据量的可预测定价模型，每个服务有固定的计算成本，该成本在所有类型的 CDC ClickPipes 之间共享。MySQL CDC 连接器比使用第三方 ETL 工具 任何类型都更加经济高效，成本效益高出 5-10 倍，这体现了我们致力于将 ClickPipes 作为连接 ClickHouse Cloud 和您各种数据源的无缝且经济实惠的选择。有关更多详细信息，请参阅 ClickPipes 计费文档。

开始使用 MySQL CDC 连接器

MySQL CDC 连接器适用于所有服务层级的新老 ClickHouse Cloud 客户。要开始使用，请导航到 ClickHouse Cloud 控制台中的 数据源 选项卡，配置您的 MySQL 或 MariaDB 数据库的连接详情，然后就可以开始了！

有关分步说明、常见问题和注意事项，请查看 MySQL ClickPipes 文档。

准备好加速 MySQL 数据的分析了吗？

立即试用 MySQL CDC 连接器，体验与 ClickHouse Cloud（全球最快的分析数据库）完全托管、原生的集成体验。