Debezium 博客

此帖最初发布于 WePay 工程博客。

在此博客文章系列的上半部分，我们解释了我们在 WePay 设计 Cassandra 流式数据管道的决策过程。在此帖中，我们将把该管道分解为三个部分，并更详细地讨论每个部分

本文最初发布在 WePay 工程博客。

历史上，MySQL 一直是 WePay 微服务的事实数据库选择。随着 WePay 的扩展，我们的一些微服务数据库中写入的数据量变得非常大，这迫使我们必须在分片 MySQL（例如 Vitess）和切换到原生分片 NoSQL 数据库之间做出扩展决策。经过一系列评估，我们选择了 NoSQL 数据库 Cassandra，主要因为它具有高可用性、水平可伸缩性和处理高写入吞吐量的能力。

Debezium 的容器镜像结构得到了巨大的改进，最近，使得扩展其行为变得非常简单。

这是一个小型教程，展示了如何例如添加 Sentry，“一个开源错误跟踪 [软件]，帮助开发人员实时监控和修复崩溃”。这里我们将使用它来收集和报告 Kafka Connect 及其连接器的任何异常。请注意，这仅适用于 Debezium 0.9+。

我们需要一些东西来使 Sentry 工作，我们将添加所有这些，然后有一个 Dockerfile 来正确地将它们组合在一起

我很高兴地宣布 Debezium 0.10.0.Beta2 的发布！

这进一步稳定了 0.10 版本系列，为不同连接器进行了大量错误修复。23 个问题已在此版本中修复；其中一些与 MySQL 连接器的 DDL 解析器有关，例如关于 RENAME INDEX（DBZ-1329）、触发器中的 SET NEW（DBZ-1331）以及带有 COLLATE 关键字的函数定义（DBZ-1332）。

对于 Postgres 连接器，我们修复了刷新已处理 LSN 到数据库时可能出现的潜在不一致性（DBZ-1347）。此外，“include.unknown.datatypes”选项现在快照期间按预期工作（DBZ-1335），并且连接器不再会在快照期间遇到物化视图（DBZ-1345）。

Debezium 项目致力于提供易于部署的连接器，因此用户可以通过获取正确的连接器存档并将其解压到 Kafka Connect 的插件路径中，来尝试运行他们选择的连接器。

这适用于所有连接器，但 Debezium PostgreSQL 连接器除外。该连接器具有独特性，因为它需要在 PostgreSQL 源数据库本身内部安装逻辑解码插件。目前，有两个支持的逻辑插件。