Binary Log 在 MYSQL 数据流中的可用性：有什么缺点和优点？

Question

我一直在尝试使用 Kafka 连接从 MySQL 中读取数据，使用 MySQL 源连接器用于数据库和 debezium 连接器用于 bin 日志。我试图了解什么是提取更改数据的更好方法。 Bin 日志有写入日志等的开销，而从数据库读取有查询数据库的开销。与这两种方法相关的其他主要优点和缺点是什么？捕获变更数据的更好方法是什么？同样从 MySQL 8 开始，bin 日志默认启用。这是否意味着它可能是一种更好的做事方式？

Answer 1

这个问题可以总结如下：

基于日志的 CDC（由 Debezium Connector 表示）与 基于轮询的 CDC（由 JDBC Source Connector 表示）的优缺点是什么？

基于查询的 CDC：

• ✓ 通常更容易设置
• ✓ 需要更少的权限
• ✗ 轮询数据库的影响
• ✗ 需要源架构中的特定列来跟踪更改
• ✗ 无法跟踪删除
• ✗ 无法在轮询间隔之间跟踪多个事件

基于日志的 CDC：

• ✓ 捕获所有数据更改
• ✓ 事件延迟低，同时避免增加 CPU 负载
• ✓ 对数据模型没有影响
• ✓ 可以捕获删除
• ✓ 可以捕获旧记录状态和更多元数据
• ✗ 更多设置步骤
• ✗ 需要更高的系统权限
• ✗ 对于某些专有数据库来说可能很昂贵

参考：

1. Five Advantages of Log-Based Change Data Capture 来自 Gunnar 莫林
2. No More Silos: How to Integrate Your Databases with Apache Kafka and CDC 罗宾·莫法特
3. 堆栈溢出：Kafka Connect JDBC vs Debezium CDC

Answer 2

@Iskuskov Alexander 给出的列表很棒。我再补充几点：

• 基于日志的 CDC 还需要写入日志（您在问题中提到了这一点）。这不仅会增加性能开销，还会增加存储空间。

• 基于日志的 CDC 需要连续的日志流。如果 CDC 遗漏了一个日志，那么副本就无法保持同步，整个副本必须由数据库的新快照初始化的新副本替换。

• 如果您的 CDC 定期离线，这意味着您需要保留日志直到 CDC 运行，而这很难预测会持续多长时间。这导致需要更多的存储空间。

也就是说，基于查询的 CDC 有其自身的缺点。在我的公司，我们使用了基于查询的 CDC，但我们发现它不方便，我们正在努力将其替换为基于 Debezium 日志的解决方案。由于其他答案中的许多原因，还有：

• 基于查询的 CDC 难以使架构更改与副本保持同步，因此如果源数据库中发生架构更改，可能需要将副本删除并替换为新快照。

• 副本经常处于“重建”状态数小时，此时它需要从快照重新初始化，而用户不喜欢这种停机时间。快照传输也增加了网络带宽需求。

没有一个解决方案比另一个“更好”。两者都有优点和缺点。作为工程师，您的工作是选择最适合您项目要求的选项。换句话说，选择对您的需求不利的最不坏的那个。

我们无法为您做出这样的选择，因为您比我们更了解您的项目。

---

你的cmets：

启用二进制日志不会产生读取查询的开销，但会产生大量写入查询的开销。根据 Percona 首席技术官 Vadim Tkachenko 的测量，MySQL 8.0 的开销变得更大，并在此报告：https://www.percona.com/blog/2018/05/04/how-binary-logs-affect-mysql-8-0-performance/

他得出结论，二进制日志的开销在 MySQL 5.7 中约为 13%，在 MySQL 8.0 中高达 30%。

您能否解释一下“副本经常处于“重建”状态数小时，此时需要从快照重新初始化”？你的意思是建立一个复制数据库？

是的，如果您需要构建新副本，您需要获取源数据库的快照并将其导入到副本中。每一步都需要时间：

1. 创建源快照
2. 将快照传输到副本所在的主机
3. 将快照导入副本实例

多长时间取决于数据库的大小，但可以是几小时甚至天。在等待这个的时候，用户不能使用副本数据库，至少如果他们希望他们的查询分析源数据的完整副本的话。他们必须等待导入完成。