银行交易系统 TiDB 在线缩容迁移

2019-05-16 11:02:42 +08:00
 PingCAP

作者:Dan 本文转载自公众号「白噪声 OG 」。

经历了上礼拜漫长的上线周期,终于有时间总结一下期间发生的故事。TiDB 是一款非常优秀的国产分布式 NewSQL 数据库,因其支持水平扩展性、强一致性、高可用性,从 18 年 3 月起已在国内银行的账务、支付类核心系统得到应用。

临近年中,银行重要系统的建设进入投产冲刺阶段,本次上线又有多个系统对接 TiDB,为了优化集群资源分配,引发了这次分享的主题——线上系统 TiKV 的缩容、region 的迁移,本文主要针对本次 TiKV 的缩容、迁移过程进行梳理总结。

TiDB 数据库的扩容已在官方文档进行了详细的说明https://pingcap.com/docs-cn/op-guide/horizontal-scale/并被各路大咖广泛提及,但缩容迁移并在银行交易系统上的实践却少有分享,这也是本文的目的之一。

进入主题,先交代下环境,服务器集群采用 NVMe+SSD 的存储方案构建了 16 个 TiKV 实例,作为重要的核心支付类系统,两地三中心五副本不可少,每个 TiKV 上 8K+ 个 region。整个迁移过程历时 5 个小时,过程中没有停止系统对外服务,很是顺滑平稳。

接下来还是看一下迁移的过程:

(一) TiKV 采用 Raft 一致性算法保证副本强一致性,迁移过程本质上是扩容的逆过程,确定下线的 TiKV 打上 label 后,将 region 搬移到最终保留下来的 TiKV 上。

(二) 接下来聚焦 region 1 的 Raft Group,对其副本进行搬移,实际上所有 region 的数据是一样的,只是在保留的 TiKV 内进行 region 数据的复制,新产生的副本由于数据不完整,作为 Raft Group 中的 learner。

(三) Learner 创建后,PD 会在这样的一个 Raft Group ( 5 个全副本 region + 2 个 learner )中发起选举:

(四) 这样新的 leader 选出来了,当两个新副本数据追平后,将删除下线 TiKV 中的 region。

(五) 这样一个新的 5 副本 Raft Group 我们就获得了。

这里再说几点:

1. 磁盘 IO 对迁移的效率影响还是很大的,测试环境使用普通的 SAS 盘,在更高并发的条件下,耗时长了很多。

2.(二)、(三)、(四)的过程并非原子化操作,当然 learner 的数据本身也不具备一致性,但对 raft 的改造最终要保证一致性,与 PingCAP 的开发同学确认后,这些会在之后加入。

3. 我认为最有意思,也最有意义的一点,learner 的引入是本次迁移过程中非常巧妙的设计,解决了数据不一致副本在选举过程中的尴尬地位,而 learner 也是 Multi-Raft 协议中的重要角色,HTAP 引擎 TiFlash&TiSpark 也以此引入列存副本,非常期待 TiDB 3.0。

PS:本次上线的重头戏 Cloud TiDB 在平稳运行后,希望有机会进行总结分享。TiDB 自上线后实现了多次重要变更操作,均未暂停系统对外服务,从一只开发狗的角度看 TiDB 在金融级 NewSQL 数据库的方向上的确投入了很多。

最后,感谢 PingCAP Gin 同学和研发大神们的支持,感谢运维爸爸们直到凌晨 4 点的奋斗。

2411 次点击
所在节点    推广
5 条回复
gosansam
2019-05-16 14:59:37 +08:00
这也太🐂🍺了吧
PressOne
2019-05-16 15:10:34 +08:00
哪个行?
jieee
2019-05-16 15:25:13 +08:00
@PressOne
估计是北京银行,我看官网案例出现了
notfound09
2019-05-16 15:42:46 +08:00
围观大佬
saltxy
2019-05-16 18:08:27 +08:00
大。。。大佬

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/564624

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX