（三） `MaterializedMySQL`同步机制解读

当使用 ClickHouse 的 MaterializedMySQL 引擎进行全量同步时，它主要依赖于两个关键机制：初始全量数据导入和随后的增量更新。以下是这些机制的详细解释：

初始全量数据导入

1. 读取现有数据:

   • 当您在 ClickHouse 中创建一个 MaterializedMySQL 类型的数据库时，ClickHouse 首先连接到指定的 MySQL 数据库。
   • 它读取 MySQL 数据库中所有表的当前状态，包括所有行和列的数据。

2. 数据转换:

   • ClickHouse 将从 MySQL 读取的数据转换为其自己的数据格式。这个过程包括数据类型的转换，因为 ClickHouse 和 MySQL 在数据类型上有所不同。

3. 数据存储:

   • 转换后的数据被存储在 ClickHouse 的表中。这些表反映了 MySQL 中的表结构，但使用 ClickHouse 的存储格式和类型。

随后的增量更新

1. 二进制日志（Binlog）:

   • 一旦初始全量数据导入完成，ClickHouse 开始监听 MySQL 的二进制日志（binlog）。Binlog 是 MySQL 用来记录所有更改（如插入、更新、删除）的日志文件。

2. 读取和应用更改:

   • ClickHouse 实时读取 binlog 中记录的更改，并将这些更改应用到其内部存储的表中。
   • 这意味着当 MySQL 数据库中的表被修改时，这些更改几乎即时地反映在 ClickHouse 中的相应表上。

3. 处理 DDL 语句:

   • 如果在 MySQL 中执行了数据定义语言（DDL）操作（如创建表、修改表结构等），这些操作也会通过解析 binlog 来同步到 ClickHouse。

4. 事务处理:

   • ClickHouse 使用 _version 和 _sign 这两个虚拟列来处理 MySQL 事务。这些列帮助管理数据的版本和删除标记，以保持与 MySQL 的一致性。

注意事项

• 实时同步的依赖性：这种同步机制高度依赖于 MySQL 的 binlog，因此必须在 MySQL 服务器上启用并正确配置 binlog。
• 延迟：尽管同步几乎是实时的，但在高负载或网络延迟的情况下，可能会出现轻微的延迟。
• 复制限制：某些特定类型的 MySQL 更改可能无法在 ClickHouse 中准确复制，如某些复杂的 DDL 操作或特定类型的数据。
• 初始同步时间：对于含有大量数据的 MySQL 数据库，初始的全量数据导入可能需要相当长的时间。

总之，MaterializedMySQL 引擎通过首先进行一次全量数据导入，然后持续应用 MySQL 的增量更改来实现数据同步。这种方式适用于需要在 ClickHouse 中镜像 MySQL 数据库的场景。