本文最初发布于Pinterest Engineering技能博客，InfoQ 经翻译授权发布。
迁移背景与动机在 Pinterest，Hbase 一贯是我们最关键的存储后端之一，持续为浩瀚线上存储做事供应支持，涵盖 Zen（图数据库）、UMS（宽列数据存储）和 Ixia（近实时二级索引做事）。HBase 生态系统具备一系列突出上风，例如在大容量要求中保障行级强同等性、灵巧的模式选项、低延迟数据访问、Hadoop集成等，但也由于运营本钱高、过于繁芜和短缺二级索引/事务支持等问题，而明显无法知足未来三到五年内的客户实际需求。
在评估了十余种不同的存储后端选项，向三种入围方案导入影子流量（将生产流量异步复制至非生产***并开展深入性能评估之后，我们终极决定将 TiDB 选为这场统一存储做事竞赛的胜出者。
如何将统一存储做事的支持职责顺利移交给TiDB，无疑是一项须要数个季度才能完成的困难寻衅。我们须要将数据从 HBase 迁移至 TiDB，重新设计并实现统一存储做事，将 Ixia/Zen/UMS 的 API 迁移至统一存储做事，再把各种离线作业由 HBase/Hadoop 生态系统迁移至 TiSpark 生态系统——而且全体过程中，现有业务的可用性和延迟 SLA 均不能受到影响。
在本篇博文中，我们将首先磋商不同数据迁移方法及其各自利弊。之后，我们再深入探究如何将数据从 HBase 迁移至 TiDB，这也是 Pinterest 第一次以零停机办法迁移一个每秒 14000 次读取查询、400 次写入查询的 4 TB 大表。末了，我们将共同验证这套新方案能否实现 99.999%的数据同等性，并理解如何衡量两个表之间的数据同等性。
数据迁移策略一样平常来讲，零停机韶光数据迁移的履行策略可以概括为以下几点：
假定已有数据库 A，须要将数据迁移至数据库 B，则首先开始对数据库 A 和 B 进行双重写入。将数据库 A 的转储数据导入至数据库 B，并办理与实时写入间的冲突。对两套数据集进行验证。停滞向数据库 A 写入。当然，详细用例肯定各有不同，以是实际项目中每每会包含一些独特的寻衅。
我们综合考量了各种数据迁移方法，并通过以下权衡筛选最适宜我们需求的选项：
从做事向两个表（HBase 和 TiDB）实行双重写入（以同步/异步办法写入 2 个数据源），并在 Lightning 中利用 TiDB 后端模式进行数据摄取。这种办法最大略也最易行。但 TiDB 后端模式供应的传输速率仅为每小时 50 GB，因此只适宜对较小的表进行数据迁移。
获取 HBase 表的快照转储，并将来自 HBase cdc（变更数据捕捉）的数据流实时写入至 kafka 主题，而后利用 lightning 工具中确当地模式对该转储实行数据摄取。接下来，即可从做事层实行双重写入，并运用来自 kafka 主题的全部更新。
运用 cdc 更新时每每会引发繁芜冲突，因此这种方法的履行难度较高。其余，我们此前卖力捕捉 HBase cdc 的低廉甜头工具只能存储键，以是还须要额外的开拓事情才能知足需求。
另一种替代方案，便是直接从 cdc 中读取键，并将存储在另一数据存储内。接下来，在面向两个表的双重写入启动后，我们从数据源（HBase）读取各键的最新值并写入 TiDB。这种方法履行难度很低，不过一旦通过 cdc 存储各键的异步路径发生可用性故障，则可能引发更新丢失风险。
在评估了各项策略的利弊利害之后，我们决定采纳下面这种更加稳妥可靠的方法。
迁移事情流术语定义：客户端：与 thrift 做事对话的下贱做事/库
做事：用于支持在线流量的 thrift 做事；在本次迁移用例中，做事指的是 Ixia
MR Job：在 map reduce 框架上运行的运用程序
异步写入：做事向客户端返回 OK 相应，无需等待数据库相应
同步写入：仅在收到数据库相应后，做事才向客户端返回相应
双重写入：做事以同步或异步办法同时写入两个根本表
履行细节由于 HBase 为无模式（schemaless），而 TiDB 利用严格模式，因此在动手迁移之前，须要先设计一个包含精确数据类型和索引的 schema。对付我们这个 4 TB 大小的表，HBase 和 TiDB schema 之间为 1：1 映射，也便是说 TiDB 架构会通过 map reduce 作业来剖析 HBase 行中的所有列和最大列大小，之后再剖析查询以创建精确的索引。下面来看详细步骤：
我们利用 hbasesnapshotmanager 获取 HBase 快照，并将其以 csv 格式存储在 S3 内。各 CSV 行利用 Base64 编码，以办理分外字符受限的问题。接下来，我们在本地模式下利用 TiDB lightning 对这一 csv 转储实行摄取，而后进行 base64 解码，并将行存储至 TiDB 内。摄取完成且 TiDB 表上线后，即可启动对 TiDB 的异步双写。异步双写能够既保障 TiDB 的 SLA，又不影响做事 SLA。虽然我们也为 TiDB 设置了监控和分页，但此时 TiDB 仍旧以影子模式运行。利用 map reduce 作业对 HBase 和 TiDB 表实行快照保存。各行会首先被转换为一个通用工具，再以 SequenceFiles 的形式存储在 S3 内。我们利用 MR Connector 开拓了一款自定义 TiDB 快照管理器，并在 HBase 中利用 hbasesnapshotmanager。利用 map reduce 作业读取各 sequencefiles，再将不匹配的行写回至 S3。从 S3 中读取这些不匹配的行，从做事中读取其最新值（来自 HBase），再将这些值写入至辅数据库（TiDB）。启用双重同步写入，同时向 HBase 和 TiDB 实行写入。运行步骤 3、4、5 中的折衷作业，每天比较 TiDB 与 HBase 内的数据奇偶性，借此获取 TiDB 与 HBase 间数据不匹配的统计信息并进行折衷。双重同步写入机制不具备回滚功能，无法办理对某一数据库的写入失落败。因此必须定期运行折衷作业，确保两个表间数据同等。连续保持对 TiDB 同步写入，同时对 HBase 启用异步写入。启用对 TiDB 的读取，此阶段中的做事 SLA 将完备取决于 TiDB 的可用性。我们将连续保持对 HBase 的异步写入，尽可能连续保持双方的数据同等性，以备发生回滚需求。彻底停滞写入 HBase，弃用 HBase 表。如何处理不一致问题由后端不可用导致的不一致在 Ixia 做事层构建的双写框架无法回滚写入操作，这是为了防止因任一数据库不可用而导致局部故障。在这种情形下，就须要定期运行折衷作业以保持 HBase 与 TiDB 双表同步。在修复此类不一致时，主数据库 HBase 为数据源，因此一旦涌现 HBase 表写入失落败、但 TiDB 表写入成功的情形，则折衷过程会将这部分数据从 TiDB 中删除。
双重写入和折衷过程中，因竞态条件引发的不一致
如果事宜按以下顺序发生，则可能导致将旧数据写入 TiDB：（1）折衷作业从 HBase 表读取；（2）实时写入将数据同步写入至 HBase，异步写入至 TiDB；（3）折衷作业将之前读取的值写入 TiDB。
此类问题可以通过多次运行折衷作业来办理，每次折衷都能显著减少此类不一致数量。在实践中，对付支持每秒 400 次写入查询的 4 TB 表，只须要运行一次折衷作业即可在 HBase 与 TiDB 之间达成 99.999%的同等性。这项同等性指标的验证源自对 HBase 和 TiDB 表转储值的二次比较。在逐行比较之后，我们创造两表的同等性为 99.999%。
成效我们看到，第 99 百分位处的读取延迟降落至三分之一到五分之一。在本用例中，第 99 百分位的查询延迟从 500 毫秒低落至 60 毫秒。实现了写后读取同等性，这也是我们希望通过更换 Ixia 达成的主要目标之一。迁移完成后，全体架构更大略、涉及的组件数量更少。这将极大改进对生产问题的调试流程。寻衅与心得内部 TiDB 支配由于我们没有利用 TiUP（TiDB 的一站式支配工具），以是 Pinterest 根本举动步伐中的全体 TiDB 支配流程成了我们一次宝贵的学习经历。之以是没有选择 TiUP，是由于它有很多功能都跟 Pinterest 内部系统相互重叠（例如支配系统、运营工具自动化做事、量化管道、TLS 证书管理等），而综合二者间差异的本钱会超出利用收益。
因此，我们决定连续掩护自己的 TiDB 版本代码仓库和构建、发布与支配管道。集群的安全管理绝非易事、涉及大量细节，如果我们自己不努力探索，就只能把这些事情一股脑交给 TiUP。
现在我们拥有了自己的 TiDB 平台，构建在 Pinterest 的 AWS 根本举动步伐之上。我们可以在个中实现版本升级、实例类型升级和集群扩展等操作，且不会引发任何停机。
数据摄取在数据摄取和折衷过程中，我们也碰着了不少现实问题。感谢 Pingcap 在各个环节中供应的全力支持。我们也为 TiDB 代码库贡献了一些补丁，这些成果已经由上游社区完成了合并。
TiDB lightning 5.3.0 版本不支持自动刷新 TLS 证书，而且由于短缺干系日志而难以调试。Pinterest 的内部证书管理做事则每 12 小时刷新一次证书，以是期间总会发生一些失落败的摄取操作，只能依赖 pingcap 来办理。好在证书自动刷新功能现已在 TiDB 5.4.0 版本中正式发布。Lightning 确当地模式会在数据摄取阶段花费大量资源，并影响到同一集群上运行的其他表的在线流量。为此，Pingcap 与我们开展互助，对 Placement Rules 做出了短期和长期修复，因此支持在线流量的副本已经不会受到本地模式的影响。TiDB MR Connector 须要进行可扩展性修复，才能把 4 TB 表的快照保存韶光掌握在合理范围。此外，MR Connector 的 TLS 也有改进空间，目前这些改进贡献已经完成了提交及合并。
在调优和修复之后，我们已经能够在约八小时之内摄取 4 TB 数据，且每轮折衷和验证运行只须要七小时旁边。
Ixia在本轮迁移中，我们的表由 ixia 卖力支持。期间，我们在异步/同步双重写入和查询模式变更中碰着了几个可靠性问题。由于 ixia 本身的分布式系统架构非常繁芜，导致 thrift 做事（ixia）极难进行调试。感兴趣的朋友请参阅我们的其他博文以理解更多细节。
鸣谢这里，我们要感谢 Pinterest 存储和缓存团队的各位前成员和现同事，感激大家在这场将最新 NewSQL 技能引入 Pinterest 存储堆栈的攻坚战中做出的卓越贡献。
我们还要感谢Pingcap团队为各类繁芜问题供应的持续支持、联合调查和根本缘故原由剖析（RCA）。
末了，我们要感谢各位客户在这次大规模表迁移过程中表现出的耐心和支持。感激您的理解与合营！
原文链接：
https://medium.com/pinterest-engineering/online-data-migration-from-hbase-to-tidb-with-zero-downtime-43f0fb474b84
