--- title: 'MySQL 到 TiDB 迁移实践：云盛海宏零售业海量场景下 ToC 系统的选型思考与经验分享' date: '2024-02-05T22:15:26+08:00' status: publish permalink: /blog/mysql-migrate-to-tidb-in-wonhigh author: '周, 盛虎' excerpt: '本文来自 InfoQ，作者云盛海宏 ToC 业务团队崔文涛、邓有才，介绍了其 To C 系统数据库选型背景、测试方案、应用改造及生产切换效果。' type: post id: 6274 category: - 案例实践 tag: - MySQL post_format: [] profile: - 崔文涛 - 邓有才 --- > 本文来自 InfoQ，作者云盛海宏 ToC 业务团队崔文涛、邓有才。 云盛海宏是一家零售业科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务中国 6000 余家的线下门店和千万级别的线上会员。云盛海宏的 To C 系统分为私域商城和会员营销两条业务线，它为 7000 多万注册会员提供了丰富的权益和服务，是我们非常核心的系统。 选型背景 ---- 随着近几年消费模式的升级，我们和消费者的互动与服务从传统线下逐渐延展至线上，使得 To C 系统的能力和规模越来越大，其数据库压力也越来越大。 最初在建设 To C 系统时，业务库主要使用 MySQL，既有单库架构，也有分库分表架构，时至今日我们面临的问题主要如下： 1. 分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整 ● 分库分表规则为品牌名称，而不同品牌之间数据规模、用户规模有较大差异 ● 需要针对大分片再次进行二次拆分才能解决该问题，但同时复杂度将大幅提升 2. 个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显 ● 数据量千万级以上表：87 张；亿级以上表：21 张 ● 需要将单库架构改造成分库分表架构才能解决 以上两个问题均需要大幅调整数据库架构来解决，解决成本高（人力、硬件），并且未来还可能再次面临这样的问题。为彻底解决以上问题，我们计划直接切换到原生分布式数据库 TiDB： 1. TiDB 兼容 MySQL 协议，并且是原生分布式，无需规划分片规则，对应用友好，能够很好的解决之前分库分表数据倾斜的问题 2. TiDB 架构下提供的动态水平扩展、热点自动调度等能力，大幅简化了一系列运维成本，能够支撑应用规模持续的增长，即使数据增长超过预期也能动态增加节点解决 3. 另外我们的零售系统在去年成功切换到 TiDB，也给了我们团队很大的信心 数据库测试方案 ------- 对于数据库的切换我们比较关心以下几个问题： 1. 迁移数据的完整性：数据是企业的核心资产，不容许丢失 2. SQL 兼容性及性能：这意味着我们迁移改造的成本 3. 资源隔离能力：多个业务库合并后如何保障其服务质量 测试目的：识别关键问题，基于测试结果完善应用改造 ### 测试一：迁移数据的完整性 **1.1 数据同步** TiDB 提供 DM 数据同步工具，该工具支持 MySQL 全量、增量数据的同步，同时也支持分库分表的合并。对于分库分表的合并，我们的任务策略如下： ![任务策略](https://img1.pingcap.com/files/2024/02/20240206133643318.png)**1.2 数据比对** 为确保 DM 数据同步工具的可靠性，在切换过程中需要进行数据一致性校验。实测数据比对效率较高，能够达到 400MB/s 以上的全量比对速度，以下是数据比对映射关系： ![数据比对映射关系](https://img1.pingcap.com/files/2024/02/20240206133715237.png)### 测试二：SQL 兼容性及性能 针对生产的全量 SQL 语句进行兼容性以及性能的测试，靠人力手工完成测试是不现实的，所以我们引入了 Percona 开源的 playback 工具进行测试。 **2.1 playback SQL 回放工具经验分享** playback 工具介绍 项目地址： ![playback 工具介绍](https://img1.pingcap.com/files/2024/02/20240206133806886.png)- SQL 录制：MySQL 数据库在开启慢查询功能时，会将慢 SQL 输出到慢查询日志 - SQL 回放：playback 工具解析慢查询文件中的 SQL，并连接到目标数据库进行回放 - 报告展示：回放完成会输出报告（执行失败的 SQL 含结果不一致等、性能数据） 实际测试流程 由于我们是存在分库分表架构，而 TiDB 中存储的都是单表，所以我们步骤进行了一些调整： - SQL 录制：将生产 MySQL 库的 long\_query\_time 设置为 0，运行一个业务周期（一天），记录一天内所有 SQL（样本数越大测试结果越准确） - SQL 处理 ：部分慢查询日志未记录 schema 信息，通过脚本指定 schema（还存在将 db\_1 映射成 db 这样的 schema 转换） - SQL 回放：指定慢查询回放整个业务周期运行的 SQL 语句 回放结果分析 测试结果汇总 ![测试结果汇总](https://img1.pingcap.com/files/2024/02/20240206133941220.png)由于私域商城大表十分多，所以性能提升非常明显，2.5 亿条 SQL 的总执行时间约之前的 1/6；而会员运营之前进行过拆分，7376 万条 SQL 的执行总时间约之前的 1/2。 **错误详情分析**： - 会员运营： - 1 处业务 SQL 错误：“during query: Data too long for column”，原因字段精度不够，调大后解决，其余业务 SQL 均兼容 - 剩余 1220855 次均为非业务 SQL 的报错：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等 - 私域商城： - 无业务 SQL 错误，业务 SQL 均兼容 - 所有错误均为非业务 SQL：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等 **兼容性基本没有问题** **性能详情分析**： 虽然总体执行时间缩短了，但我们还是需要排查下性能退化的 SQL 是哪些，需要保证原本正常的 SQL 还是要处于在一个基本对用户无感知的响应时间范围。 理论上来说， 小于 100ms 的 SQL 基本都不影响前端用户的体验，所以分析时可以忽略这一部分的 SQL；而对于 100ms-1s 的 SQL，可能会影响用户体验，需要关注；1 秒以上时基本上用户感知非常明显。 ![性能详情分析](https://img1.pingcap.com/files/2024/02/20240206134155783.png)通过详细性能分析数据以及 SQL 回放执行总耗时，我们不难发现： 1. 由于 TiDB 是存储计算分离的分布式架构，1000us 内的 SQL 数很少，基础操作（如 show variables/start transaction/set ... 等）执行时间均高于 MySQL；同时另一个极端，大于 10 秒以上的 SQL 数，两个系统在 TiDB 中下降了一个数量级。 2. 通过一些采样分析，我们发现在 TiDB 中一些 commit/rollback 操作的时间也普遍高于 MySQL，个别操作从几百微秒变成几十 / 几百毫秒。查阅了 TiDB 中的事务机制，发现 TiDB 提交成本高于 MySQL，首先是 2PC 跨节点事务，另外就是事务中的脏数据直到 commit 时才开始刷到存储（计算节点 ->存储节点），对于这种类型的 SQL 在性能分析时也可以忽略掉。 3. 我们将样本数据整理成桑基图，将这部分性能退化、并且影响用户体验的 SQL 识别出来，进行分析和优化 ![会员运营中 SQL 性能数据桑基图](https://img1.pingcap.com/files/2024/02/20240206134231428.png)以上为会员运营中 SQL 性能数据桑基图，如红色箭头以及红色框的这些 SQL，需要重点分析 ![会员运营中原本 10 秒以上 SQL 性能变化](https://img1.pingcap.com/files/2024/02/20240206134334142.png)以上为会员运营中原本 10 秒以上 SQL 性能变化 4. 私域商城的 SQL 性能提升很明显，100ms 内 SQL 数量均高于 MySQL，同时 1s 以上的 SQL 少于 MySQL，说明用户体验提升明显。但还是需要根据桑基图来分析是否存在异常的 SQL ![私域商城系统 SQL 性能桑基图](https://img1.pingcap.com/files/2024/02/20240206134416260.png)以上为私域商城系统 SQL 性能桑基图，红框对应的 SQL 应该重点分析 ![私域商城原本 10 秒以上 SQL 性能变化](https://img1.pingcap.com/files/2024/02/20240206134441118.png)以上为私域商城原本 10 秒以上 SQL 性能变化 ### 测试三：资源隔离能力 资源隔离能力在我们这边的用途： - 系统间资源隔离：多个 MySQL 库上的应用系统合并到一个 TiDB 时，如何保障各个系统在业务高峰期的可用资源 - 系统内资源隔离： - 当某个系统中出现一个大查询时，如何限制其资源消耗，避免对该应用、对整个集群造成影响 - 当某个系统中批量调度作业到白天还没跑完时，如何限制其资源消耗，避免对白天业务造成影响 - 其他场景的资源隔离 - 应用监控等定时调度操作往往比较复杂，如何限制其运行时的资源消耗 - 客户端数据查询场景难以避免 SQL 条件不规范的情况，当出现这种情况时，如何避免人工查询导致的系统不可用 为解决以上几种问题，需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能，该功能能够实现： - 按用户设置资源规格 - 按会话设置资源规格 - 按 SQL 设置资源规格 以下是用户级别测试效果： 为数据库压测用户指定其 RU 为 500，并使用 Jmeter 压测应用，观察 TiDB 数据库是否能够限制资源，并且在达到资源限制时，应用是否报错。 ![Jmeter 压测应用](https://img1.pingcap.com/files/2024/02/20240206140613520.png)该用户在达到 500RU 时，使用值轻微超过限制值，基本符合预期。 ![压测结果](https://img1.pingcap.com/files/2024/02/20240206140641196.png)应用改造 ---- **1 分页 SQL 增加排序条件** 这也是几乎所有的 MySQL 系统迁移到 TiDB 会遇到的问题： 当 SQL 中无显示排序条件时，返回结果无顺序保障，这将导致分页结果不可靠 我们大概梳理了系统中存在的分页 SQL，大概 1600 余条，最终改造 + 测试工作量约 2 个月 **2 性能退化的 SQL 优化** 如特定的表关联方式，执行计划是全表扫描 `MARKDOWN_HASHacf67ca9b556dbac39985c0a6fe71088MARKDOWNHASH`shop\*\*\*\*\_id`) AND shop_****_id IN ( ... );` 改写成 `MARKDOWN_HASH7730c0ee75ccaab37e70e66a0e559c78MARKDOWNHASH`shop\*\*\*\*\_id` GROUP BY shop_****_id) AND shop_****_id IN (...);` **3 从分库分表处理逻辑改成单库处理逻辑** 业务 sql 中存在批量查询、批量更新的场景，调整成按照用户链接维度设置 batchquery **4 数据回写改造** 应用切换到 TiDB 前，需要将 TiDB 的增量数据写回到 MySQL，保障紧急情况下的可回退： 之前是单库的场景，可以直接使用 TiCDC 提供的 mysql sink 完成回写。 分库分表的场景下，TiCDC 并不能直接写 MyCAT 组件；所以我们先将增量数据通过 TiCDC 发送给 Kafka，再消费写入到 MyCAT 下的分片中。 **5 下游订阅改造** TiDB 不兼容 MySQL Binlog，原本的消息订阅链路（Binlog/canal/kafka）需要换成 TiCDC->Kafka 这条链路，TiCDC 提供 canal-json 格式的兼容，消费程序上要基于 TiCDC 的消息格式进行一定的调整。 生产切换效果 ------ 我们于双十一之前的两周完成消息中心等系统（4 个 MySQL 库）的切换，切换到 TiDB 后经受住了双十一大批量消息推送的验证，也增强了我们的信心。 在元旦后第一个工作日进行了私域商城系统（16 个 MySQL 库）的切换，切换过程比较顺利。以下是切换后第一个工作日的业务高峰，最大 QPS 4.4 万，P95 响应延迟 3.9ms，整体运行良好。 ![切换效果](https://img1.pingcap.com/files/2024/02/20240206140915606.png)1.8 日某品牌大促，业务量是平时的一倍，数据库最大 QPS 6.5 万，P95 响应延迟 3.9-4.5ms 之间： ![品牌大促](https://img1.pingcap.com/files/2024/02/20240206140949940.png)以下是切换 TiDB 的整体流程，可以看到切换到 TiDB 后了简化了其架构：由于 TiDB 无需设置分片规则，数据都在一个集群中，原本综合库（MySQL 单库）上的查询也直接切到 TiDB 中。 ![生产切换流程](https://img1.pingcap.com/files/2024/02/20240206141019285.png)以上为生产切换流程 总结 -- 数据库迁移是一个复杂且高风险的工程，迁移前规划一个全面的测试方案必不可少，提前识别迁移风险，大幅降低迁移后的风险，当然像分阶段迁移、回退链路等保障措施也及其重要。 年后我们将继续把会员运营系统（20 个 MySQL 库）切换至 TiDB，实现 To C 系统从 MySQL 40 个库到 TiDB 的整体切换，支撑未来持续增长的数据规模。