Debezium 博客
作为近期 使用变更数据捕获和流处理构建审计日志 博客文章的后续，我们希望通过管理功能扩展此示例，使其能够捕获和修复任何缺失的事务数据。
在上述博客文章中，有一个日志增强服务，用于将“Vegetable”数据库表中插入或更新的数据与事务上下文数据（例如
-
事务 ID
-
执行操作的用户名
-
实际更改背后的用例，例如“创建蔬菜”
只要所有更改都通过蔬菜服务进行，这一切都能很好地工作。但情况总是如此吗？
那么维护活动或直接在数据库级别执行的迁移脚本呢？仍然存在大量此类活动，无论是故意的，还是因为这是我们正在努力改变的老习惯……
让我们谈谈 TOAST。吐司？不，TOAST！
那是什么？TOAST (The Oversized-Attribute Storage Technique，超大属性存储技术) 是 Postgres 中的一种机制，它将大型列值存储在多个物理行中，从而绕过了 8 KB 的页面大小限制。
通常，TOAST 存储对用户是透明的，所以您真的不必关心它。但是有一个例外：如果表行已更改，则使用 TOAST 机制存储的任何*未更改*值都不会包含在 Debezium 从数据库收到的消息中，除非它们是表复制身份的一部分。因此，这种未更改的 TOAST 列值将不会包含在发送到 Apache Kafka 的 Debezium 数据变更事件中。在本文中，我们将讨论处理这种情况的不同策略。
业务应用程序通常需要维护某种形式的审计日志，即应用程序数据所有更改的持久化跟踪。如果仔细看，带有 Debezium 数据更改事件的 Kafka 主题与之非常相似：它源自数据库事务日志，描述了应用程序记录的所有更改。所缺少的只是一些元数据：数据为何、何时以及由谁更改？在本博文中，我们将探讨如何通过变更数据捕获 (CDC) 提供和公开这些元数据，以及如何使用流处理来丰富实际的数据更改事件以包含此类元数据。
