Debezium发布历史07

原文地址： https://debezium.io/blog/2016/08/02/capturing-changes-from-mysql/

从 MySQL 捕获更改
八月 2, 2016 作者： 兰德尔·豪奇
mysql

欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.

变更数据捕获是一个热门话题。Debezium 的目标是让多个 DBMS 轻松捕获变更数据，但不可否认，我们仍然是一个年轻的开源项目，到目前为止，我们只发布了一个用于MySQL 的连接器，以及即将推出的用于 MongoDB 的连接器。因此，很高兴看到其他人如何使用和实施变更数据捕获。在这篇文章中，我们将回顾 Yelp 的方法，看看它与 Debezium 的 MySQL 连接器有何惊人的相似之处。

Yelp 上的流数据
Yelp 工程博客最近开始了一系列描述其实时流数据基础设施的文章。第一篇文章提供了很好的介绍，并解释了如何从整体架构转向面向服务的架构提高了生产力，但也使处理分布在拥有该数据的 100 个服务中的数据变得更具挑战性。现在完全值得您花时间阅读它。

正如贾斯汀在帖子中所写，有几个原因促使他们创建自己的实时流数据管道：

确保跨服务的数据始终保持一致始终是一项艰巨的任务，尤其是当事情可能并且确实会出现问题时。跨服务的事务在某些情况下可能很有用，但它们并不简单，成本高昂，并且可能导致请求放大，其中一个服务调用另一个服务，而另一个服务与另外两个服务协调，等等。

在多个后端服务中更新数据的服务会遇到双重写入问题，即在更新一个后端服务之后但在更新另一个后端服务之前发生故障，并且总是会导致难以追踪和纠正的数据不一致。

组合和集成分布在多个服务中的数据也可能很困难且成本高昂，但当数据不断变化时就更难了。一种方法是使用批量 API，但这些 API 可能难以创建，可能会导致不一致，并且当服务需要不断接收永无休止的数据更新时，会带来真正的可扩展性问题。

Yelp 的实时数据管道将数据更改记录在完全有序的分布式日志上，以便下游消费者能够以完全相同的顺序接收和处理相同的更改。服务可以使用其他服务所做的更改，因此无需显式的服务间通信即可保持同步。该系统使用 Kafka 来记录事件日志，使用一个名为MySQLStreamer的自主开发系统来捕获对 MySQL 表的提交更改，使用Avro来记录消息格式和模式，以及一个自定义Schematizer服务来跟踪消费者并在每个 Kafka 上强制执行用于消息的 Avro 模式话题。

Yelp 如何捕获 MySQL 更改
也许 Debezium 最感兴趣的是 Yelp 如何捕获 MySQL 数据库中已提交的更改并将其写入 Kafka 主题。该系列的第二篇文章更详细地介绍了 MySQLStreamer 进程，该进程读取 MySQL 二进制日志并持续处理日志中出现的 DDL 语句和 DML 操作，生成相应的insert、update、delete和刷新事件，并将这些事件消息写入每个 MySQL 表的单独 Kafka 主题。我们之前提到过DML 操作产生的 MySQL 行级 binlog 事件不包含列的完整定义，因此了解每个事件中列的含义需要处理也出现在 binlog 中的 DDL 语句。Yelp 使用一个单独的 MySQL 实例，它称为模式跟踪器数据库，其行为类似于 MySQL 从机，仅应用从 binlog 读取的 DDL 语句。这项技术让 Yelp 的 MySQLStreamer 系统了解二进制日志中处理事件时数据库模式的状态及其表的结构。这非常有趣，因为它使用 MySQL 引擎来处理 DDL 解析。

Yelp 的 MySQLStreamer 进程使用另一个 MySQL 数据库来跟踪描述其在 binlog 中位置的内部状态、哪些事件已成功发布到 Kafka，以及由于每个副本上的 binlog 位置不同，因此还跟踪有关每个事务的与副本无关的信息。后一个信息与 MySQL GTID 类似，尽管 Yelp 使用的是不支持 GTID 的早期版本的 MySQL。

当然，对于已经存在很长时间的数据库必须特别考虑。MySQL binlog 是有上限的，不会包含数据库的整个历史记录，因此 Yelp 的 MySQLStreamer 进程通过启动另一个干净的 MySQL 副本来引导旧数据库的更改数据捕获过程，该副本将使用内置的 MySQL 复制机制和MySQL 黑洞数据库引擎来获取主服务器的一致快照，以便所有活动都记录在副本的二进制日志中，而副本实际上不存储任何数据。

Yelp 的 MySQLStreamer 机制非常巧妙，它使用 MySQL 和多个额外的数据库来捕获 MySQL 数据库的更改并将其写入 Kafka 主题。当然，缺点是这样做确实会增加系统的操作复杂性。

相似的目的，相似的方法
Debezium 是一个开源项目，正在为各种 DBMS 构建变更数据捕获。与 Yelp 的 MySQLStreamer 一样，Debezium 的MySQL Connector可以持续捕获对 MySQL 数据库行的已提交更改，并将这些事件记录在每个表的单独 Kafka 主题中。首次启动时，Debezium 的 MySQL Connector 可以执行初始一致快照，然后开始读取 MySQL binlog。它同时使用了binlog中出现的DDL和DML操作，直接解析并使用DDL语句了解每个表结构的变化以及每个插入、更新和删除binlog事件的映射。写入 Kafka 的每个生成的更改事件都包含有关原始 MySQL 服务器及其 binlog 位置的信息，以及受影响行的之前和/或之后状态。

然而，与 Yelp 的 MySQLStreamer 不同，Debezium MySQL 连接器不需要或使用额外的 MySQL 数据库来解析 DDL 或存储连接器的状态。相反，Debezium 构建在 Kafka Connect 之上，Kafka Connect 是一个新的 Kafka 库，提供了许多通用功能，可以可靠地从外部系统提取数据、将其推送到 Kafka 主题以及跟踪已处理的数据。Kafka Connect 将此状态存储在 Kafka 内部，从而简化了操作足迹。然后，Debezium 的 MySQL 连接器可以专注于在需要时执行一致快照、读取二进制日志以及将二进制日志事件转换为有用的更改事件的细节。

Yelp 的实时数据管道利用自定义 Avro 架构注册表，并使用这些 Avro 架构将每个事件编码为紧凑的二进制表示形式，同时保留有关事件结构的元数据。使用 Debezium 也可以做到这一点：只需将Confluence 的架构注册表作为服务运行，然后配置 Kafka Connect 工作线程以使用Avro 转换器。当转换器序列化每个事件时，它会查看连接器定义的结构，当该结构发生更改时，会生成更新的 Avro 架构并将其注册到架构注册表。然后，使用新的 Avro 模式将事件（以及其他具有相同结构的事件）编码为写入 Kafka 的紧凑二进制形式。当然，消费者也可以使用相同的 Avro 转换器，这样当事件被反序列化时，只要转换器需要它不知道的 Avro 架构，它就会与架构注册表进行协调。因此，事件以紧凑的方式存储，同时事件的内容和元数据仍然可用，而架构注册表捕获并维护每个表的 Avro 架构随时间演变的历史记录。

使用 Debezium 捕获 MySQL 的更改
如果您对使用 MySQL（或任何其他 DBMS）捕获变更数据感兴趣，请尝试一下 Debezium，浏览我们的教程，该教程将引导您启动 Kafka、Kafka Connect 和 Debezium 的 MySQL 连接器，以准确了解变更数据事件的样子以及如何使用它们。最重要的是，它是开源的，拥有不断增长的开发人员社区，并且受益于构建在最近创建的 Kafka Connect 框架之上。我们的 MySQL 连接器现已准备就绪，但我们正在开发其他 DBMS 的连接器。具体来说，我们即将发布的 0.3 版本将包括我们的MongoDB Connector，0.4 版本包括用于 PostgreSQL 和/或 Oracle 的连接器。

更正：本文的前一个版本错误地指出 Yelp 使用的是支持 GTID 的 MySQL 版本，而实际上他们使用的是不支持MySQL GTID 的版本。该帖子已更正，作者对错误感到遗憾。