Debezium 嵌入式数据库连接管理/池答案

【问题标题】：Debezium Embedded Database Connection Management/PoolingDebezium 嵌入式数据库连接管理/池
【发布时间】：2020-03-17 03:58:38
【问题描述】：

我正在使用嵌入式 Debezium，并且似乎在单一应用程序开发环境中对我来说工作得很好。但是，我担心在多节点环境中使用此功能，其中应用程序的多个实例将尝试打开与同一数据库的连接以监视日志。是否需要连接池实现？我在文档中找不到这方面的信息。

【问题讨论】：

请问您为什么使用嵌入式模式？流式传输到 Kafka（通过常规 Kafka Connect 部署风格）允许多个消费者使用更改日志的单个阅读器（来自 Kafka 主题）。此外，如果您的应用程序节点属于同一消费者组，则只有其中一个会处理每个事件。了解更多关于您的具体用例以提供更可靠的建议会很有趣。
Kafka 不是我们的选择（公司决定）。我们处于需要发布/订阅解决方案的位置，我们希望再次保持 DB 表与内存数据库同步公司决定。我们有一些旧的兔子实例，我被告知我们在这里也不再支持非常有限。嵌入式 Debezium 似乎适合我们的需求，我们可以在不破坏架构的情况下实现它。我唯一关心的是有多个应用程序连接回读取数据库日志表是一个问题。我们在生产中有 12 个实例将指向同一个数据库。谢谢

【解决方案1】：

虽然我不是 Debezium 的专家，但我确实管理 IBM Data Replication 产品组合，所以这个答案就是考虑到这一点。

定义：

更改数据馈送 = 对通过恢复/事务/撤消日志捕获的多个表之一进行插入、更新、删除

通常，如果您有多个更改数据事件馈送的使用者，则适当的设计选择是将该馈送放入一个队列中一次，然后在该队列中拥有多个读取器，从而避免使用多个日志读取器。

队列可以被多个消费者读取。队列的示例是“暂存审计表”，即包含更改馈送的表。您需要定期删除审计表以防止它们变大。

另一个流行的选择是分期到 Kafka。 Kafka 面向多读者，少作者。

一些成熟的产品（如 IBM Data Replication 产品组合）具有完全设计用于满足原始更改源的许多消费者的用例的功能，即所谓的“抓取缓存”或“单一抓取器”。通过这种方式，复制工具可以将原始更改源发送到许多目标，包括数据库、Hadoop 和 Kafka，而只需在源数据库上读取一次日志。

干杯！

【讨论】：