{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-resource-control",
"result": {"pageContext":{"blog":{"id":"Blogs_486","title":"新特性解析丨TiDB 资源管控的设计思路与场景解析","tags":["Resource Control"],"category":{"name":"产品技术解读"},"summary":"资源管控技术是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。","body":"## 导读\n\n资源管控技术（Resource Control）是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。 \n\n本文从将技术优势、配置方式、场景实践等角度详细解析 TiDB 7.0 版本中的资源管控技术。 \n\n作为可透明扩展的分布式数据库，TiDB 一直致力于满足企业对大型数据库集群的管理需要，集群内资源管控和资源隔离是企业客户长久以来的诉求之一。资源管控的主要目的在于解决数据库管理中常见的一些问题： \n\n- 当多个业务共享同一数据库集群时，某个业务的非预期负载变化会影响其他业务的正常运行\n- 当集群中存在混合负载时，对资源需求较高的数据分析或批量作业会影响在线交易类业务的响应时间\n- 在需要 7x24 高可用性的业务系统中，数据备份、统计信息收集等后台任务可能会影响服务质量\n- 应用灰度上线时，小流量引发的性能问题仍可能“击穿”整个生产数据库\n\n为了解决上述场景中的问题，TiDB 开发了资源管控技术，于 TiDB 6.6 首次引入，并在 TiDB 7.0 进行了优化和增强。该技术利用资源组 (Resource Group) 将一个庞大的数据库集群划分为多个逻辑单元，每个资源组都能限制其所需的计算和 I/O 资源。通过特定设置，当集群有空闲资源时，允许一部分资源组超越其限制，以实现资源的充分利用。\n\n## 核心优势\n\n- TiDB 采用了业界领先的双层资源管控机制来实现更精确的管控。“流量控制”模块控制资源限额，确保仅在限额内的操作才能得以执行；“调度控制”模块则对队列中的任务设置不同的优先级，以确保在负载剧烈变化或超负荷运行时，高优先级的任务能够得到快速反馈。与同类产品通常只提供其中一层管控能力不同，TiDB 同时具备流控和调度控制能力，能够精确定义出更符合用户场景的配置。\n- 基于存储计算分离的架构，TiDB 的资源管控对最重要的 I/O 资源进行了限制。I/O 吞吐通常是数据库系统最常见的资源瓶颈，也是资源管控的难点，多数数据库产品并不支持对 I/O 进行控制。只有控制住主要瓶颈，才能保证在资源阻塞时有疏通调控的手段。\n- 把所有资源抽象成统一的单位来进行分配和限制。太过细粒度的设置通常难以衡量，也容易失去灵活性。TiDB 希望通过尽量少的指标来识别用户的意图，自适应地完成最佳的调度方案，提升易用性。\n- 除了隔离性，提升资源利用率也是 TiDB 资源管控的重要目标。在整体资源尚有空闲的情况下，允许部分业务超过资源组定义的限制。 \n- 提供用量统计的精确反馈， 通过监控面板获取实际用量的使用情况，协助用户合理改进配置。同时，配合企业管理目标，TiDB 能够协助企业精确统计各部门数据库资源的使用情况，进而完成合理的成本分摊。\n- 提供灵活的资源绑定手段。支持在用户级，会话级，和语句级指定资源的绑定方式，满足不同场景的资源控制需要。\n\n## 管理方式\n\n资源管控引入了“资源组(Resource Group)”的概念，通过设置“用户”和“资源组” 的对应关系，把会话与用户组进行绑定，利用“用量 (RU)”对资源限额进行定义。结构如下：\n\n\n\n### 资源组 (Resource Group) \n\n资源组是资源管理的逻辑单元。任意一个会话属于唯一的资源组，而同一资源组的所有会话共享同一组资源限额。TiDB 支持数据库用户与资源组的映射关系，通过设置数据库用户的默认资源组，用户会话可以分属于不同的资源组。未指定默认资源组的用户，与系统内置的 default 资源组相关联。\n\n### 资源限额\n\nTiDB 首先支持为资源组配置用量 (RU)。RU (Request Unit) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位，目前会考虑 CPU、IOPS 和 IO 带宽三个指标，按照一定的比例统一到 [RU 单位上](https://docs.pingcap.com/zh/tidb/v6.6/tidb-resource-control#什么是-request-unit-ru)。TiDB 支持设置资源组为 BURSTABLE 模式，BURSTABLE 模式允许资源组超额使用到集群的空闲资源。\n用户可以查看面板数据的反馈，以获取真实的用量请求和分配情况。通过对数据进行分析，来优化资源组的限额配置。配合真实负载的压力测试，用户还可以通过数据反馈得出整个系统的用量上限。\n\n### 调度优先级\n\n默认情况下，所有资源组的优先级 (PRIORITY)均为“中等(medium)”。当资源组在同一优先级下，调度优先级按照资源配额的比例分配，这已经能够满足绝大多数场景的需要。用户仍旧可以显式地指定资源组优先级为“高(high)”或者“低(low)”，从而完成更复杂的设定。比如，为一个算力需求不大，但优先级很高的应用配置资源组。\n\n### 资源组设定\n\n在 TiDB v7.0，用户能够通过以下方式指定资源组：\n- 用户级别。通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。\n- 会话级别。通过 `SET RESOURCE GROUP` 设置当前会话的资源组。\n- 语句级别。通过优化器 hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n### 配置步骤\n\n- 启用资源管控\n\n手工开启资源管控分两步进行（资源管控在 TiDB 7.0 中默认开启）： \n\n1)设置 TiDB 全局变量启用“流量控制”： \n```\nSET GLOBAL tidb_enable_resource_control = 'ON';\n``` \n\n2)在 TiKV 配置中将 `resource-control.enabled` 设为 `true` 启用“调度控制” \n\n- 估算集群容量\n\n在资源规划之前，TiDB 提供了集群总用量(RU)的估算。需要注意的是，这个值是基于当前硬件配置结合平均负载经验得出的参考值，在运行用户实际应用时可能会有偏差。用户可以以此作为资源组起始规划的参考，后续再根据实际运行数据进行微调。 \n\n```\nCALIBRATE RESOURCE;\n```\n\n- 有了总容量的估算，此时我们可以根据实际业务目标规划和创建资源组。例如创建一个名为 rg1 的资源组，分配每秒 500 RU 的流量，并允许资源组在有空闲资源的情况下超限额分配。 \n\n```\nCREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;\n```\n\n- 将用户 `usr1` 的资源组设置为 `rg1`\n\n```\nALTER USER usr1 RESOURCE GROUP rg1;\n```\n\n完成上述配置后，当系统繁忙时，用户 `usr1` 的所有会话使用的资源上限为 500 RU/秒；非繁忙时间段， `usr1` 则能够使用空闲集群资源。\n\n## 场景演示\n\n我们来看一个配置的示例。假定我们有三个租户分别运行三种不同的业务形态，每类业务有不同的管控目标：\n\n\n\n对于以上这个需求，如果选择严格的多租户物理隔离，就不得不为每一个租户分配足够的资源，同时会造成 oltp 谷值负载时的资源浪费比较严重；而放入一套集群又无法消除租户 batch 对租户 oltp 的影响。利用 TiDB 既“隔离”又“融合”的资源管控技术，我们可以为这几类用户分别创建资源组：\n\n- 为租户 oltp 分配一个较高的用量，租户 batch 和 租户 hr 则相对低，这样在系统资源紧张的情况下，保证租户 oltp 的服务质量。\n- 租户 oltp 和 batch 的资源组设置为 burstable， 这样租户 oltp 发生超预期的负载，仍旧可能会保证质量；而当整个集群负载有空余时， 租户 batch 可以利用空闲资源加速其工作。\n\n\n\n- 创建资源组\n\n```\nCREATE RESOURCE GROUP oltp RU_PER_SEC=4000 BURSTABLE;\nCREATE RESOURCE GROUP batch RU_PER_SEC=400 BURSTABLE;\nCREATE RESOURCE GROUP hr RU_PER_SEC=400;\n```\n\n- 创建租户对应租户，并设置其所属的资源组\n\n```\nCREATE USER 'oltp' RESOURCE GROUP oltp;\nGRANT ALL PRIVILEGES ON oltp.* TO 'oltp'@'%';\n\nCREATE USER 'batch' RESOURCE GROUP batch;\nGRANT ALL PRIVILEGES ON batch.* TO 'batch'@'%';\n\nCREATE USER 'hr' RESOURCE GROUP hr;\nGRANT ALL PRIVILEGES ON hr.* TO 'hr'@'%';\n```\n\n在完成以上简单的设置之后，我们来模拟几个租户不同的负载，观测吞吐量 (QPS) 和服务质量 (P99 响应时间）。整个场景模拟分为三个阶段： \n\n1. 首先三类负载同时运行， 租户 oltp 设置为峰值负载。\n2. 切换租户 oltp 的负载到谷值，其他不变。\n3. 再次切换租户 oltp 的负载回到峰值。\n\n\n\n从实际数据来看，TiDB 资源管控技术在负载变化时的反馈非常及时。租户 oltp 的响应时间始终维持在较低的水平，租户 hr 的吞吐被限制在较低的范围内：\n\n1. 当租户 oltp 维持在峰值负载时， 它保持高吞吐和较低的响应时间；租户 batch 和 租户 hr 维持在低吞吐，由于租户 batch 可以使用空闲资源，因此吞吐要略高于租户 hr。\n2. 当租户 oltp 进入谷值负载，吞吐下降，其响应时间仍旧很低。这时由于租户 batch 的资源需求很大，因此它的吞吐迅速提升，响应时间下降， 租户 hr 仍旧被限制在其限额内。\n3. 当租户 oltp 重新回到峰值负载，租户 batch 则立即让出资源，使得租户 oltp 的吞吐再次回到之前的水平，响应时间维持不变。\n\n由此得出， 利用 TiDB 提供的资源管控和调度能力，多个不同诉求的租户能够共存在一套系统中，在保证各自服务目标的基础上，提升资源使用效率。\n\n## 资源管控技术协助企业兼顾质量与成本\n\n从上面的例子我们看到， 资源管控技术能够有效地解决在负载剧烈变化时，服务质量无法保证的问题。我们也可以利用这项技术防止未经验证的应用出现资源过载，比如新业务上线前的灰度测试，为资源组为灰度流量定义上限，避免局部性能问题引发大范围影响。 \n\n资源管控技术同时提供了数据库的多租户隔离能力，支持企业将中小型的系统进行合并，降低数据库运行成本。成本的节约主要来自几个方面： \n\n- **节省预留资源**：一般来说，我们在规划单系统容量的时候，平均负载一般占到规划容量的 50% 甚至更低，留下足够的空间应对突发的性能抖动，以及未来可能的业务增长。而多个不相关的业务系统很少在同一时间出现负载波动，结合 TiDB 可透明扩展的特性，将这些系统合并到同一集群中，就不必预留相同比例的空间了。\n\n\n\n- **缓解峰值谷值波动**：如果将负载峰值与谷值不同的系统整合在一起，整合后的系统可以减少负载波动的幅度。在“削峰填谷”的作用下，资源利用率得到提升，低负载时段的硬件浪费也得到了减少。\n\n\n\n\n- **快速扩展与收缩**：企业经常需要为定期的业务活动增加临时的计算资源，以确保系统的稳定性。在多个业务系统合并的情况下，可以借助合理的业务规划，共享预留资源，轮流进行促销活动，而不必反复部署，节约重复的人力投入。\n\n- **提升运维效率**：将多个业务系统整合成一个系统，可以显著降低运维人员的投入。因为管理实体变少了，系统数量也减少到以前的几十分之一，运维难度和需要的人工成本都随之大大降低。\n\n这要求产品需要有很强的负载隔离能力，同时又能够将资源融合，正是 TiDB 资源管控技术想要达成的目标。\n\n## 未来展望\n\nTiDB 发布的资源管控能力是一个很好的开始，我们将沿着这个方向从多角度持续深耕这项技术，通过细粒度资源管控技术为客户创造更多的价值： \n\n- **更多样的管控方式**： 根据场景的不同，为客户提供百分比，权重，用量等多种资源限额定义方式，并把 TiDB Cloud 中 Serverless 模式的计量方式和经验注入产品，协助客户运行自己的私有云服务，轻松完成成本分摊。扩展资源组的映射方式，支持除用户以外其他会话属性向资源组的映射。\n\n- **更多维的管控范围**： 除了最重要的 CPU 与 I/O 资源，持续延伸管控的范围和粒度，如分析型负载，内存使用，并行度等等。另外， 还将支持把运维操作和系统内部任务编入资源组， 协助客户做更精细的场景定义。\n\n- **更智能的管控手段**：通过分析历史运行数据，提供资源管理的建议，协助客户发现资源配置的潜在问题和风险，结合 TiDB Cloud 的部署运行经验，为客户提供更经济更合理的资源配置建议，协助企业的成本控制。\n\nTiDB 的弹性扩展特性和资源管控能力可以有效提高 IT 系统的效率，并协助企业降低 IT 运营的成本，同时确保系统的稳定性和安全性。随着资源管控技术的不断增强， TiDB 一定能够协助企业在数字化的道路上更加扎实地前进。","date":"2023-04-19","author":"宋日杰","fillInMethod":"writeDirectly","customUrl":"tidb-resource-control","file":null,"relatedBlogs":[{"relatedBlog":{"body":"\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。 \n\n资源管控适用于以下场景： \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况： \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示： \n\n\n\n## 自动计划缓存减少查询延迟 \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。 \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。 \n\n\n图：TiFlash 存算分离架构\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。 \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。 \n\n## 使用 Key 分区提高可扩展性 \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求 \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。 \n\n## 使用 LOAD DATA 从远程存储导入数据 \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。 \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\n\n\n","author":"PingCAP","category":2,"customUrl":"tidb-7.0-release","fillInMethod":"writeDirectly","id":473,"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","tags":["TiDB","Release"],"title":"TiDB 7.0 发版"}},{"relatedBlog":{"body":"## 导读\n\n现在，数据库已成为众多企业信息系统的核心，数据库的备份恢复能力至关重要。对于 TiDB 这样的分布式数据库而言，数据库存储数据量不断增加，备份恢复也面临着更多挑战。\n\nAmazon Web Services (AWS) EBS 快照是一种数据备份技术，用于将 EBS 卷上的数据快速备份到云端。他山之石，可以攻玉，本文分享了 TiDB 运用 AWS EBS 快照技术实现备份恢复功能的原理和实践，以及如何解决传统数据库备份恢复特性无法克服的问题，让备份恢复特性向前迈进了坚实的一步。\n\n## 备份恢复技术介绍\n\n备份恢复对数据库产品来说是至关重要的，因为数据库是许多企业信息系统的核心部分，如果数据库出现问题或者数据丢失，将会对企业造成极大的损失。因此，备份恢复技术是用来保护数据库数据，确保在意外情况发生时能够尽快恢复数据库的正常运行。\n\n传统数据库的备份恢复技术通常分为备份和恢复两部分。其中包含了全备和增量备份。全备就是将数据库的所有数据和日志文件都备份到一个指定的目录或者存储设备中。增量备份则是只备份数据库在上一次备份之后发生变化的数据和日志文件。\n\n恢复技术则是将数据库恢复到一个指定的时间点的过程。通常，恢复技术需要将备份的数据和日志文件按照时间顺序进行恢复，以便保证数据库的一致性。\n\n传统数据库备份恢复技术的主要优点是简单易用，但是也有很多问题，其中最主要的问题就是：\n\n1. 备份过程中可能会对数据库造成一定的影响\n2. 恢复时间也会受到数据量的影响，导致恢复时间较长（RTO 通常以小时甚至天为单位）\n\n在数据库技术进入到分布式数据库时代后，随着数据库数据量的不断上升，上面的问题对用户的影响越来越大。\n\n## AWS EBS 快照技术介绍\n\nAmazon Web Services (AWS) EBS 快照是一种数据备份技术，用于将 EBS 卷上的数据快速备份到云端。EBS 卷是 Amazon Elastic Block Store (EBS) 的一种存储设备，可以将其作为 Amazon Elastic Compute Cloud (EC2) 实例的持久化存储。\n\nEBS 快照是一种增量备份技术，只备份在上一次备份之后发生变化的数据。因此，EBS 快照备份速度很快，并且备份的数据量也较小。\n\nEBS 快照可以保存在 Amazon Simple Storage Service (S3) 中，可以在 S3 中的任何区域内进行存储。EBS 快照可以用来创建新的 EBS 卷，也可以用来创建 Amazon Machine Image (AMI)。\n\nEBS 快照是一种非常有用的数据备份技术，可以帮助企业保护其重要数据，并且在数据丢失或损坏时进行快速恢复。\n\n## TiDB 如何利用 AWS EBS 快照技术进行数据库备份恢复\n\n\n\n作为采用 raft 协议的 shared-nothing 架构的分布式数据库产品的典型代表，新一代的 TiDB 备份恢复特性创新性地利用了 EBS 快照技术，解决了传统数据库备份恢复特性无法克服的问题，让备份恢复特性向前迈进了坚实的一步。\n\nTiDB 将数据存储在 EBS 卷上，当需要进行备份的时候，通过 TiDB Operator 向 backup contorller 发出备份的命令，产生相应的 Backup Worker，产生 TiKV 节点所对应的 EBS 卷的快照并保存到 S3 中。在恢复的时候，则通过备份时保存在 S3 上的元数据和 EBS 卷快照来将集群恢复到新的集群。\n\n由于 EBS 快照是一种磁盘快照技术，只能够保证 EBS 自己的一致性，却无法保证数据库层面的一致性。而且在数据库事务层的处理上，同一个事务的数据，在经过 MVCC 版本编码以及 Raft 层处理后，数据落盘到不同的 TiKV 的 EBS 卷上，这些卷之间的一致性是 EBS 快照无法保证的。\n\n无论在备份还是恢复过程中，如何确保备份的数据是一致的，以及如何将数据库基于 EBS 快照恢复到用户指定的时间点，并确保数据的一致性，是一个很大的挑战。\n\n幸运的是，TiKV 维护了 region 级别的 resolved_ts，用来代表某一个 region leader 上最大能读到的一致性完整事务的时间，即 resolved_ts = max(resolved_ts, min(lock_cf.StartTS))。resolved_ts 能够保证任意时刻能读到当前 region 最大数据一致性的 ts. 同时 TiKV 会计算当前节点所有 region leader 上最小的 resolved_ts, 并主动汇报给 PD。PD 汇总集群所有 TiKV 一致性 TiKV resolved_ts, 得到集群级别 min_resolved_ts。\n\n### 备份阶段\n\n\n\n在备份阶段，BR 工具会首先从 PD 获得集群的全局一致性 min_resolved_ts ，之后停止副本的调度和 GC，并行调用 AWS 卷快照服务产生 TiKV 节点 EBS 卷快照并保存备份的元数据，之后恢复副本调度并记录元信息，最后备份结束。\n\n### 恢复阶段\n\n\n\nBR 工具在接受到恢复请求之后，restore worker 会获取备份的元数据，其中包含集群拓扑信息以及备份时数据一致性的 min_resolved_ts。之后获取恢复目标集群的拓扑信息，以便确保是否开始恢复。Restore worker 会首先恢复集群的 PD 组件，之后根据备份的元数据挂载 TiKV 节点对应的 EBS 快照，接下来根据元数据中的一致性 min_resolved_ts 将集群恢复到一致的状态。\n\n### 测试数据\n\n在以下的内容中，我们会展示一组数据来说明该特性在备份和恢复方面的性能。\n\n**备份阶段**\n\n首先，EBS 卷快照备份阶段包含创建备份任务、停止调度、停止 GC、获取备份时间 backup_ts 以及卷快照, 其时间占比如下：\n\n\n\n由于创建 EBS 卷快照是并行的，因此整个备份的时间取决于耗时最久数据卷快照创建时间，与集群规模无关。下面的表格描述了 EBS 卷中数据该变量与备份时间的关系。\n\n\n\n经过测试，备份过程对集群的 QPS 影响低于 3%。\n\n**恢复阶段**\n\n对于恢复阶段，由于 EBS 快照的恢复是并发执行的，整体恢复时间取决于恢复最慢的 TiKV 节点，与集群规模也没有很大的关系。基于我们的测试，对于一个 21TB 规模的 TiDB 集群（每个 TiKV 节点采用 1TB 的 EBS 卷）， 可以在 15 分钟左右完成恢复。下面的表格包含了恢复过程中各个阶段的耗时：\n\n\n\n对于各个恢复阶段的详细解释和更多测试数据，请参考 TiDB 文档：基于 EBS 卷快照备份恢复的性能介绍\n\n## 未来规划\n\n接下来，TiDB 的备份恢复特性会沿着基于存储快照技术这个方向继续发展，支持更多云厂商的磁盘快照能力，并以此为基础，发展出更多的高级备份恢复特性。","author":"高斌","category":1,"customUrl":"from-disk-snapshot-to-backup-recovery","fillInMethod":"writeDirectly","id":470,"summary":"本文分享了 TiDB 运用 AWS EBS 快照技术实现备份恢复功能的原理和实践，以及如何解决传统数据库备份恢复特性无法克服的问题，让备份恢复特性向前迈进了坚实的一步。","tags":["TiDB","备份恢复"],"title":"TiDB 6.5 新特性解析丨他山之石，可以攻玉：从磁盘快照到备份恢复"}},{"relatedBlog":{"body":"## 导读\n\nTiKV 推出了名为“partitioned-raft-kv”的新实验性功能，该功能采用一种新的架构，不仅可以显著提高 TiDB 的可扩展性，还能提升 TiDB 的写吞吐量和性能稳定性。TiDB 6.6 之前的版本已经成功容纳超过 200 TB 的数据，甚至有客户将超过 500 TB 的数据放入 TiDB 集群中；开启新功能后，TiDB 的可扩展性能够提高到 PB 级别。本文将深入介绍 TiKV “partitioned-raft-kv”功能的用户价值、应用实践以及使用方式。\n\nTiDB 是一种高度可扩展的分布式 HTAP 数据库，而 TiKV 是 TiDB 基于行的存储层。TiDB 的优势之一在于它的 OLTP 可扩展性：在 TiDB 6.6 之前，TiDB 集群可以轻松容纳超过 200 TB 的数据；有些客户正在将超过 500 TB 的数据放入 TiDB 集群中。相比之下，像 Aurora 这样的传统数据库则很难处理超过 100 TB 的数据。\n\n在 TiDB 6.6 及后续的版本中，TiKV 的一个名为“partitioned-raft-kv”的新实验性功能可以将 TiDB 的可扩展性带到 PB 级别。它利用了一种新的架构，不仅可以提高可扩展性，还可以显著提高 TiDB 的写吞吐量和性能稳定性。\n\n## 用户价值\n\n- 更高效：更好地利用硬件能力，消除写入流程中的瓶颈\n- 更快：更好的写入性能和 QoS，特别是在大数据集下\n- 更安全：每个表的物理隔离。\n\nPartitioned-Raft-KV 的主要改进之一是将写放大显著降低，最高可降低 80%，从而可以释放更多的 IO 资源用于用户的实际读写流量。另一个主要改进是通过每个区域的专用 RocksDB 实例，消除了单个巨大 RocksDB 实例的逻辑瓶颈，因而在生成和应用快照时对用户流量没有逻辑影响。快照的唯一影响是 IO / CPU 资源消耗，但因为降低了读放大，所以总的资源消耗仍然小于旧版本。\n\n## 性能测试\n\n在 AWS m5.2xlarge 上运行 Sysbench 的批量插入：\n\n\n\n在这里，我们可以看到其写入吞吐量要高得多。I/O 吞吐越大，提升越明显。因此，该特性对大宽表（行大小> 4KB）的插入操作性能提升要比小表更明显。\n\n另一个重要的改进是更快的扩缩容速度（即增加/减少 tikv 节点）。这意味着 TiKV 现在可以更快地响应用户流量的增长或下降。更重要的是，可以看到在扩缩容操作时，gRPC 的延迟和吞吐量不会受到影响，如下图所示。\n\n\n\n关于 CPU 使用率，Partitioned-Raft-KV 的 CPU 使用率即使在写入吞吐量更高的情况下也没有显著增加。这是因为工作负载本身并不是 CPU 密集型，并且 Partitioned-Raft-KV 的 compaction 相关操作占用的 CPU 较小，其内部消息编码也进行了优化。因此，单位吞吐量 （MB）的 CPU 使用率要低得多。\n\n## 使用限制\n\n- 工作负载是 CPU 密集型的情况下，例如大量小的读写请求\n- 工作负载是读密集型。\n\n虽然“partitioned-raft-kv”可以节省一些压缩相关的 CPU 资源，但减少的 CPU 资源通常不到一个单独的核心。因此，如果工作负载是 CPU 密集型的，“partitioned-raft-kv”帮助不大，当然它也不会使情况变得更糟。然而，在重读取方案下，“partitioned-raft-kv”可能会有一定的性能退步，因为它在内存表上消耗更多的内存，而在范围查询工作负载中不是很有用，这些内存可以被页面缓存使用以实现更好的读取性能。在未来的版本中，这将通过刷新空闲内存表来进行优化。在接下来的章节中，我们将探讨它如何实现这些改进，并使用一个真实的用户案例来展示它在 Web3 场景中的好处。\n\n## 应用实践\n\nB 公司是一个 Web3 服务提供商，同步多个区块链的数据，然后向其客户提供查询/分析服务。它每月处理约 40TB 的数据。查询负载主要在最近的新数据上，而旧数据大多处于空闲状态。\n\n\n\n**服务概述**\n\n当每个 TiKV 节点有 2TB+ 数据时，由于读/写放大的影响，性能稳定性会受到影响。因此，为了跟上快速增长的数据量，即使查询流量保持稳定，B 公司也必须每月添加 TiKV 节点来匹配数据大小。为了解决这个问题，B 公司想出了一个解决方案 - 冷热数据分离。\n\n\n\n首先，为了减少已处理数据的影响，他们必须将其与原始数据分开，现在他们有两个集群，一个用于存放已处理数据，另一个用于存放原始数据。其次，为了减少热原始数据的影响，公司 B 使用了放置规则（Placement Rules），通过主键中嵌入的时间戳将冷数据和热数据分开。这是通过每月更新放置规则来完成的。\n\n这种方法的问题是：它增加了管理复杂性，现在公司 B 有两个集群，而不是一个集群。同时，每月更新放置规则也是一个容易出错的操作。冷原始数据和热原始数据的资源分配很棘手。它们不共享，这意味着冷原始数据的 TiKV 大多数时间都处于空闲状态，然后当它们被使用时，资源很可能不足够。但是，有了 v6.6 的“partitioned-raft-kv”，我们可以继续使用一个集群，因为我们从不担心冷数据会影响热数据的查询。冷数据只是静静地坐在那里，不会消耗内存或 CPU。因此，单个 TiKV 可以通过混合冷热数据支持大量数据（4TB +）。因此，我们能够使用完全相同的 TiKV 节点来存储冷热数据。热数据应该分散在不同的 TiKV 节点中，这要归功于热点平衡，而冷数据也应该因为区域平衡而分布均匀在每个 TiKV 节点中。\n\n## 开启方式\n\n该功能只能在设置新集群时启用，之后不能更改，因为存在数据兼容性问题。我们将在后续版本中解决此问题。要启用新功能，只需将 storage.engine 的参数配置为 `partitioned-raft-kv`，另外，还可以通过调整一些其他的配置项来让该特性能更好适应您的工作负载。您可以参考[分区 Raft KV](https://docs.pingcap.com/zh/tidb/v6.6/partitioned-raft-kv) 获取详细信息。\n\n在下一篇文章中，我们将探索新功能的内部机制，介绍为什么它能具有如此大的优势。\n","author":"徐奇","category":1,"customUrl":"partitioned-raft-kv","fillInMethod":"writeDirectly","id":484,"summary":"TiDB 6.6 之前已经成功容纳超过 200 TB 的数据，开启新功能后，TiDB 的可扩展性能够提高到 PB 级别。本文将深入介绍 TiKV “partitioned-raft-kv”功能的用户价值、应用实践以及使用方式。","tags":["TiKV"],"title":"TiDB Raft KV 新引擎：更高级别的可扩展性和写性能"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}