关系型数据库的发展经历了漫长的岁月。这些数据库大家都非常熟悉，包括很多事务型和分析型数据库产品和技术。TiDB分布式数据库是新一代开源分布式NewSQL数据库。整个产品结构非常清晰，计算与数据存储层分离。这是大多数现代分布式数据处理系统通常倾向于考虑的架构：底层“TiKV”层是分布式数据库的存储引擎层，不仅用于访问和管理数据，还负责对数据进行并行操作数据。TiKV之上是“TiDB”层，它是分布式数据库的SQL引擎层，处理连接会话管理、权限控制、SQL分析、优化器优化、执行器等关系型数据库的核心功能。此外，还有一个名为“PD”的集中式调度器承担着集群大脑的角色。同时在整体架构中集成了一些运维管理工具，包括部署、调度、监控、备份等，TiDB可以实现自动水平伸缩、强一致性分布式事务、多副本等重要的NewSQL特性基于Raft算法的复制，也满足了我行对高可用、高性能、高扩展性的要求。TiDB易于部署，在线弹性扩展不影响业务，远程多活自动故障恢复保障数据安全，兼容MySQL协议，将迁移和使用成本降到极低。本文将详细介绍我行TiDB的设计与实践。1.设计目标当我们设计TiDB分布式数据库集群时，我们需要考虑各种需求。因此，拟定以下内容作为本项目的设计目标。二、业务需求1、业务数据预估我们设计的TiDB分布式数据库集群一期规划承载一个业务系统，即我行核心的支付交易系统。在购买设备之前，我们根据业务发展规模进行了合理预估，获取了预计的日交易量、数据规模、数据增长率等信息。2.设备需求估算根据第一年的数据量和日交易量来规划设备需求，同时考虑数据副本数和磁盘空间可用性。因此，需要规划足够的冗余存储容量。另外，TiDB集群还需要中控机对集群进行统一管理，监控机对集群进行监控，服务器进行数据备份。因此，这些服务器的规划也必须加以考虑。除了生产集群，我们还设计了一个slave集群，用于异地容灾。binlog用于同步生产集群和灾备集群之间的数据。我们选择了Kafka作为binlog同步工具。因此，我们需要考虑Kafka服务器的配置规划。至此我行TiDB集群所需设备已经规划完毕，具体如下：设备角色生产集群TiKV生产集群TiDB/PD中控机监控机备份服务器Kafka服务器slave集群服务器三。整体架构设计我们的TiDB集群是两地三中心的多活架构，设计了主从集群的容灾部署。在本章中，我们将详细介绍架构设计。1.逻辑架构设计架构说明：(1)整个集群采用主从结构。master集群作为生产集群，承担日常的生产服务。从集群通过binlog异步同步主集群的数据，作为容灾集群使用。（2）主集群（生产集群）采用两地三中心结构，分别为同城IDC1、同城IDC2、异地IDC3。(3)slave集群和master集群通过binlog完成数据同步。2.物理位置规划(1)IDC1和IDC2各配备两个机柜，均用于部署生产主集群。IDC3的一个机柜用于部署生产主集群，另一个机柜用于部署容灾从集群。(2)每个IDC配置2台10G交换机（主备部署）。master集群各机器内部通信，slave集群各机器内部通信，master和slave集群之间使用10G网络。(3)三个IDC的负载均衡挂载在全局DNS下，每个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组件分别向PrometheusPushgateway推送数据，由Prometheusserver统一抓取；Prometheus中的监控数据通过自定义Grafana展示模板展示。当监控值超过我们指定的阈值时，会触发告警，告警信息会通过AlertManager或集成监控平台以邮件或短信的方式通知管理员。根据故障的严重程度，将告警分为警告、紧急、紧急三个级别。最高级别的紧急表示最严重的故障。根据业务需求和信息系统安全要求，我们定制了不同的告警策略。(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）关闭master集群，记录当前时间戳；4）将业务数据库连接切换到slave集群；5）启动主集群；6)从集群运行Drainer与主机集群同步。7.应用适配和优化(1)检查和优化库/表/索引等内部对象。TiDB优化器会根据统计信息选择最优的SQL执行计划。统计信息收集表级别和列级别的信息，并存储在三个表中：stats_meta、tats_histograms和stats_buckets。除了系统自动更新，我们还编写了脚本来手动更新统计信息，定时执行ANALYZE语句来收集统计信息。SQL执行计划由一系列运算符组成。TiDB提供了EXPLAIN语句来查看SQL语句的执行细节。当数据库中的对象需要优化时，我们会综合分析统计信息和执行计划，然后提供优化方案。（2）性能检测与判断应用连接TiDB数据库后，需要检测几个指标：QPS、TPS、响应时间、业务数据库大小、业务表增长速度、数据库连接会话数、热盘等。目前我们会通过监控、巡检、日志三个方面综合分析指标，从而判断数据库的性能。五、结语综上所述，以上就是我行分布式数据库TiDB两地三中心多活架构的方案设计和具体实践，涵盖了监控、告警等日常运维管理的方方面面、集群调优、备份恢复、容灾切换、扩容缩容等，未来我行将尝试将更多业务场景迁移到分布式数据库，探索更多实用领域。同时也希望能把我行的实践经验分享给大家，互相学习，共同进步。我们欢迎您提出宝贵建议！
