从 Oracle 到 TiDB 丨数据库资源评估指南

本文作者：柳冬冬

导读

在当今技术飞速发展的时代，传统单机数据库正面临着前所未有的挑战。随着人工智能、云计算和大数据的崛起，企业对数据库的性能、可靠性和扩展性的需求日益增长，分布式数据库取代传统集中式数据库的必然趋势。

本文将详细介绍企业如何通过资源评估、迁移策略和架构优化，顺利实现从 Oracle 等传统数据库向 TiDB 的平稳过渡，进而满足关键业务需求，实现降本增效的目标。

*全文约 8,000 字，速读约 10 分钟

分布式数据库替换，集中式数据库是大势所趋

在人工智能、云计算和大数据技术的浪潮推动下，企业对数据库的性能和可靠性需求不断攀升。传统单机 Oracle 数据库在处理大规模数据和高并发请求时，其容量和性能的瓶颈日益凸显，加之昂贵的许可费用和维护成本，使得企业面临越来越大的挑战。与此同时，分布式数据库凭借其出色的可扩展性、高效的处理能力、高可用性以及成本效益，满足了各行业日益增长和多样化的数据处理需求，成为数据库技术演进的主流趋势。从技术趋势、性能需求、成本效益以及国家政策导向等多个维度来看，使用国产分布式数据库替换传统单机数据库，已是大势所趋。

越来越多的企业级用户将 Oracle 数据库迁移到 TiDB 分布式数据库，以满足关键业务对高性能、动态扩展和高可用性的需求，并实现降本增效的目标。资源评估是 Oracle 数据库迁移到 TiDB 的首要关键步骤，可以帮助企业合理规划迁移资源，通过进行资源评估、制定迁移方案、选择合适的迁移工具，可以确保迁移成功，并充分发挥 TiDB 的优势，为企业提供更强大的数据库服务，同时，对于上线后的 TiDB 业务系统，通过全面的备份资源评估，也可以制定合理的备份策略，充分利用资源，并确保备份的完整性以及灾难发生时的备份可用性。

资源评估是 Oracle 迁移至 TiDB 数据库的首要关键步骤。文本旨在为从 Oracle 向 TiDB 数据库迁移的用户提供一份详尽的资源评估指南，结合头部保险公司的实际应用经验，详细介绍 Oracle 数据库的资源评估方法，覆盖项目投产上线前的 TiDB 集群资源评估以及投产上线后的备份资源评估。

Oracle 与 TiDB 架构对比

2.1 Oracle RAC 架构介绍

Oracle RAC 架构，它允许多个 Oracle 数据库实例在多台服务器上共享同一个数据库存储空间，并通过集群来保证高可用性和容错性。简单来说，RAC 就是将多个数据库实例连接起来，形成一个集群，可以在任何节点上访问到完整的数据库内容。

Oracle RAC 由多个数据库实例组成，其中每个实例都运行在不同的服务器节点上。节点之间通过网络通信，每个实例都可以访问数据文件、控制文件、归档日志和参数文件等共享资源。在 RAC 架构中，数据库和应用程序是分离的，应用程序只需要连接到任何一个数据库实例即可，当有节点故障时，连接会自动定向到其他节点上。

Oracle RAC 架构虽然采用了存算分离的架构，但是数据存储依然集中在一个 RAC Database 中，存储和 I/O 能力的扩展依然需要通过升级硬件实现横向扩展，并且需要 Oracle Dataguard 架构搭建备库来保护数据。

2.2 TiDB 架构介绍

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

• **TiDB Server **( https://docs.pingcap.com/zh/tidb/stable/tidb-computing )：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

<!---->

• PD (Placement Driver) Server
• ( https://docs.pingcap.com/zh/tidb/stable/tidb-scheduling )：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

<!---->

• TiKV Server ( https://docs.pingcap.com/zh/tidb/stable/tidb-storage )：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
• TiFlash ( https://docs.pingcap.com/zh/tidb/stable/tiflash-overview )：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

<!---->

• 存储节点

TiDB 原生分布式架构设计在处理大规模数据、高并发、弹性伸缩、容错和高可用性、简化运维管理、多租户和资源隔离、与云基础设施的无缝集成以及支持现代应用架构等方面具有显著的优势。

TiDB 集群资源评估方法

3.1 TiDB 集群资源评估概览

根据项目实践经验，总结了 Oracle 的总数据量和、QPS 与 TiDB 数据库的对应比例关系，结合 Oracle 和 TiDB 数据库的基本信息和应用场景，形成下表的对比参照。

3.2 TiKV 服务器数量评估

3.2.1 评估标准

为了确保数据库系统的稳定运行、满足业务增长需求并降低运维成本，通常从集群容量的角度进行 TiKV 节点的资源评估，并且预留未来两年的空间增长：

• **评估目的：**确保数据库集群拥有足够的存储空间，避免因空间不足导致性能下降或数据丢失风险。预留合理的空间，为未来业务增长提供缓冲，降低后期扩容成本。
• **核心指标：**实际数据量 + 未来两年预期增长量 < 总存储空间 * 80%

通常预留的磁盘空间建议 200GB-400GB 之间，因为不同规格的盘浪费的空间会有很大差异，比如 2 TB 磁盘的预留剩余空间为 2TB （1-0.8）= 400GB，4 TB 磁盘的预留剩余空间为 4 TB （1-0.8）= 800GB，为了避免资源浪费，可以在空间使用率可接受范围内动态调整剩余空间大小，此处统一按照可用空间不超过总存储空间的 80% 来规划使用。

3.2.2 Oracle 与 TiDB 数据量大小比例关系

为确保 Oracle 数据库迁移至 TiDB 的顺利实施，建议遵循以下精细化评估流程和专业化建议：

• **副本策略评估：**根据业务类型、项目重要级别以及具体的可用资源情况，科学选择合适的 TiDB 副本策略。
• **高可用场景：**对于关键业务系统或高可用性要求较高的项目，建议采用 TiDB 5 副本策略。5 副本架构提供更高的数据冗余和故障恢复能力，即使任意 2 副本出现故障，也能确保数据安全和业务连续性。
• **一般场景：**对于非关键业务系统或对可用性要求不高的项目，可以采用 TiDB 3 副本策略。3 副本架构在降低成本和资源消耗的同时，也能提供良好的数据安全性和可用性。
• **数据容量评估：**根据选择的副本策略，精细评估 Oracle 数据量与 TiDB 数据量之间的关系，合理预留存储空间。
• **TiDB 5 副本：**Oracle 数据量与 TiDB 数据量之比约为 1:1.5。这意味着 TiDB 5 副本需要比 Oracle 更大的存储空间，以容纳额外的副本数据。建议在评估过程中考虑历史数据增长率、压缩率等因素，预留充足的空间以满足未来需求。
• **TiDB 3 副本：**Oracle 数据量与 TiDB 数据量之比约为 1:1。这意味着 TiDB 3 副本与 Oracle 所需的存储空间大致相同。建议根据实际情况和成本预算，选
• 择合适的存储方案。

3.2.3 单台服务器 TiKV 实例数量

根据服务器硬件指标 CPU 数量、内存大小、磁盘数量合理规划单台服务器 TiKV 实例数，根据实践经验建议 TiKV 单实例资源至少是 16C/64GB，所以可以根据对 ”总逻辑 CPU 数量/16“、”总内存大小/64“、”磁盘总数量“ 取最小值的方式来评估单台服务器 TiKV 实例数量，也就是 min(总逻辑 CPU 数量/16,总内存大小/64,磁盘数量)。

3.2.4 TiKV 服务器数量计算

TiKV 服务器数量

=（总存储空间/(Oracle 与 TiDB 数据量比例关系)） /（单个 TiKV 实例磁盘大小单台服务器 TiKV 实例数80%）

=（总存储空间/(Oracle 与 TiDB 数据量比例关系)） /（单个 TiKV 实例磁盘大小min(总逻辑 CPU 数量/16,总内存大小/64,磁盘数量)80%）。

3.3 TiDB 服务器数量评估

3.3.1 评估标准

为了确保数据库系统的稳定运行、满足业务增长需求并降低运维成本，通常从集群 QPS 和 TiDB 节点的 CPU 使用率、内存使用率、连接数等角度进行 TiDB 节点的资源评估。由于 TiDB 服务器资源能力的差异，以及业务场景的差异，很难精确评估出具体需要多少 TiDB 资源，需要根据 TPCC 基准测试、业务实际性能测试结果来具体分析每个 TiDB 实例的处理能力，并结合业务压力总 QPS 来计算出需要使用多少 TiDB 实例。

• 核心指标：CPU 使用率峰值低于企业安全生产阈值。

首先要确保数据库集群拥有足够的业务承载能力，避免由于 TiDB 节点负载过高影响业务正常使用；此外需要预留合理的空间，避免大促或者业务快速增长导致达到业务峰值。以下因素会影响 TiDB 数量的评估结果：

**服务器规格：**更强的服务器可以支持更大的 QPS 和更低的延迟。

**业务类型：**OLTP 密集型业务需要更多的 TiDB 节点，而 HTAP 密集型业务需要更多的 TiKV 和 TiFlash 节点。

**批处理作业：**如果存在批处理作业，需要考虑 OLTP 业务和批量作业在 TiDB 层面进行物理隔离，避免互相影响。

3.3.2 TiDB 总 QPS 计算

通过 Oracle AWR 报告可以查看 Oracle 系统总 QPS 数据，普通 OLTP 业务场景下 Oracle QPS 与 TiDB QPS 比例大约为 1:1。Oracle QPS 主要参考 AWR 报告中 Load Profile 模块的 Executes (SQL) 指标。

3.3.3 单个 TiDB 实例 QPS 计算

根据实际的业务性能压测，基本可以判断出整体的业务模型，比如通过分析 Grafana 监控指标 QPS 面板，可以评估出该业务的读写分布比例，并且可以通过监控指标 Affected Rows By Type 面板针对写业务评估出具体的 INSERT、UPDATE 、 DELETE 等 DML 操作的比例分布情况。

通常业务性能测试会覆盖 50%~60% 的业务场景和业务负载情况，无法完全模拟真实生产业务负载，但是可以通过性能测试过程调整并发来评估出单个 TiDB 实例的处理能力，比如随着负载压力的增大，TiDB 实例的 CPU 使用率最高达到企业安全生产阈值，也就是正常运行态此阈值下可承受业务高峰期的业务冲击，比如该生产阈值为 40%，此时可以认为该 TiDB 实例的 QPS 值为推荐值。

由于性能测试模拟的是日常业务高峰期流量，但是业务特殊时间点存在业务负载翻倍的情况，比如保险行业的开门红活动，所以测试过程中认为 TiDB CPU 使用率达到 40% 就是日常高峰期最大值了，这样在业务负载翻倍的情况下，相对线性的比例计算，TiDB 的 CPU 使用率会达到 70% 左右，企业安全生产阈值极值，而当这种极端情况发生时，可以通过动态扩容来紧急处理，得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

综上所述，计算单个 TiDB 实例的 QPS 推荐值，通常是在性能测试期间，TiDB 实例的最高 CPU 使用率达到企业安全生产阈值的场景下，来对应的查看 TiDB 实例的 QPS 当前值而得出的结论，从而最大程度保障业务高峰期所有业务的正常运行。如果某些业务场景绝大部分情况下业务压力相对平稳，极少情况下出现业务高峰，此时可以考虑根据 TiDB 实例的平均 CPU 使用率达到企业安全生产阈值的场景下，来对应的估算 TiDB 实例的 QPS 值为推荐值。

3.3.4 单台服务器 TiDB 实例数量

单台服务器 TiDB 实例数的评估需要结合连接数和 CPU 情况来具体分析：

通常情况下，可以按照 CPU numa 数量来 1:1 的规划 TiDB 实例数，这样可以避免跨 numa 访问，提升 TiDB 实例 CPU 使用性能，比如鲲鹏服务器 CPU 配置是 128C，4 个 numa（2 Sockets），那么 TiDB 实例可以考虑单机 4 实例。

对于业务体量较大，业务重要级别较高，且硬件资源相对充足的情况下，可以考虑按照物理 CPU 的个数来划分，使资源使用率维持在一个相对较低的水平，以应对更加复杂的业务逻辑和关键节点的超高业务流量，比如海光服务器 CPU 资源配置是 128C，两个物理 CPU（Sockets），8 个 numa，那么 TiDB 实例可以设置为单机双实例。

3.3.5 TiDB 服务器数量计算

TiDB 服务器数量=总 QPS /（单个 TiDB 实例推荐 QPS*单台服务器 TiDB 实例数）。

3.4 PD 服务器数量评估

3.4.1 评估标准

• **核心指标：**依据业务系统重要级别以及高可用需求，并满足 CPU 使用率峰值

低于企业安全生产阈值。

3.4.2 PD 服务器数量计算

根据业务类型、项目重要级别以及具体的可用资源情况，科学选择合适的 PD 副本策略：

**高可用场景：**对于关键业务系统或高可用性要求较高的项目，建议采用 5 实例策略。5 实例架构提供更高的安全性和故障恢复能力，确保业务的连续性。

**一般场景：**对于非关键业务系统或对可用性要求不高的项目，可以采用 3 实例策略。3 实例架构在降低成本和资源消耗的同时，也能提供良好的数据库连续性和可用性。

通常情况下使用 3 台 PD 服务器即可，可与 TiDB 节点进行混合部署，若业务压力大，PD 节点 CPU 使用率达到企业安全生产阈值以上，建议将 PD 节点部署在独立的服务器上，以避免与 TiDB 节点竞争资源。建议项目正式投产上线之前，使用 TiDB 压测工具进行基准性能测试并根据根据项目实际的性能压测指标环境 判断整体资源情况，更加精细合理的对 PD 节点数进行评估。

头部保险公司从 Orace 迁移至 TiDB 资源评估实践

4.1 业务场景和 Oracle 生产集群基本信息

保单系统是保险公司最重要的核心系统，负责保险业务的投保、承保、批改等功能，为所有内外部承保渠道及其他系统提供服务支撑。对于超大型保险公司的保单业务而言，数据量大，负载高，逻辑复杂，经常出现单条 SQL 长达数千行的情况。鉴于原有双节点 Oracle RAC 的写入性能不足，以及其他业务系统对 HTAP 能力的需求，加之对自主可控的综合考量，该头部保险公司启动了保单核心系统的迁移工程，从 Oracle 转向 TiDB，以期提升性能、增强系统的灵活性和可控性。原有 Oracle 生产集群的基本信息如下：

**总数据量：**Oracle 数据库集群总大小约为 57TB，可以通过系统表 dba_segments 来直接进行统计，包括表数据、索引、分区、大字段等内容。

SYS@xxx> select segment_type ,sum(bytes)/1024/1024/1024 from dba_segments where owner='POLICY' group by segment_type;

SEGMENT_TYPE                         SUM(BYTES)/1024/1024/1024
------------------------------------ -------------------------
INDEX                                               22887.7479
INDEX PARTITION                                     534.651794
LOBINDEX                                            .006652832
LOBSEGMENT                                           4.5736084
TABLE                                                29384.197
TABLE PARTITION                                     4379.71582
-------------------------------------------------------------- 
TOTAL                                               57286.895565232
6 rows selected.

**数据增长量：**该业务系统数据未来两年的空间增长量约为 12TB，依然可以通过系统表 dba_segments 对具备代表性的常规业务运行阶段进行分析统计，比如统计周期为一周，通过计算周期内的均值得到数据日增长量，进而计算出月增长量、年增长量等。

4.2 Oracle 迁移至 TiDB 资源评估

4.2.1 TiDB 集群服务器配置

4.2.2 TiKV 服务器数量规划

• 评估数据量

从原有的 Oracle 数据库基本信息中可以得出结论：基础数据量为 57TB，数据月增长量为 0.5TB，未来空间预留周期 2 年，两年后保险集群 A 总数据量:

= 57TB(基础数据量)  1.5(五副本 O2T 数据量比例) + 0.5TB(数据月增长量)12(每年 12 个月)2（未来 2 年） 1.5(五副本 O2T 数据量比例)

= 57B1.5+0.5TB1221.5

= 103TB

• 计算 TiKV 服务器数量

通过计算 min(总逻辑 CPU 数量/16,总内存大小/64,磁盘数量)=min(128/16,512/64,4)=4，得出结论，TiKV 可以按照单机 4 实例计算，每台服务器 4 块 nvme 磁盘，每块磁盘 1.4 TB 空间，那么每天服务器总空间为 1.44=5.6TB，按照资源评估规则，空间使用率不超过 80%，得出每台服务器可用空间为 1.44*0.8=4.48T；

所以，需要的 TiKV 服务器数量为：

=两年后保险集群 A 总数据量/每台服务器可用空间

=（总存储空间/(Oracle 与 TiDB 数据量比例关系)） /（单个 TiKV 实例磁盘大小单台服务器 TiKV 实例数80%）

=（总存储空间/(Oracle 与 TiDB 数据量比例关系)） /（单个 TiKV 实例磁盘大小min(总逻辑 CPU 数量/16,总内存大小/64,磁盘数量)80%）

= ((57+0.5122)/(1/1.5)) / (1.4min(128/16,512/64,4)0.8)

= 103/(5.6*0.8)=22.9 台；

由于 TiDB 集群采用五副本，所以 TiKV 的数量按照 5 的倍数规划便于打 label 标签，合理的进行数据平衡分布，所以大约需要 25 台 TiKV 服务器。

4.2.3 TiDB 服务器数量规划

该业务系统为 OLTP 场景，可以根据资源评估规则中的通用场景来评估 TiDB 的服务器数量，TiDB 服务器数量和 TiKV 服务器数量关系约为 2:3；因此需要 TiDB 服务器数量大约是 25*（2/3）≈16 台。

• 计算 TiDB 总 QPS

Oracle 两节点 RAC 集群，总 QPS=节点 1QPS+节点 2QPS= 31973，根据上述评估规则，可以评估出 TiDB 总 QPS 约为 3.2w。

• 单个 TiDB 实例 QPS 推荐值评估

通过性能压测可以发现，在 TiDB 实例的 CPU 平均使用率为 3% 的时候，TiDB 实例的 CPU 最高使用率可以达到 40%，此时 TiDB 实例的 QPS 值约为 800，该值即为单个 TiDB 实例 QPS 推荐值。

CPU 使用率查看

通过调整 Grafana 监控中 TiDB 组件里的 CPU Usage 面板，可以查看 CPU 的最大使用率和平均使用率；设置 Left Y 将 CPU 显示比例设置为 0-100；在右侧 Legend 模块里打开 Max 和 Avg 按钮，显示最大值和均值；

从监控面板可以看到，CPU 最高使用率为 40% ，即达到了企业生产安全阈值，CPU 使用率整体趋势在 30% 以下，而 CPU 平均使用率只有 3% 左右。依据上述评估标准，TiDB 实例的 CPU 最高使用率达到企业生产安全阈值的时候，此时的 TiDB 实例 QPS 平均值即为生产环境单个 TiDB 实例的 QPS 推荐值，所以接下来要查看 QPS 相关具体信息。

TiDB 单实例 QPS 查看

通过调整 grafana 监控，TiDB 模块中 Query Summary 的 CPS By Instance 面板；在右侧 Legend 模块里打开 Avg 按钮，即可显示该时段 QPS 平均值为 800 左右。

• 业务分布特征

在完成全流程的业务性能测试之后，通过查看 Grafana 监控面板，可以看到整体的业务分布特征，比如具体的读写分布情况，而在资源评估的过程中，参考业务分布特征相近系统的资源评估方式，将更加具有实用性和代表性。

读写分布：

根据 QPS 分布情况可以得出读写分布结论。

写类型分布

根据 Affected Rows By Type 面板指标情况，可以得出写类型比例分布结论。

• 单台服务器实例数量评估

CPU 具体信息如下，该服务器 CPU 共有两个 Socket，且系统重要级别很高，硬件资源相对充足，综合考虑 CPU 使用率和连接数分布情况，建议 TiDB 实例采用单机双实例。

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    2
Core(s) per socket:    32
Socket(s):             2
NUMA node(s):          8

• TiDB 服务器数量计算

通过上述评估过程，可以得到 QPS 分布和 CPU 使用率等基本信息，在 CPU 最高使用率达到企业生产阈值 40% 的情况下，TiDB 实例的 QPS 平均值可以达到 800，所以可以认为该业务场景下，单个 TiDB 实例 QPS 为 800 是一个相对合理的推荐值，在此基础上计算 TiDB 服务器的数量。

根据 TiDB 服务器数量评估规则，可以计算出需要 20 台 TiDB 服务器：

TiDB 服务器数量：

= TiDB 总 QPS /（单个 TiDB 实例 QPS 推荐值*单台服务器 TiDB 实例数）

= 33k /（800*2）

≈ 20 台

4.2.4 PD 服务器数量规划

由于保险集群 A 业务压力很大，日常高峰期 QPS 在 50k 左右，PD 节点调度压力也会随之增大，在性能压测阶段，将 TiDB 节点与 PD 节点混合部署，发现服务器 CPU 使用率很高，达到了 60% 以上，所以建议单独拿出 3 台服务器部署 PD 组件，单独部署的 PD 节点 CPU 使用率在 20% 左右。

4.3 TiDB 集群资源评估结论

根据上述评估结论，TiDB 集群整体服务器资源规划如下表所示。由于该业务系统重要性级别非常高，而且资源相对充足除了日常业务高峰期要保障系统的稳定运行以及业务指标在合理范围内之外，在重大业务活动期间，业务体量会呈现翻倍趋势，所以系统资源使用情况需要有一定的预留和应急空间，所以最终采用的评估方案时根据按照业务高峰期最高 CPU 使用率来评估的 TiDB 组件。

另外，TiDB 支持水平扩缩容，用户可以很方便根据业务的需要对计算层或者存储层扩缩容，以应对突发的业务压力和数据库性能瓶颈。TiDB 具有动态扩缩容的便利性，一方面，业务的增长总是突然且快速的，对业务无感知的扩容，可以让业务人员投入更多的精力到业务迭代中去，而不用被复杂的数据库扩容迁移任务所打扰，另一方面，假设因为不可抗力，业务增长不符合预期，那么也可以动态缩容节省成本。

4.4 常见金融业场景的 TiDB 集群资源最佳配置

业务模型的评估对整体的资源评估具有重大参考意义，下表是在项目实践中总结出来的面向各业务场景的 TiDB 集群最佳配置，可供参考：

TiDB 集群备份资源评估方法

5.1 TiDB 集群备份资源评估概览

备份资源评估是制定有效备份策略的重要组成部分，旨在评估现有资源满足备份需求的能力，并识别潜在的瓶颈和优化机会。针对数据库备份，评估通常涵盖全量备份和增量备份两个方面。通过全面的备份资源评估，可以制定有效的备份策略，确保数据安全和业务连续性。

结合项目实践经验，依据 Oracle 数据库和 TiDB 数据库日常的备份方式和备份策略，可以得出 Oracle 数据库相关指标与 TiDB 数据库的对应关系，从而形成下表的对照参考。

• 全量备份

全量备份是指将数据库所有数据在特定时间点复制到备份介质上。它通常用于创建初始备份或定期进行完整数据恢复。全量备份可以采用两种主要方式：

Dumpling 工具: 使用数据导出工具 Dumpling ( https://github.com/pingcap/tidb/tree/release-8.1/dumpling )，你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份。Dumpling 也支持将数据导出到 Amazon S3 中。这种方法具有简单易用的优点，但可能需要较长的备份时间和较大的存储空间。

**BR 工具: **Backup & Restore (BR) 简称 BR，通过对大数据量的 TiDB 集群进行数据备份和恢复，可以实现数据迁移，备份恢复功能包含了多种不同类型的集群数据对象的备份与恢复实现，此处只涉及到 BR 的全量备份功能。

• 增量备份

增量备份是指仅备份自上次全量备份或增量备份以来发生变化的数据。它通常用于更频繁地捕获数据变化，以缩短恢复时间并减少存储空间需求。增量备份主要采用以下方式：

**TiDB Binlog 工具: **TiDB Binlog 用于收集 TiDB 中二进制日志数据、提供实时数据备份和同步以及将 TiDB 集群的数据增量同步到下游。

5.2 评估方法

为了确保数据库备份拥有足够的存储空间，避免因空间不足导致备份失败。预留合理的空间，为未来业务增长提供缓冲，降低后期扩容成本。数据库备份策略的稳定运行以及灾难情况下的数据快速恢复，需要综合考虑备份存储空间以及磁盘性能等因素来综合考量，默认使用 NFS 等备份存储，此处更多从备份存储空间容量的角度来进行资源评估：

• **默认指标：**TiDB 集群采用 3 副本；备份存储使用 NFS
• **备份空间核心指标：**备份后的文件大小 < 总备份空间 * 80%
• **全量备份空间评估指标：**根据项目实践经验，总结备份后的文件大小与 TiDB 集群大小的比例关系
• 增量备份空间评估指标：

根据项目实践经验，总结 Oracle 数据库的归档日志大小与 TiDB Binlog 大小对应比例关系。通常项目投产上线 TiDB 之后，为了防止出现意外情况导致的 TiDB 服务异常，可以部署 TiDB 到 Oracle 的应急回切链路。通过这条同步链路，可以查看某天的 Oracle 归档日志大小和 TiDB Binlog 日志大小，从而得到 Oracle 数据库的归档日志大小与 TiDB Binlog 大小对应比例关系。以月为周期统计 Oracle 归档日志的日均值大小，从而得到 TiDB Binlog 日均值大小，依据这些信息来评估未来一段时间内所需要的 TiDB Binlog 空间大小。

以下是项目实践总结出来的备份数据参考：

全量备份：

增量备份：

5.3 Dumpling 全量备份空间评估

根据项目实践经验，使用 Dumpling 工具全量备份后文件的大小略有放大，约为 TiDB 集群大小的 1.2 倍：

TiDB 集群大小：Dumpling 备份后文件大小 ≈** 1:1.2**

5.4 BR 全量备份空间评估

根据项目实践经验，使用 BR 工具全量备份后文件的大小约等于 TiDB 集群大小除以 TiDB 集群副本数量：

TiDB 集群大小：BR 备份后文件大小 ≈ 3.5:1

5.5 Binlog 增量备份空间评估

根据项目实践经验，Oracle 数据库迁移至 TiDB 数据库后，每天日志增量大小大约会缩小一倍，可以根据 Oracle 数据归档日志大小来对应的计算 TiDB Binlog 大小：

Oracle 归档日志大小：TiDB Binlog 大小 ≈** 2:1 **。

• 按天查看 Oracle 归档日志大小

2024 年 07 月 10 日，Oracle 数据库归档日志大小为 716 GB。

select
        sum(block_size * blocks)/ 1024 / 1024/1024 DAY_GB,
        to_char(first_time,
        'yyyy-mm-dd') DAY_TIME
from
        gv$archived_log
where
        first_time > sysdate -7 
        and dest_id = 1
group by
        to_char(first_time,
        'yyyy-mm-dd')
order by
        2;
        
DAY_GB     DAY_TIME
---------- -----------
720.522 2024-07-07
700.844 2024-07-08
779.099 2024-07-09
716.177 2024-07-10
613.449 2024-07-11
759.644 2024-07-12
800.371 2024-07-13

7 rows selected

• 按天查看 TiDB Binlog 日志大小

2024 年 07 月 10 日，TiDB 数据库 Binlog 日志大小为 354GB。每个 Binlog 日志约为 513M，所以查看对应日期的文件个数即可计算出日志大小：

[root@cxbdzxfcdb-46-12 pb]# pwd
/tidb_backup/backup_policy_fc/tidb_binlog_8249/pb
[root@cxbdzxfcdb-46-12 pb]# ls -l binlog-000000000006*20240710*|wc -l
706
[root@cxbdzxfcdb-46-12 pb]#

• 查看 Oracle 归档日志日均值大小

以 2024 年 06 月整月为统计周期，计算出 Oracle 数据库归档日志日均值大小为 702GB。

select substr(t.DAY_TIME,1, 7) MONTH_TIME,
       max(t.DAY_GB) MAX_DAY_GB,
       avg(t.DAY_GB) AVG_DAY_GB
  FROM (select sum(block_size * blocks) / 1024 / 1024/1024 DAY_GB,
               to_char(first_time, 'yyyy-mm-dd') DAY_TIME
          from gv$archived_log
         where first_time > sysdate - 30
           and dest_id = 1
         group by to_char(first_time, 'yyyy-mm-dd')) t
 group by substr(t.DAY_TIME, 7);
 
 
MONTH_TIME         MAX_DAY_GB AVG_DAY_GB
------------       ---------- ----------
2024-06            1400.300 702.463

5.6 备份资源评估示例

以某头部保险公司的保单业务为例，全量备份使用 BR 工具和 Dupling 工具两种方式分别进行评估，增量备份使用 TiDB Binlog 工具进行评估，依据上述评估过程，可以获得 TiDB 集群大小与 TiDB 备份大小的对应比例关系，也可以获得 Oracle 归档日志大小与 TiDB Binlog 大小的对应比例关系以及 Oracle 归档日志的日均值大小，结合 TiDB 数据库当前数据量大小以及生产备份策略，可以完整的评估出所需要的备份资源。

全量备份大小和增量备份大小计算方法如下：

全量备份

BR 全量备份大小：

= TiDB 集群大小 /（集群大小：备份大小比例关系）

= 27.7TB /（3.6/1）

= 7.7TB

Dumpling 全量备份大小：

= TiDB 集群大小 /（集群大小：备份大小比例关系）

= 27.7TB / （1/1.2）

= 33.2TB

保留策略：

每天备份，保留 2 天全量备份

增量备份

增量 Binlog 备份大小：

= Oracle 归档日志日均值大小（以月为周期取日均值）/ （Oracle 归档日志大小：TiDB Binlog 大小比例关系）

= 540GB / （2.1/1）

= 257GB

**保留策略：   **

准实时备份，保留 3 天

备份资源评估结论：

• BR 全量备份 +Binlog 增量备份所需总空间为 22TB。
• Dumpling 全量备份 +Binlog 增量备份所需总空间为 86TB。

总结

本文为从 Oracle 迁移到 TiDB 的用户提供了一份详尽的数据库资源评估指南，通过深入分析 TiDB 集群资源及备份资源的评估方法，帮助企业合理规划硬件资源配置，保障数据安全，提升系统性能，降低迁移风险，为企业决策提供科学依据，保障服务可用性并降低运维成本。

在数据迁移准备阶段，用户需要充分调研业务系统基本情况和业务指标，结合本文提供的资源评估方法，制定合理的资源规划方案，以确保 TiDB 集群的稳定运行和数据的安全可靠。资源评估应紧密结合具体业务场景，避免一刀切的做法。此外，用户还需关注评估模型的精确性和数据增长的合理预测，资源评估是一个持续渐进的过程，应根据业务的发展和变化不断地进行调整和优化。