MySQL 到 ClickHouse 的高速公路

作者 | TCeason 青云科技数据库研发工程师

2000 年至今，MySQL[1] 一直是全球最受欢迎的 OLTP（联机事务处理）数据库，ClickHouse[2] 则是近年来受到高度关注的 OLAP（联机分析处理）数据库。那么二者之间是否会碰撞出什么火花呢？

本文将带领大家打破异构数据库壁垒，将 MySQL 数据同步至 ClickHouse。对QingCloud MySQL Plus[3] 平台与 MaterializeMySQL[4] 引擎进行了详细介绍，并进一步简述了 HTAP 应用场景。

背景

1、MySQL 复制的发展历程

图 1-1 MySQL 复制的发展历程

图1-1详细罗列了 MySQL 复制的发展历程。

2001 年的 MySQL 3.23 版本就已经支持了同构数据库异步复制；由于是异步复制，根本无法在实际生产中大批量使用。

2013 年 MySQL 5.7.2 版本支持增强半同步复制能力，才勉强算得上是企业级可用的数据同步方案。

2016 年 MySQL 5.7.17 支持了 MGR，并不断地发展成熟，变成了一个金融级别可用的数据同步方案。

而对于同构的 MySQL 数据同步，接下来要做的就是不断地优化体验，提升同步时效性，解决网络异常下的各类问题。

基于此，各大厂商也开始做自己的高可用同步组件。例如 QingCloud MySQL Plus，就具备了真正的强一致性和高可用能力。

2、QingCloud MySQL Plus

图 1-2 MySQL Plus 架构图

图 1-2 中的 Xenon 是由类 Raft 算法来实现的高可用组件，用来管理 MySQL 选举和探活，并订正数据准确性。MySQL 数据同步则依然使用 Semi-Sync Replication 或者 MGR，从而达到数据强一致性、无中心化自动选主且主从秒级切换，以及依托于云的跨区容灾能力。

多副本同步复制，确保金融级强一致性

QingCloud MySQL Plus 采用一主两从的初始节点架构设计，并通过 MySQL 5.7 版本中的 Semi-Sync 特性实现数据的多副本同步复制，确保至少一个从节点与主节点始终保持数据的完全一致，提供金融级数据强一致性。多个从节点的设置将极大地屏蔽掉单点故障带来的影响，确保集群内始终有从节点保有全量数据。

无中心化自动选主且主从秒级切换

节点之间使用 Raft 协议进行管理，当主节点出现故障不可用时，集群会秒级响应并选出新的主节点（与主节点数据完全同步的从节点），立即接管读写请求，确保业务的连续高可用。这一过程，用户完全无需关心后端集群中各节点的角色如何设置，一切由系统自动管理。

跨区容灾能力

可实现多可用区主从部署，具有跨可用区容灾能力，提升数据安全性及容灾能力。

MySQL 有了高可用能力之后，可以通过增加只读实例的方式来增强 AP 能力。但是 MySQL 数据结构和分布方式决定了其 AP 能力相对较弱，那么如何加速 OLAP 查询呢？

ClickHouse 同步 MySQL 数据

为了加速