MySQL 数据归档的技术困境与 Databend 解决之道

在企业数字化转型的浪潮中，MySQL 作为最受欢迎的开源数据库，承载着越来越多的业务数据。从最初的几百 GB，到现在动辄几个 TB 甚至数十 TB 的数据规模，MySQL 数据库的体量增长速度常常超出企业的预期。然而，一个不容忽视的现实是：这些庞大数据库中真正的热点数据往往只占 20-30%，剩下的大部分都是历史数据、日志记录和归档信息。

这种现象在各个行业都很普遍。电商平台需要保留多年的订单记录用于用户查询和监管合规；金融机构必须长期存储交易流水以满足审计要求；政务系统要保存大量的办事记录和操作日志；游戏公司积累了海量的玩家行为数据用于分析和运营。这些数据有个共同特点：具有明显的生命周期，在线一段时间后失去实时业务价值，但仍需要保留用于合规、审计或分析。与此同时，随着业务规模的扩大，现在有很多企业正在从传统的 MySQL 迁移到分布式数据库，如 TiDB、OceanBase 等原生分布式数据库。这种技术升级往往涉及大量的数据搬迁工作，如果企业平时就做好了数据归档工作，将冷数据提前分离出来，那么在进行数据库迁移时的工作负担就能大大减轻。

如何妥善处理这些"冷数据"，既保证业务系统的性能，又控制存储成本，已经成为每个使用 MySQL 的企业都必须面对的问题。更重要的是，随着数据驱动业务决策的趋势越来越明显，这些历史数据的分析价值也在不断提升，企业需要的不仅仅是"存起来"，更需要"用得着"。

MySQL 归档的技术困境与现有方案

现在 MySQL 常用于 OLTP 业务环境，一般会使用比较好的硬件资源来提供对外服务。MySQL 数据对外提供的数据动不动好几个 T 也是正常的。在很多业务中，数据有较强的生命周期，在线一段时间后，可能就失去业务意义。

典型的归档需求包括：某个业务下线后的历史数据、业务数据超过服务周期（例如某个业务只需要近 3 个月的数据）、业务操作的日志类型数据进行归档、分库分表的数据库需要合并到同一个地方提供统计查询及分析能力，以及定期的备份归档提供审计工作进行查询使用。

现在常见的归档方式一般分成两大类，核心工具通常是 pt-archive 或解析 binlog 获取归档的数据。

第一类：使用 MySQL 存储归档

这类方案中，一般是通过购买 PC 机，通常是大容量（50T左右）、大内存机型，可以跑实例，来对线上的生产库进行归档，甚至是备份同步。这种场景是最常见的，甚至见到在线下建一个主从，对 PolarDB 进行归档对外提供线下内网查询。

该方式的优点很明确：基于 MySQL 环境，大家都熟悉好管理；和线上环境基本能保持同一个版本及高度的兼容；归档环境可以使用大容量便宜的磁盘构建。

但这种归档服务也有明显的缺点：为了成本考虑，归档节点通常没开启 Binlog，真正的备份还会放到对象存储中一份，也没有从库，如果发生数据损坏或硬盘损坏，数据恢复周期长；计算能力不够，基本没有能力对计算节点扩展，如果需要计算，通常需要把数据抽出来放到大数据环境中计算；这种架构存在大量的 CPU 和 RAM 资源的闲置。

第二类：使用 MariaDB 归档

MariaDB 有一个特性：S3 engine，该引擎有较高的压缩能力，基本也保持了 MySQL 的使用习惯。归档流程是先写 InnoDB，然后 alter table tb_name engine=s3。

该方案的优点包括：基本保持了 MySQL 兼容能力、存储上支持 s3 类对象存储、支持高压缩存储。