分布式数据库TiDB在商业银行的设计与实践

关系型数据库的发展经历了漫长岁月，这些数据库大家都非常熟悉，包括交易型、分析型的很多数据库产品和技术。 TiDB 分布式数据库是新一代开源分布式 NewSQL 数据库，整个产品的结构非常清晰，计算跟数据存储层分离，这是现代大部分分布式数据处理系统通常都会倾向和考虑采用的架构：

最底层“ TiKV ” 层，是分布式数据库的存储引擎层，不只是用来存取和管理数据，同时也负责执行对数据的并行运算。在 TiKV 之上即是“ TiDB ”层，为分布式数据库的 SQL 引擎层，处理关系型数据库诸如连接会话管理、权限控制、 SQL 解析、优化器优化、执行器等核心功能。此外，还有一个承担集群大脑角色的集中调度器，叫做“ PD ”，同时整体架构中还会融合一些运维管理工具，包括部署、调度、监控、备份等。

TiDB 可实现自动水平伸缩，强一致性的分布式事务，基于 Raft 算法的多副本复制等重要 NewSQL 特性，并且也满足我行对于高可用、高性能、高可扩展性的要求。 TiDB 部署简单，在线弹性扩容不影响业务，异地多活及自动故障恢复保障数据安全，同时兼容 MySQL 协议，使迁移使用成本降到极低。这篇文章中，我们将详细介绍 TiDB 在我行的设计与实践。

一、设计目标

我们在设计 TiDB 分布式数据库集群时，需要考虑多方面的需求，因此，制定了以下内容，作为项目的设计目标。

二、业务要求

1 、业务数据估算

我们设计的 TiDB 分布式数据库集群在一期计划承载一套业务系统，该系统为我行核心支付交易系统。在采购设备之前，我们根据业务的发展规模进行了合理估算，得出了预期日交易量、数据规模、数据增长率等信息。

2 、设备需求估算

设备需求按照第一年的数据量和日交易量进行规划，并综合考虑了数据副本数和磁盘空间可用率，因此需要规划足够的冗余存储容量。此外， TiDB 集群还需要中控机对集群进行统一管理、需要监控机进行集群监控、需要服务器进行数据备份，因此，还要考虑这些服务器的规划。

除了生产集群，我们还设计了从集群，作为异地灾备使用。生产集群和灾备集群之间通过 binlog 同步数据，我们选用了 Kafka 作为 binlog 同步工具，因此，需要考虑 Kafka 服务器的配置规划。

至此，我行的 TiDB 集群所需的设备均已规划完毕，详情如下：

三、整体架构设计

我们的 TiDB 集群为两地三中心多活架构，并且设计了主从集群的灾备部署，本章节我们将详细介绍架构设计。

1 、逻辑架构设计

架构说明：

（ 1 ）整个集群采用主从结构，主集群作为生产集群，承担日常生产服务，从集群通过 binlog 异步同步主集群数据，作为灾备集群使用。

（ 2 ） 主集群（生产集群）采用两地三中心架构，分别为同城 IDC1 、同城 IDC2 、异地 IDC3 。

（ 3 ）从集群与主集群通过 binlog 完成数据同步。

2 、物理位置规划

（ 1 ） IDC1 、 IDC2 各配置两个机柜，均用于部署生产主集群， IDC3 一个机柜用于部署生产主集群，另一个机柜用于部署灾备从集群。

（ 2 ）每个 IDC 配置两台万兆交换机（以主备模式部署），主集群各台机器内部通信、从集群各台机器内部通信、主从集群之间都是使用万兆网络。

（ 3 ）全局 DNS 下挂载三个 IDC 的负载均衡，各 IDC 种负载均衡挂载各自中心内部的 TiDB 服务器，以千兆网环境对外提供业务服务。

四、运维方案设计

1 、高可用方案

高可用是 TiDB 数据库的特性之一， TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。我行的 TiDB 生产集群，由生产中心、同城灾备中心、异地灾备中心共同实现两地三中心多活高可用部署方案。下面，我们将从不同的维度来分析集群的高可用性。

（ 1 ）从服务器角色的角度

集群中的服务器有三个角色： TiDB 、 TiKV 、 PD ，我们从这三个角色来分析集群的高可用性。

TiDB 是无状态的，以实例为单位通过前端的负载均衡设备对外提供服务。当单个 TiDB 实例失效时，仅仅会影响当前实例上进行的会话，应用服务出现单次请求失败的情况，应用重新连接至其他 TiDB 实例后即可继续获得服务，此时可以先摘除这个实例进行故障解决或者重新部署一个新的实例。

TiKV 以集群方式部署，通过 Raft 协议保持多副本情况下的数据一致性，并通过 PD 进行数据层面的负载均衡调度。单个 TiKV 节点失效时，会影响这个节点上存储的所有 Region 。对于 Region 中的 Leader 结点，会中断服务，等待其他 TiKV 上的 Region 重新选举 Leader ，待 Leader 选出了可继续对外提供服务；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复， PD 会将其上的数据迁移到其他的 TiKV 节点上。

PD 同样以集群方式部署，通过 Raft 协议保持数据的一致性。单个实例失效时，如果不是 leader ，那么服务完全不受影响；如果是 leader ，那么 PD 集群会重新选出新的 leader ，自动恢复服务。

（ 2 ）从宕机规模的角度

我行的 TiDB 数据库集群可容忍单机级、 Rack 级、数据中心级的故障，从而实现高可用。

单机服务器故障，分为 TiDB 、 TiKV 、 PD 三个角色，参考上一小节的阐述。

我们将集群所有服务器分散放置在各个 Rack 里，根据 Raft 协议大多数原则，单个 Rack 出现故障，不会影响集群对外提供服务。我行的架构允许集群中两个 Rack 同时出现故障。

任何一个数据中心发生故障，根据 Raft 协议大多数原则，剩余的两个数据中心仍可对外提供服务。

2 、存储方案

TiDB 集群数据库集群的数据包括业务数据、数据库日志、数据库运行状况数据，综合考虑硬盘的容量、 I/O 读写速率等因素后，我们选用了 SAS 盘 +SSD 盘作为服务器硬盘存储。需要注意的是，在规划容量时，要考虑数据多副本的特点，从而规划出足够的存储容量。

数据库日志分为 TiDB 日志、 TiKV 日志、 PD 日志，分别存储在各自的实例节点上。

数据库运行状况相关数据存放集群默认库里，也分散存储在所有 TiKV 节点上，通过定期执行 analyze 操作进行更新。

3 、监控与告警

我行的 TiDB 数据库监控分三个模块：数据库运行状况实时监控、旁路监控、 mocha 监控，告警也分别由这三个模块各自触发。

（ 1 ）数据库运行状况实时监控

这部分是最多、最重要的监控内容。

TiDB 集群使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案，使用 Grafana 可视化组件对监控数据进行展示。告警渠道有两个，一个是我行自主研发的一体化监控平台，一个是 AlertManager 。监控组件安装在监控服务器上， Prometheus 产生的监控数据也存储在这里。

监控与告警总体架构如下图所示：

集群的 TiDB/PD/TiKV 组件分别向 Prometheus Pushgateway 推送数据，统一供 Prometheus server 抓取；通过定制 Grafana 展示模板对 Prometheus 中的监控数据进行展示。

当监控的数值超过我们指定的阈值时，就会触发告警，告警信息通过 AlertManager 或一体化监控平台，以邮件和短信的方式通知管理员。根据故障发生的严重程度，告警被划分为 3 个级别： warning 、 critical 、 emergency ，其中 emergency 级别最高，表示故障最严重。根据业务要求和信息系统安全性要求，我们分别定制了不同的告警策略。

（ 2 ）旁路监控

旁路监控是对 prometheus 监控的补充，一方面检测 prometheus 的模块是否正常，另一方面也会直接监控 TiDB 的关键服务工作状态，针对异常产生告警。下图是旁路监控示意图：

（ 3 ） mocha 监控

监控数据库级别的运行状况。

4 、备份与恢复

虽然 TiDB 集群的多副本策略可以避免故障发生时数据的丢失，但我们仍然需要制定完善的数据备份与恢复策略，进一步加强数据安全性。

通过全量备份工具（ Mydumper ）与增量备份组件（ binlog ），对 TiDB 集群数据库的任意时间点的状态进行保存；当需要恢复数据到某一个时间点时，首先使用全量数据恢复工具（ Loader ）恢复该时间点之前的最后一个全量备份，确认全量导入无误后，使用增量恢复工具（ Reparo ）恢复 PB 文件形式的 binlog 增量数据到所要求的恢复时间点。

（ 1 ）备份

所有的备份组件都安装在备份服务器上，我们编写了自动备份脚本，全量备份和增量数据文件都先存储在本地，再转储至磁带上。

备份策略：

每周一次全备份，选在业务量少的夜间进行；

每天实时备份增量数据。

备份特性：

支持按表恢复数据；

TiDB 的备份数据可以恢复到 TiDB 集群或 MySQL （ 5.7.x ）中；

TiDB 增量备份是贯穿于数据库整个生命周期的，它以 PB 文件的形式存在， PB 文件由 Drainer 解析 binlog 生成。

备份示意图如下：

（ 2 ）恢复

任意一台安装有 mysql 实例的服务器均可用来恢复数据，也可将备份的生产数据经过脱敏处理后用于测试环境的 TiDB 集群。

5 、日常运维方案

（ 1 ）产品升级策略

TiDB 作为开源软件，其产品迭代速度快，常使用补丁式更新，一旦发现错误可马上更新，这与银行业要求的稳定性存在一定差异，且不符合监管要求的变更流程。因此，我们目前的升级策略是待其新发布的大版本稳定后再安排变更升级，对于补丁式小版本，在不影响业务的情况下，暂缓升级。

（ 2 ）集群日常巡检

除了 24 小时实时监控外，我行要求每日对数据库进行定时巡检。这部分我们编写了自动巡检脚本，通过邮件方式推送数据库运行状态。

（ 3 ）集群扩容缩容方案

TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容，实现在线灵活可扩展特性。扩容缩容也分为 TiDB 、 TiKV 、 PD 三种情况，具体操作在 PingCAP 官网都有清晰地描述，这里不再赘述。

需要特别说明的是扩容 PD 时，需滚动升级集群，升级过程中会导致 TiDB 连接断开，影响业务，待升级完成即可恢复，因此，最好选择业务量少的时段进行。**

6 、灾备方案

除了生产主集群，我行的 TiDB 集群还增加了从集群的设计，目的是为了实现异地灾备。因此，我们也制定了完善的主从集群灾备切换方案。

下图是一个简单的主从集群部署示意图，主从集群通过 binlog 进行数据同步：

切换时，主从集群架构不变，仅仅是主从同步数据流改变方向。切换流程如下：

1 ）停业务，等待主从同步完成；

2 ）关闭主集群 Drainer, 停止主从同步；

3 ）关闭主集群，记录当前时间戳；

4 ）将业务数据库连接切换到从集群；

5 ）启动主集群；

6 ）从集群运行 Drainer ，向主机群同步。

7 、应用适配和优化

（ 1 ）检查和优化库 / 表 / 索引等内部对象

TiDB 优化器会根据统计信息来选择最优的 SQL 执行计划。

统计信息收集了表级别和列级别的信息，存储在 stats_meta 、 tats_histograms 、 stats_buckets 这三个表里。除了系统自动更新外，我们还编写了手动更新统计信息的脚本，每日定期执行 ANALYZE 语句来收集统计信息。

SQL 执行计划由一系列的 operator 构成， TiDB 提供了 EXPLAIN 语句，可以查看 SQL 语句的执行详细信息。

当数据库中的对象需要优化时，我们会综合分析统计信息、执行计划，然后给出优化方案。 **

（ 2 ）性能检查和判断

应用连接 TiDB 数据库后，需要着重检查几个指标： QPS 、 TPS 、响应时间、业务库大小、业务表增长率、数据库连接会话数、热点盘等。目前我们会通过监控、巡检、日志三方面综合进行指标分析，从而判断数据库的性能。

五、结语

综上即为我行分布式数据库 TiDB 两地三中心多活架构的方案设计与具体实践，并且结合涵盖了日常运维管理的各个方面，包括监控告警、集群调优、备份恢复、灾备切换、扩容缩容等。今后我行会尝试将更多的业务场景迁移到分布式数据库上，以探索更多的实践领域。同时也希望将我行的实践经验分享给大家，互相学习、共同进步，欢迎各位提出宝贵建议！

本文作者：
王旭丛，金融机构科技项目经理，具备多年银行核心系统运维经验和分布式技术实践经验，负责金融科技基础架构研究及项目管理，长期致力于私有云、分布式数据库技术、智能运维领域的研究和实践。
刘洋，具有7年银行系统平台领域运维管理经验，主要负责Power小机，x86服务器、数据库、中间件、应用负载均衡、监控、备份、容器、私有云、开源技术等的运维及管理工作，对于传统or分布式数据库、双活数据中心建设、容器及私有云平台建设、监控以及自动化运维领域有着深入的见解。