共计 1354 个字符，预计需要花费 4 分钟才能阅读完成。
作者：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）中发起选举：
- 选举会增加 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 点的奋斗。
