IT评测·应用市场-qidao123.com技术社区

标题: 多点 Dmall x TiDB：出海多云多活架构下的 TiDB 运维实战 [打印本页]
作者: 自由的羽毛    时间: 2024-11-22 18:01
标题: 多点 Dmall x TiDB：出海多云多活架构下的 TiDB 运维实战
作者：多点，唐万民
导读
时隔 2 年， 在 TiDB 社区成都地区组织者冯光普老师的协助下，TiDB 社区线下地区活动再次来到成都。来自多点 Dmall 的国内数据库负责人唐万民老师，在《出海多云架构，多点 TiDB 运维实战》的主题分享中，先容了多点在出海业务场景摆设和利用 TiDB 的经历。本文根据唐万民老师的演讲实录进行整理，你可以从中了解到多点从无到有，利用 TiDB 的业务场景，多云架构的实践履历，以及版本升级遇到题目的办理方案。


多点的 TiDB 之路

现在，多点在国内和出海都有利用 TiDB 的业务，线上生产情况中共有 46 套 TiDB 集群，300+节点，400TB+ 数据量。这些集群支撑着包罗业财融合、TMS、结算、采销、物流、库存根据、履约、存货核算等在内丰富的业务场景。底层的云资源也根据各地业务需求，选择了腾讯云、华为云、微软云、火山云等众多公有云。


多点大概有二十多个线上生产情况，上图是其中一个情况的部分 TiDB 集群，从中能看出业财一体化的数据库流量非常大，入网出网都是 500 MB/s 左右，QPS 17, 000 看着好像不高，但其实都是一些大的查询和操作。


多点现在摆设的 TiDB 版本许多，从上图可以看出，从 5.1.1、5.1.2，一直到现在最新升级的 6.5.8 版本都有。其中，线上版本分布最多的是 6.1.5 版。那为什么多点会有如此多的 TiDB 版本，而不全部升级到 6.5.8？其实作为 DBA 而言，对待数据库一样平常情况下都是能不动就不动，一旦动了就有出题目的风险。而数据库的绝大多数题目、风险是由变更引起的。
但为什么我们又要做升级呢？一是由于业务推动，数据库当前这个版本可能已经满足不了业务需求，不得不升；二是高版本实在太香了，有一些新功能很想用，这个需求已经凌驾了升级带来的风险。一旦做出选择，我们就会对 TiDB 的新版本做一些调研，看看升级到哪个版本更好。这时候就不得不提到 TiDB 社区的氛围真的非常好，TiDB 的各个版本社区小伙伴都有在用，社区里会有许多人热心地答复我们的一些题目，也会有许多升级、摆设的实践分享，我们在选择新版本时就会有更多的履历来参考。
多点与 TiDB 携手前行



作为 TiDB 的老朋友，多点和 TiDB 的缘分很早，从 2018 年起就打仗了 TiDB，其时候照旧 2.0.3 版本。其时我们想把 MySQL 的一些复杂查询拿到 TiDB 里做，但是测试发现 TiDB 2.0.3 版性能确实不是那么好，MySQL 办理不了的题目，TiDB 也办理不了。
直到 2020 年的 TiDB 4.0 版本开始，TiFlash 出现了，我们就又想实验一下 TiDB。其时多点的业财业务非常复杂，数据量非常多，MySQL 已经承载不了这个数据。通过调研，我们最终选择将这部分数据迁徙到 TiDB。2020 年 6 月开始，TiDB 上线测试情况；9 月，生产情况正式升级到 TiDB 4.0 GA 版本；10 月，生产情况又升级到 4.0.6 版本；2021 年 4 月，继续升级到 4.0.9 版本；2021 年 10 月，升级到 5.1.2 版本；2022 年，升级到 5.1.4；2023 年，升级到 6.1.5；直到近来，我们升级到 TiDB 的 6.5.8 版本。其实，多点每年都在升级新的版本，这里面当然也有一些线上的题目在推动着我们升级，后面会详细睁开。
数据库类型选择

多点用 TiDB 到底在做什么？为什么要选择 TiDB？我会从四个场景睁开分享多点将 TiDB 应用到哪些场景中。



第一个场景 是 一连增长类数据 。TiDB 在一连 增长类的场景中黑白常得当利用的，一个是它只管写入，无穷扩容，不像 MySQL，假如写多了就要做迁徙，做分库分表，要去保证集群的高可用，迁徙代价也非常高，要去做各种各样的沟通，还有许多迁徙风险。TiDB 有一个平滑迁徙的功能，并且存储本钱降低了 70%。同时，TiDB 在存储数据时和 MySQL 不一样， MySQL 是没有经过压缩的， TiDB 会经过压缩算法将数据进行压缩。经过我们测试，TiDB 的一个单副本和 MySQL 的单副本比起来最大有接近 10 倍的差距。即便是日志类的数据， TiDB 是三副本， MySQL 是主从两份数据，TiDB 的数据存储本钱也会降低许多。


第二个场景 是 数据冷热分离，历史数据归档 。我们在刚开始用 TiDB 时， DM 还没有现在的 DM cluster 那么成熟，所以我们自研 了 DRC-TiDB 同步工具，用这个工具去做从 MySQL 到 TiDB 的同步，将一些冷数据、历史归档数据放到 TiDB 里面。然后 MySQL 就保持高性能读写， TiDB 全量储存。


第三个场 景是 合库合表，**OLAP** 聚合查询 。MySQL 里的数据 分布在不同的库和不同的表里面，研发在查询时就会非常痛苦。做分库分表的都知道，在分库分表里去做查询、聚合都非常痛苦。研发其实很喜好把许多的分库分表，许多的数据聚合在一起，TiDB 可以非常好地支持做这个事情，并且 TiFlash 是列存的数据，有全量数据，我们可以用 TiFlash 去加速一些统计的操作。


第四个场 景是 替换 ES 。在多点内部， ES 用的非 常多，但 ES 的本钱非常高。假如涉及到大数据量存储的话，ES 必要许多机器，我们用 TiDB 做了一些 ES 的替换。实话实说，有一些查询场景，好比模糊查询， ES 其实比 TiDB 会更好一些。所以做 ES 替换的时候，我们也做了一些测试，假如迁到 TiDB 里查询性能没有 ES 好，我们就不会去替换。实际结果测下来，有大概 60% 的 ES 是可以替换的，整体本钱也降低了许多。
多点的数据技能栈架构



上图是多点数据技能栈的整体架构。数据从 MySQL、仓储、贩卖、付出这些数据库，通过 DRC-TiDB，流转到 TiDB 集群里；财务引擎也可以直接把数据清洗转换过来，在 TiDB 里面去做读写；其他一些业务也会在 TiDB 里面去做读写。在这个流程的卑鄙，我们会在 TiDB 里面直接去做一些分析，好比一些财务相干 API 、财务核算、全流程的跟踪体系、经营分析等。此外，我们还有一些大数据的需求，是通过 TiCDC 将数据流转到 Kafka，然后再到 Spark，再到大数据离线数仓。好比说有一些离线的报表需求，都是到 Hive 里面去做，整个流程较长。
出海业务 TiDB 摆设的架构选择

之前，多点出海业务只摆设在微软云上，但逐步出现了一些题目：

基于这些缘故原由，我们就从只摆设微软云改为“微软云+华为云”双机房的摆设模式，目标是当恣意机房不可用时，TiDB 都可以主动恢复调停数据。我们通过微软云和华为云，在新加坡为 RTA 搭建同城双活架构，应用、中间件、数据库跨 2 个公有云摆设，实现 3 个同城机房，恣意一个机房不可用业务都可以快速恢复，进步 RTA OS 可用性。


上图是双机房摆设方案的架构图，微软云有两个 zone，华为云有一个 zone，TiDB 的 PD 集群跨三个 zone 摆设， TiCDC 在微软云和华为云各摆设一个节点，TiDB 也在微软云和华为云各摆设一套，各摆设一些节点。这样做的话，必要在 TiKV 节点打上 dc 的 label，然后去把 region 分布在三个机房。TiDB 至少 2 个节点，跨 2 个机房摆设，TiCDC 也是跨 2 个机房摆设。我们也对 DRC-TiDB 同步链路恢复做了一些优化，做了一些 master standby 的布局，假如一个 DRC-TiDB 链路中， MySQL 到 TiDB 的链路挂了，另外一个能起到 standby 的作用。


这是我们在 TiKV 上打的一些 dc 的 label，里面的 zone、dc、rack、 host 其实大家都可以自己设置，这只是标识出你要把 region 分布在哪些机器、zone 上。不外，Placement rules 跟这个方法是不能一起利用的，有可能出现预期外的一些题目。


实施方面，我们将 PD 集群从微软云迁徙 1 个节点到华为云，TiKV 节点打上 dc label，从微软云迁出部分节点到华为云，等它主动 rebalance 完，然后 TiDB 也从微软云迁出一个节点到华为云。整个过程其实黑白常平滑的，假如我们用 MySQL 从一个云迁徙到多个云的话，就会非常麻烦。或者将 MySQL 从一个云迁徙到另外一个云，也非常麻烦。我们其实做过许多 MySQL 的迁徙工作，好比前段时间把腾讯云上的 MySQL 整体迁徙到火山云，其中一些情况的工作量非常大，而且风险也很大，但 TiDB 做这种迁徙就非常平滑。
多云 TiDB 集群实践过程中的题目

我们在利用 TiDB 的时候也会遇到一些题目，并不是说 TiDB 就完美无缺了。但 TiDB 的社区非常开放活泼，不管遇到什么题目，你去 asktug 上一查，许多题目都有人遇到过了，从他们的分享中你可以直接得到资助。
好比在 4.0.9 版本，我们遇到过 TiDB Server 的 OOM 题目。它的 expensive SQL hashagg to sreamagg 有一个题目，在内存里面去做一个哈希，TiDB server 耗费的内存非常高。我们其时改成 stream aggregation 走这个执行计划，内存斲丧一下就降下来。在 TiDB 更新的版本里，这些题目都已经办理了。其实，在 TiDB 4.0.9 版本中，不论是 TiDB Server、TiKV 或是 TiFlash，内存控制都没现在的版本好。那为什么现在的版本就会好许多？这是由于大量的社区用户都反馈了利用 TiDB 时遇到的题目，经过官方优化，新版本天然就办理了。
4.0.9 还有一个 CDC 的题目。CDC 由于重要是涉及到一些大数据需求，或者必要流转到卑鄙的需求才会用到。假如数据量小的话，应该不会遇到许多题目。其时，我们的 CDC 就是重启后 checkpoint 不推进，挂了以后起不来。这重要是由于其时 sort-engine 默认是 memory，假如机器内存不敷，在重启后做排序的时候，它内存就不敷了。后面的新版本有 unified sort DR，内存不敷了就会先放到磁盘，然后再去做一些排序，做一些 check。
此外，我们的 dashboard 其时按非时间排序查询 slowlog ，导致了 TiDB OOM ，这是由于 plan decode 引起 insert SQL 较大。假如 insert SQL 不大这个题目是不会产生的。还有一些执行计划跑偏的题目，TiFlash 重启起不来的题目，其时我们都遇到过，后续的版本都已经办理了。其实，任何数据库，数据量很小的时候都会没题目，一旦上了量，题目就会变多。所以有我们这种数据量比较大的用户利用 TiDB，就会帮大家把这些雷都排了，大家再遇到这些题目就可以放心利用了。
升级也是大家都会关心的题目，升级后 TiDB 万一起不来怎么办？我们在 5.1.2 版本就遇到了这个题目。TiDB 升级的正常次序应该是 TiFlash、PD、TiKV、 pump、tidb、drainer、cdc、prometheus、grafana、alertmanager 这样一个次序。有一次，我们升级的时候 TiFlash 升级完马上就升级 CDC 组件，跳过了 PD、TiKV、 pump，末了升级失败了。其时 TiUP 1.5.1 版本组件可能存在题目，升级到更新的 TiUP 版本就办理了这个题目。
在 6.1.5 版本升级的时候，我们也遇到过题目。其时升级后发现 TiDB 起不来，经过仔细检查发现是由于我们升级前有一个大的 DDL 在跑，升级过程中这个 DDL 壅闭了升级数据字典的操作，数据字典一直没有升级乐成，导致 TiDB 就起不来。


从上图可以看到，有一个 alter table mysql.stats_meta 去加字段的时候加不了，这是我们升级过程中遇到的非常。所以，我发起升级的时候肯定要检查有没有大的 DDL。实际上，这个题目也是由于我们的数据量很大，DDL 执行的时间很长，其时没有等 DDL 跑完就重启了，假如数据量小的话应该就不会遇到这个题目。
综上所述，曾经遇到的题目都可以在 TiDB 的新版本得到解 决。 我给大家的发起是能用新版本就不要用旧版本 。许多题目在我们这些老用户用 的时候就已经遇到过，这些题目已经反馈给了社区，并一连在新版本中都已经办理了。我相信，假如用 TiDB 的人越来越多，社区也像现在这样一直活泼的话，TiDB 就会越来越好！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/) Powered by Discuz! X3.4