--- title: 'TiDB 8.1 LTS 发版：夯实大型集群的稳定性和易用性，驱动业务融合和降低企业成本' date: '2024-05-28T13:36:04+08:00' status: publish permalink: /blog/tidb-8-1-release author: '周, 盛虎' excerpt: '本文将探讨 TiDB 8.1 如何在大规模数据库场景下实现整体稳定性和运维管理能力的提升，并从数据导入、运维安全等几个场景入手介绍新 LTS 版本的部分重要功能。' type: post id: 6791 category: - 公司动态 tag: - Release - TiDB post_format: [] profile: - PingCAP --- ![tidb-8-1-release](https://img1.pingcap.com/files/2024/05/20240530053641652.jpeg)导读 -- 5 月 24 日，TiDB 8.1 LTS 正式发布。 当下，成本效益成为企业在数据库架构选择时的关键因素。随着企业趋向于将数据从分散的数据库实例合并到大型集群中，对数据库的性能、稳定性和运维便利性提出了更高的要求。TiDB 8.1 LTS 的发布，正是为了满足这一需求，它通过一系列创新功能，增强了大型集群的稳定性和运维能力，尤其针对应用多租户功能和 SaaS 类型用户场景做了稳定性和性能的多方面增强。 **本文将重点解析 TiDB 8.1 在大型集群运维、性能稳定性层面的进展**。随着 TiDB 持续演进，我们也将继续为用户提供可靠、高效、易于管理的数据库解决方案，支持企业的数字化转型和业务增长。 - - - - - - 在整体经济周期的冲击下，成本逐渐成为大中型用户在数据库构架规划中的重要考量因素。基于运行成本和管理成本的考虑，我们注意到越来越多的客户将原先分散在多个数据库实例中的数据迁移合并到一个大型集群中。这些数据原本来自按地域划分的数据库实例、按业务种类划分的实例，以及提供 SaaS 或 PaaS 服务的数据库实例。 与传统数据系统设计相比，这类合并后的大型数据库集群包含了海量数据和建模，并为大量应用系统提供服务支撑。因此对性能、稳定性以及单元化管理能力都有着更高的要求。这让我们意识到，协助客户解决这类大型集群合并过程及合并后所面临的问题和风险变得尤为重要。比如： - 更大集群规模，更多数据表，更大数据量的场景下，集群依旧稳定运行； - 提升大规模数据操作的效率，并限制其影响范围，包括数据导入，批量建表，数据恢复，创建索引等场景。 - 更细粒度的数据修复手段，在遭遇数据损坏或人为误操作时避免进行全库数据恢复； - 尽可能地保持服务可用，不发生闪断； - 个别业务的性能问题要得到有效控制，避免其影响到全局； - 添加便捷有效的 SQL 调优手段，简化操作步骤，又不会为集群引入风险； - 将观测数据进一步深化并细分，能够观测到更多细节，也能够观测到业务单元内运行状况，并协助用户按用量进行成本拆分。 作为 2024 年发布的第一个长期支持版本 (LTS)，TiDB 8.1 着眼于提升大型集群的稳定性和运维能力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用性以及可观测性等方面获得了持续的提升。TiDB 8.1 LTS 包含了已发布的 7.6.0-DMR 和 8.0.0-DMR 版本中的新功能、提升改进和错误修复。TiDB 8.x 开始着手一些复杂的架构改进，旨在进一步提升大型集群性能和稳定性，这些工作无法在一个 LTS 周期完成，因此我们在 v8.1 中看到了许多实验特性。同时，上一个 LTS 发布的大部分实验特性都已转为正式功能。 本文将探讨 TiDB 8.1 如何在大规模数据库场景下实现整体稳定性和运维管理能力的提升，并从数据导入、运维安全等几个场景入手介绍新 LTS 版本的部分重要功能。 性能与稳定性 ------ **TiDB 并行执行框架与全局排序相辅相成，提升大规模数据写入的性能和稳定性** 扩大并发度是提升分布式系统性能的重要手段，尤其对于大规模数据系统而言尤为关键。分布式执行框架（Distributed eXecution Framework，简称 DXF）是 TiDB 从版本 v7.2.0 开始引入的重要特性之一，旨在实现任务在多个 TiDB 节点的统一调度和分布式执行。该框架可以将用户提交的任务（目前支持数据导入和添加索引）分解成多个子任务，并在多个 TiDB 节点上进行调度和执行，有效提高了任务的执行效率和性能，特别是对于需要处理大量数据的场景非常高效。**通过对节点进行动态任务分配，TiDB 可以将任务分配到特定的节点，实现任务的隔离执行。这种灵活性意味着可以通过按需添加资源来处理这类任务，从而提高了整个集群的稳定性和可靠性**。自 8.1.0 开始，DXF 将会默认打开。利用分布式执行框架，多个 TiDB 节点能够共同参与并行数据导入。而全局排序（Global Sort）则为多个 TiDB 节点维护了一块共同的排序空间，**通过一体化排序整理，使得每个 TiDB 节点所导入的数据不会有重叠，不会触发 TiKV 进行 compaction 操作，从而显著提升了并发数据导入时的稳定性，同时也提高了导入速度**。全局排序是在 8.1.0 中成为正式功能的另一个重要特性。 ![全局排序](https://img1.pingcap.com/files/2024/05/20240530053926752.png)批量数据写入遇到的性能问题，一直是大型数据系统的常见难点，包括数据导入，数据迁移，创建索引等场景。并行执行框架与全局排序的引入与日趋成熟，则为这道难题给出了强有力的答案。 **快照备份的恢复速度提升 3 倍，守好集群可用性最后一道防线** 数据备份是保障数据安全的最后一道屏障。大型数据库系统包含了大量的关键业务数据，一旦发生数据丢失或损坏，在高可用手段失效的情况下，需要尽快恢复数据以保障业务的正常运行。数据恢复速度决定了服务的连续性。这也是 TiDB 持续投入改进恢复速度的理由。 经过反复测试研究，TiDB 研发团队通过采用粗粒度打散 Region 算法、批量创建库表、降低 SST 文件下载和 Ingest 操作之间的相互影响、加速表统计信息恢复等改进措施，把快照恢复的速度大幅提升。在最新的发布的 LTS 中，TiDB 快照恢复的数据传输速度已经能接近网络传输的上限，提升 10 倍，快照恢复速度提升了 1.5 到 3 倍，能够在 1 小时内完成对 100 TB 数据的恢复。 数据恢复速度的提升对于大型数据库系统来说具有重要的意义，能够在极限场景下减少业务的中断时间，提高业务的连续性和稳定性。 稳定性 --- **TiProxy 支持自有部署，实现“无感”数据库运维** 随着更多数据库实例合并到 TiDB 集群中，服务业务系统的数量和种类也相应增加，对可用性的要求也随之提高。TiProxy 应运而生，并在 8.1 LTS 版本中成为正式功能。 ![TiProxy](https://img1.pingcap.com/files/2024/05/20240530054057747.png)TiProxy 为数据库端提供连接服务，根据 TiDB 实例的负载和状态将客户端操作转发到其中一个 TiDB 实例。在大多数情况下，即使 TiDB 实例宕机，客户端连接也不会受到影响。在 TiDB 集群进行滚动重启、升级、缩容等维护操作时，通过使用 TiProxy 可以平滑地将连接迁移至其他 TiDB 实例，使客户端无感。当多个 TiDB 服务器负载不均衡时，TiProxy 提供连接动态迁移功能，将连接从一个 TiDB 服务器迁移至其他 TiDB 服务器，实现 TiDB 集群的负载均衡，而客户端无需感知。 TiProxy 在 TiDB 之前的调度和保护功能为 TiDB 提供了额外的服务质量保障，为大型 TiDB 集群的安全运维管理提供了更加完善和可靠的解决方案。 易用性 --- **跨数据库执行计划绑定，简化合并数据库的 SQL 调优工作** 将应用系统中的租户存入不同的数据库（Schema）中，是 SaaS 或 PaaS 类业务系统的常见建模方式，也广泛存在于原有分库合并后的系统。这种方式在每个 Schema 中创建完全一致的对象，并执行类似的业务 SQL。它提供了很多好处，比如，租户间的数据相互隔离，不用担心业务表可能会成长为巨型表。当某一个租户被废弃时，数据归档和数据清理工作也变得更加容易。但是，这种建模方式相应地会增加 SQL 的种类，在某些场景带来不便。比如当一条 SQL 需要被绑定到特定的执行计划时，通常来说，运行在其他 Schema 上的类似 SQL 都需要被绑定。当集群中存在上百个 Schema 时，这就成为数据库管理员的噩梦。 ![跨数据库执行计划绑定](https://img1.pingcap.com/files/2024/05/20240530054203288.jpeg)为解决这类问题，TiDB 在 8.1.0 中支持创建跨数据库执行计划绑定（cross-db binding）。一个执行计划绑定能够匹配到只有 Schema 不同的多个 SQL 语句，大幅简化了在这类建模下的 SQL 调优工作。 跨数据库执行计划绑定还能够解决这类建模的一个常见问题。各个租户的数据量可能会有很大的差别，但一般数据分布式相当的。当某个租户的数据量在短期内大幅增长时，统计信息收集可能无法及时完成，依据旧统计信息生成的执行计划有很大可能会遭遇性能问题。为解决这类问题，管理员可以选择在大数据量租户的关键 SQL 上创建跨数据库绑定，从而实现每个 Schema 下的相同 SQL 都被按此执行计划运行。通常情况下，在大租户上运行良好的执行计划，在小租户上也不会造成明显的性能回退。通过这种方式，用主动手段规避某个快速增长的租户的执行计划偏差问题。 跨数据库执行计划绑定，是 TiDB 为运行大型集群的一类客户场景“量身定做”的功能，大幅提升 SQL 调优的便利性。 可观测性 ---- **观测并识别无用或低效的索引，治愈系统调优的“后遗症”** 索引设计是数据库性能调优中至关重要的一环。根据经验，正确的索引设计可以解决一半以上的性能问题。在经过长时间的调优后，一个大型业务系统往往会积累大量索引。这些索引不仅消耗数据库存储空间，还会降低 DML 操作的速度，占用运行资源，然而在这种规模的集群中，删除索引又是一项对性能风险极高的操作。如果没有有效的方法监控和识别索引的使用情况，大量低效甚至无用的索引将成为系统性能的负担。 ![观测索引选择](https://img1.pingcap.com/files/2024/05/20240530054301580.jpeg)TiDB 在最新的 LTS 版本中引入了对索引使用情况的监控功能。通过内存表 TIDB\_INDEX\_USAGE 记录了每个索引自实例启动以来的运行情况，包括索引被选择的次数、扫描行数以及每次扫描时的选择率范围等信息。这些数据可以帮助管理员确定哪些索引是活跃的，哪些索引的选择效率偏低，从而帮助识别出需要删除的索引和有优化空间的索引。为了符合 MySQL 用户的使用习惯，TiDB 还提供了 sys.schema\_unused\_indexes 视图，快速查看自实例启动以来未被使用的索引。 结语 -- 在未来的产品迭代中，TiDB 将持续关注用户在使用和运维大规模数据库集群时遇到的稳定性及便利性问题。面对不断增长的数据规模、数据表和分区，TiDB 致力于从性能、稳定性和运维能力等多个角度出发，通过不断演进和创新，为用户提供更加稳定、高效的数据库解决方案。 TiDB 是为关键业务打造的分布式数据库，不仅适用于传统企业应用，也适用于互联网业务，能够为用户提供可靠的数据存储和处理能力。无论用户面对的是哪种业务场景，TiDB 都能够助力他们实现业务的持续增长和创新发展。通过持续关注用户需求，TiDB 将不断优化自身功能和性能，为用户提供更加优质的数据库服务。
[下载 TiDB 社区版](/product-community/) [咨询 TiDB 企业版](/contact#submit-form)
[免费试用 TiDB Cloud](https://tidbcloud.com/free-trial?utm_source=website_cn&utm_medium=direct&utm_campaign=blog)
适用于中国出海企业和开发者