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

avatar
@http://pingcap.com

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

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

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

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

进入主题,先交代下环境,服务器集群采用 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)中发起选举:

  • 选举会增加 label 限制,确保 leader 最终在保留的 TiKV 中产生;

  • 由于 learner 没有投票权,选举实际还是个 5 副本选主,多数派 (N+1)/2 仍为 3。

(四) 这样新的 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 点的奋斗。